You have probably had this experience. You asked a model to draft something you write every week, and what came back was fluent, confident, and unusable, because it read like it was written for a business roughly like yours.
Your instinct is to blame the wording and try again. Most of the time your wording was fine.
A well engineered context makes the right answer obvious to the model. A poorly engineered one leaves you with an unreliable answer to a carefully worded question, because the model is working from an incomplete picture of what you do.
Practitioners spent the first years of the generative AI boom treating prompt engineering as the discipline. By mid 2026 the conversation was shifting to this one, as Frank La Vigne summarized at Frank's World in July 2026. The change relocates the problem from something you say to something you own.
What the model was missing
There's a failure pattern in nearly every business that tried AI and found it unreliable.
You asked for something specific and the model invented a specific, because you had never given it one. You asked about a client and it wrote generically, because it knew nothing about that client, that project, or that constraint. You noticed it contradicting a decision you made last week, because it had no memory of last week.
Those are information failures, and a better prompt supplies none of the missing facts. Which matters, because a business that reads unreliable output as a skill gap sends someone on a prompting course, and a business that reads it as an information gap fixes what was broken.
A March 2026 survey of 650 enterprise technology leaders, published by Digital Applied, found 78% had AI agent pilots running and 14% had reached production scale, and traced most scaling failures to operational gaps, among them integration with legacy systems, missing monitoring, unclear ownership, and thin domain-specific training data. That last one is a context problem, and context engineering is the discipline that addresses it.
What it consists of
Four things, and a prompt is none of them.
System instructions. The persistent scaffolding that tells an agent its role, its limits, and what to do when something's missing. "You are a helpful assistant" does none of that. Defining the scope, the output format, and the behavior when a fact is absent does all of it.
Structured inputs. The specific records a task runs on. For a proposal draft in a design studio you'd supply the client intake record, the project brief, and the pricing reference. A general knowledge base leaves the model guessing which of your projects it's looking at.
Retrieval and memory. For anything that has to remember or look things up, you decide which documents get pulled, in what order, and how they're broken up. If nobody structured your knowledge base, nothing can retrieve from it.
Conversation history. Long conversations fill the window. You decide what to keep, what to summarize, and what to drop, because a window full of irrelevant history performs worse than a short focused one.
Prompt quality is real leverage, and it's the last mile. It pays once the model already has the facts your request refers to. Refine wording against a broken context and you get faster, more confident wrong answers.
Why this is operations work
Anthropic released Claude for Small Business on May 13, 2026: fifteen prebuilt skills covering work such as payroll planning, month-end close, marketing campaigns and contract review, with connectors into QuickBooks, PayPal, HubSpot, Google Workspace and others. Small businesses are roughly 44% of US GDP, and a frontier lab shipping a product built specifically for them is worth noticing.
A prebuilt skill knows the general shape of a job. It's built for the median business, so it can't know your edge cases, your categories, or the history behind how you talk to a particular client. You supply all of that or nobody does. The skills are the easy part.
So when a tool like that lands, ask whether your business has a source of truth for any skill to reference, and be honest about where your information lives rather than where it's supposed to. For most firms you'll find it in an inbox, a CRM three people stopped updating, and a Slack thread from eight months ago with the real decision buried halfway down.
Point a tool at the right records and it produces good work. Point it at whatever it can reach and it produces confident work that somebody then has to verify, correct, and re-explain. The hours you were going to recover go into that instead.
Related questions
What is the difference between prompt engineering and context engineering?
Prompt engineering is how you phrase a request. Context engineering is what the model knows before the request arrives: instructions, records, memory, and retrieved documents. In most failed deployments the context was the problem.
Does context engineering apply to a small business?
Yes, and the discipline is the same at any size. A ten person studio needs its client records, project history and service scope reachable by an agent. The scale of the context changes and the practice doesn't.
Is context engineering the same as RAG?
Retrieval-augmented generation is one technique inside it, specifically pulling documents from a knowledge base into the context window at runtime. Context engineering also covers system instructions, structured inputs, memory, and history management.
What happens if I have good prompts but poor context?
Output stays generic and inconsistent relative to your situation, and the model may invent specifics it was never given. Better prompts leave the bottleneck in place, because the bottleneck is the information.
How do I start?
Audit what information exists in your business and what shape it's in, before designing what an agent should know. You need to know what you have and what's missing before anything can be structured for retrieval.
How we read this
Context is the whole game, and an agent without good context is a waste of time and tokens, which is to say a waste of your budget. We've held that position since we started building these systems, and the industry naming it in 2026 changed the vocabulary and left the fact where it was.
What follows from it is a sequencing view. Building the knowledge base, getting one source of truth, running a project system your team uses: those are the prerequisite, and stage one of how we work for exactly that reason. You can do this work without buying anything, and it makes every tool you add afterward start from a higher floor.
We'd also say that your firm is better placed for this than a large one. The specifics a model needs are the specifics you carry in your head, and you can write them down this month. A two thousand person company has to extract them from people who are leaving.
What you can do this week
Take one task where AI gave you something unusable. Write down what an incompetent new hire would have needed to know to do that task properly, so specific and direct it may read as condescending: which client, which constraints, which past decision, which of your preferences that nobody has ever written down. Then ask the agent to ask you questions about the task until it is confident it will do the work to your satisfaction.
That list is the context. It's usually shorter than people expect, and once it's on paper you can see it was never a prompting problem. If you are new to this and want to go further, our three day Flow Sprint has you building agent instructions over your morning coffee.
Working together
Flow State Found works with a limited number of businesses to make their best work their baseline. Firms usually arrive here after months of output that could have come from anyone. We get what your business knows into a form a model can work from, which is what makes the output sound like you.
We take on limited engagements, so it starts with a conversation.
Start a conversation