The tell is in the failure, not the model. If your agent understands the goal and gets the specifics wrong, that is context. If it gets the specifics right and stops halfway through the job, that is workflow. If it does neither and the work is genuinely outside what it can do, that is the tool. Diagnose first, then fix, in that order.
What Does Each Failure Actually Look Like?
Three failure modes, three different feelings.
Context failure looks like a draft that is well written and wrong. The agent writes a proposal in the right tone but uses last year's pricing. It emails a client about a project you finished in March. It describes your business as a consulting firm when you actually run a training company with two software products and a resort. The writing is fine. The facts are not. That is context every single time.
Workflow failure looks like an agent that does one step and then hands you the baton. It drafts the email but does not send it. It pulls the data but does not load it into Airtable. It builds the plan and never checks whether step three completed. You become the human API between every step, which is the most expensive job in the building and the exact one you were trying to stop doing.
Tool failure looks like genuine incapability, no matter what you feed it. A text model cannot watch a webinar and cut clips. An agent that cannot execute code cannot run your tests. If the context is complete and the workflow is clean and it still cannot do the thing, stop feeding it and change the instrument.
Most people I talk to have two of these at once, and they treat all three with the same fix, which is a bigger model. That is why the drafts keep coming.
How Do I Test for Context Before I Touch the Workflow?
Ask the agent to state the goal back to you. Then ask it to list the facts it used to get there. If it can do the first and not the second, you have your answer.
A few concrete moves:
- Write your business down once, in one file. Who you serve, what you sell, what you charge, what you refuse to do, and three examples of work you are proud of. Keep it in Notion or Airtable so it can be pulled, not pasted into a fresh chat every morning.
- Attach your data instead of describing it. Give the agent the actual invoice export or the actual CRM rows through something like Airtable or Supabase. Descriptions drift over time. Records do not.
- Build a retrieval layer. A plain Postgres table with embeddings, or something like Pinecone, means the agent fetches the right three documents instead of reading all four hundred.
- Version the context file. When pricing changes, the file changes the same day. Most context problems are really stale context problems.
Context engineering is a discipline, not a prompt trick. The work is deciding what the agent should always know, what it should be able to look up, and what it should never guess at.
If every chat starts from zero, this is your problem. Fix it before you touch anything else.
How Do I Test for a Workflow Problem?
Run one job end to end and write down every point where you touch it. If your hands show up twice, the workflow is the problem.
Then:
- Map the steps before you build anything. I sketch it on paper first, then build it in n8n. If a step has no defined input and output, it is not a step. It is a hope.
- Add a checkpoint after every step that can fail. Not human approval on everything, just verification. Did the row get written? Did the send come back with a message ID? In n8n or Make you branch on that. In Zapier you add a filter. Without it, failures travel silently downstream and surface three steps later wearing a disguise.
- Keep one place where a person can interrupt. Mine is a Slack channel. The agent posts the draft, waits for a reaction, then continues. That is still an agentic workflow. It is not a downgrade.
- Log every run. Timestamp, input, output, success or fail. A Google Sheet is enough. After two weeks the pattern shows up, and it is almost never the model.
When Do I Actually Need a Different Tool?
When context is complete, the workflow is clean, and the agent still cannot finish. Trust that signal faster than you do.
Some jobs need a different model. Long structured reasoning and code execution tend to favor Claude. Fast, cheap, high-volume classification tends to favor GPT models or a small open model on your own hardware. Neither is right for everything, and pretending otherwise costs months.
Some jobs need a different class of tool entirely. If the agent has to click through a site with no API, you want Playwright or Apify, not a nicer prompt. If it has to run numbers, it needs a code interpreter. If it has to hear a call, transcription belongs in the pipeline before the model ever sees text.
And some jobs should not be agents. A saved search, a calendar rule, or a person who is good at the task will beat an agent on that task every time. I run 45 AI employees and I still do plenty by hand. That is not a failure of ambition. That is knowing where the machine is actually useful.
The Order Matters More Than the Answer
Context, then workflow, then tool. In that order it takes a week. In the other order it takes a quarter and usually ends with you back at the start, annoyed, holding a bigger invoice and the same drafts.
If you are trying to build AI agents for business right now, this is the pattern that will waste the most of your time. What's becoming clearer to me is that the people who get real work out of agents are not the ones with the best prompts. They built a place for context to live, gave the agent a workflow it could actually finish, and only swapped tools once the first two were provably clean. That is what an AI agent operating system is. Not a model. The structure around the model.
FAQ
How long should a context file be? Long enough to cover who you serve, what you sell, your pricing, your voice, and a few real examples. Mine runs about fifteen hundred words. Most people need more than a paragraph and less than a book.
Can a better prompt fix a workflow problem? No. Prompts change what the agent says, not what it can do next. If the failure is a missing step, a missing verification, or a missing handoff, rewriting the instructions will not help. Build the step.
Do I need an AI agent operating system if I only run two agents? You still need one place where context lives and one place where runs get logged. Start with a folder and a spreadsheet if that is what you have. The structure matters more than the stack, and it is much cheaper to put it in now than to untangle it later.
If you want the version of this you can build on Monday morning, I wrote it down. How to Build Your Own AI Agent Operating System walks you through the exact architecture I use, step by step. You can get it at a.mastermindshq.business/ai-os-book.