You’ve started using an AI tool and the output is technically fine. Grammatically correct, well structured, plausible-sounding. But it doesn’t sound like you. The proposal could belong to any consultancy in the country. The client update could have been written for anyone. You spend half an hour editing it into something recognisable, which puts you close to the time you’d have spent writing from scratch.
The problem is usually what you haven’t told it.
What is context engineering?
Context engineering is the practice of giving an AI tool structured background about your business before asking it to produce work. Larger firms build formal “context graphs” encoding customer definitions, policies and business rules. For a small services firm, the principle is simpler: write down how your business works in a way AI can read, and share that document at the start of each session.
Think of it as the background briefing a contractor needs before they can produce useful work. A skilled freelancer brought in cold produces generic output in week one. Given a thorough operations brief and a few good examples to work from, the same person is close to what you needed by day three. The AI equivalent of that brief is your context document.
“Context engineering” has gained traction because the gap between useful and generic AI output is often a briefing problem. Practitioners writing for MarTech describe the pattern: enterprise AI projects fail when they treat prompts as the main lever, and succeed when they invest in the underlying context that grounds every prompt. For owner-managed businesses, the investment is far smaller, but the principle is the same.
Why does missing context produce poor outputs?
When an AI receives a request with no background context, it defaults to the internet’s generic version of what you asked for. Ask for a client update email and the tool reaches for the most common pattern it has learned: the average structure, the standard sign-off. Your clients, your tone, your prior decisions, none of that exists unless you provide it.
Atlan, which builds governed data layers for AI agents, describes the consequence plainly: without a defined context layer, AI produces “confident, plausible, systematically wrong outputs” because it resolves ambiguous business terms with its own guesses. If your AI doesn’t know what a “qualified lead” means in your firm, every piece of content that references leads will use the generic definition, not yours, and you may not notice until a client does.
The ICO’s guidance on AI and data protection raises a related point from a compliance angle. Organisations using AI are expected to understand how their systems make decisions and to guard against “automation bias”, the tendency to accept AI outputs without adequate scrutiny. Poor context design is a driver of this: when the AI appears confident and the output is plausible, the habit of checking carefully tends to erode over time.
Where will you actually meet this problem?
Marketing content and client-facing documents are where missing context creates the most visible problems. The output is grammatically correct but off-brand, too generic, or pitched at the wrong type of client. Internal documents, SOPs and onboarding packs, are a close second: without your firm’s specific systems and constraints, the output describes how a generic firm works, not how yours does.
The Chartered Institute of Marketing advises explicitly that providing relevant background context in prompts produces more accurate and actionable outputs for content work. That applies directly to proposals, LinkedIn posts, cold outreach and case study drafts: the AI needs to know your niche, your client profile and your tone before it can produce anything close to your standard.
Client communications and reports sit in a similar position. Meeting follow-ups, project status updates, technical summaries: each needs to know the engagement scope, the decisions already taken and the client’s preferences. Without that context, the output is technically competent but generic, covering the bases rather than reflecting the actual conversation.
When does context engineering help, and when doesn’t it?
Context engineering helps when your AI tasks depend on the specific definitions and tone that belong to your firm. Where it adds little is tasks where you want the generic answer: employment law questions, market overviews, standard calculations. The question to ask before providing a context brief is whether the task’s output quality actually depends on your firm’s specifics, not just general knowledge.
There are two other situations where adding context is not sufficient on its own. The first is when your internal definitions are unclear or disputed. If your team disagrees on what counts as a “qualified lead” or a “completed project”, encoding a contested definition into your AI context will amplify the confusion rather than resolve it. Clarify the human disagreement first, then document it for the AI.
The second is regulated decision-making. The FCA has been explicit that AI must remain a supporting tool, not an automated decision-maker, for regulated activities. The ICO’s guidance on automated decision-making under UK GDPR requires meaningful human oversight wherever decisions have significant effects on individuals. Under the EU AI Act, high-risk AI systems face specific data governance and human review obligations. A well-designed context profile helps your AI produce better draft analysis, but none of that changes the requirement for human sign-off on the outputs that matter.
What does a useful business context profile include?
A business context profile is a one-page document you write once and share with your AI tool at the start of each session. It covers: who you are, who you serve, what you sell, how you work, your tone rules, your non-negotiables, and a short glossary of the terms that matter in your firm. Write it once, refine when something changes, reuse it everywhere.
The glossary section makes the most practical difference. Enterprise teams describe building a “governed vocabulary” so AI agents query your definitions rather than inferring their own. For a small firm, this means listing 5-10 terms that carry specific meaning in your business, “lead”, “qualified lead”, “customer”, “project”, “billable hour”, with a short agreed definition next to each. Thoughtworks’ Role-Task-Context-Expectation structure for individual prompts places the context document in the “Context” slot: your role and task change per request, your business context stays constant.
Keep personal data out of the profile. The NCSC has been explicit that public AI tools may retain user prompts, and the ICO’s guidance on generative AI and data protection makes clear that mixing client-identifiable information into prompts without proper controls creates data protection risk. Your context profile should describe your business in terms that would be safe to share externally: service descriptions, tone rules, process steps. Real client names, case details and financial specifics belong in tools that give you a processor agreement and appropriate data handling assurances.
Once the profile exists, extend it with a few strong examples: proposals you’re proud of, client emails that hit the right note. Include a short note on what each one does well. Enterprise firms call this “decision memory”, a record of what good looks like and why. An AI drawing on strong examples alongside your context profile will produce closer-to-final drafts far more consistently than one working from a prompt alone.
