The news
A piece on context engineering for AI agents from JD Raimondi, Head of Data Science at MakingSense, draws a hard line between prompt engineering and what actually makes agents work in production: designing the full information environment a model has access to at each step of a multi-step task. The argument is that model choice explains almost none of the gap between a clean demo and an inconsistent production agent — context architecture explains most of it.
Our take
This is the most important thing GTM teams can internalize right now, and almost none of them have.
Here's the mechanism: an AI agent doesn't reason across your entire workflow. It reasons from whatever is sitting in its context window at the exact moment it has to make a call. System instructions, retrieved documents, tool definitions, prior outputs, memory — they all compete for limited space, and the order they arrive in shapes what the model does. A great prompt at the top of the workflow cannot compensate for missing state twenty steps down.
For a single-turn chatbot, this is mostly invisible. You write a good prompt, you get a good response. But the moment you're building anything that plans, calls tools, branches on results, and continues — a prospecting agent, a lead routing workflow, a multi-step campaign orchestration — context becomes architecture. You're not writing instructions anymore. You're designing an information system.
What breaks in production almost always traces back to one of three failures: the agent had too much irrelevant information and picked the wrong path, it had too little state information and lost the thread, or the tool definitions were ambiguous enough that the model guessed wrong. None of those are model problems. They're context problems.
The good news is that fixing them doesn't require rebuilding from scratch. The article frames this correctly: audit what's actually landing in the context window today, separate what's stable from what changes call to call, and give the agent only the tools and information relevant to the step it's currently on. That's operational discipline — the same kind that makes any complex system debuggable.
For GTM teams, this reframes what "implementing an AI agent" actually means. It's not a prompt. It's not a model selection. It's information architecture for a system that has to make decisions.
So now what?
- Audit your context before you debug your prompt. If your agent is behaving inconsistently, check what's actually in the context window at the failing step — not what you think you passed in.
- Separate stable instructions from dynamic state. Your system prompt shouldn't be doing the job of runtime memory. Design them as distinct layers.
- Scope tools to steps. Giving an agent access to every tool at every step is the agentic equivalent of an all-permissions API key — it introduces noise and invites wrong turns.
The teams that will build reliable GTM agents aren't the ones with the best prompts — they're the ones who treat context as something to design, not something to wing.