There is a conversation I have watched happen dozens of times. A team sits down to build an AI agent. Someone writes a long prompt, detailed and well-intentioned, that describes what the agent should do. They call it the spec. They paste it into the builder. They start testing. Something is off. They keep editing the prompt. The prompt gets longer and messier. The agent gets harder to predict. <\/p>\n\n\n\n
What went wrong is not the quality of the writing. What went wrong is that three separate documents were collapsed into one, and in the process, each one got compromised. <\/p>\n\n\n\n
Building a reliable AI agent requires three distinct documents, each answering a different question. Confusing them is one of the most common and most fixable causes of agent failure. <\/p>\n\n\n\n
The spec answers one question: what is this agent supposed to do? <\/p>\n\n\n\n
Not how. Not when. Not in what order. What. <\/p>\n\n\n\n
A good spec defines the problem being solved, the specific user it serves, what the agent is allowed to do, what it is not allowed to do, what inputs it can use, what outputs it must produce, what good looks like, what failure looks like, and what governance constraints apply. It is the foundation document. Everything else is built on it. <\/p>\n\n\n\n
The spec is written before any planning begins, and it is not the same as a plan. <\/p>\n\n\n\n
The most important characteristic of a good spec is that another person could build from it without guessing. If the spec requires interpretation, it is not finished. If the boundaries are implied rather than stated, it is not finished. If the outputs are described in general terms rather than concrete ones, it is not finished. <\/p>\n\n\n\n
“A helpful assistant for sales teams” is not a spec. “A Microsoft 365 Copilot agent for account executives preparing for first-call customer meetings, using only approved public company information and user-provided context, producing a one-page brief with company summary, likely priorities, and three discovery questions, with no pricing commitments, no legal language, and an instruction to ask for clarification when the meeting objective is unclear” is a spec.\u00a0<\/p>\n\n\n\n
The difference is not creativity. It is specificity. <\/p>\n\n\n\n
The implementation plan answers a different question: how will we deliver the spec in phases? <\/p>\n\n\n\n
This is where most teams skip ahead. They have the spec, so they build. But what they build is usually too much. The first version tries to do everything, does most of it poorly, and is difficult to test.\u00a0<\/p>\n\n\n\n
A phased implementation plan forces a different decision: what is the minimum\u00a0version that proves the core value? That is the MVP, the thing you build first. Everything else comes later, in separate phases, each with its own scope and validation criteria.\u00a0<\/p>\n\n\n\n
A good implementation plan has three things a spec does not: phase boundaries, exit criteria, and a rollback rule. <\/p>\n\n\n\n
Phase boundaries define exactly what is in the MVP and exactly what is excluded. The exclusions are as important as the inclusions. Without them, scope drifts forward. Someone\u00a0says\u00a0“while we’re here we might as well add the CRM integration,” and the MVP becomes a full-featured v1 that was never\u00a0properly tested.\u00a0<\/p>\n\n\n\n
Exit criteria define what must be true before moving to the next phase. Not “when it feels ready.” Specific pass\/fail conditions.\u00a0<\/p>\n\n\n\n
The rollback rule defines what happens if a phase fails validation. Not an assumption that\u00a0you’ll\u00a0figure it out. A plan.\u00a0<\/p>\n\n\n\n
The implementation plan is written after the spec is approved and before any building begins. It is not the spec. It does not change what the agent is. It defines how you will deliver it.\u00a0<\/p>\n\n\n\n
Build instructions answer a third question, the only one that lives inside the builder: what exactly do I configure right now, for this specific phase? <\/p>\n\n\n\n
Build instructions are\u00a0phase-specific. They are not the spec. They are not the plan. They are the translation of the approved current phase into language that can be pasted into the builder and produce predictable\u00a0behavior.\u00a0<\/p>\n\n\n\n
Good build instructions are explicit about what the agent must do, what inputs it is allowed to use, what outputs it must produce, what it must refuse, when it must ask for clarification, and when it must escalate. They include test\u00a0scenarios\u00a0so the builder knows whether the configuration worked.\u00a0<\/p>\n\n\n\n
The reason build instructions exist as a separate document is context control. If you carry your spec and plan into the configuration session, the model will pull from all of it. Features from later phases will appear in the MVP. Scope will drift. Testing will become harder because you will not know whether a failure is a Phase 1 problem or a Phase 3 problem that snuck in early. <\/p>\n\n\n\n
Build instructions keep the session honest. You are building one thing. Just this thing. Nothing else yet. <\/p>\n\n\n\n
There is a practical rule that follows from all of this: each document should be created in a fresh conversation. <\/p>\n\n\n\n
Not because the technology requires it. Because discipline requires it. If you write the spec in one session and then keep going into planning and then into build instructions, the context from earlier in the conversation bleeds into later work. Assumptions carry forward. Scope that was meant to be excluded gets quietly included. You end up with a single long thread that is doing three jobs poorly.\u00a0<\/p>\n\n\n\n
Fresh sessions produce cleaner artifacts. One spec. One plan. One set of build instructions per phase. Each focused. Each testable. Each honest about what it is.\u00a0<\/p>\n\n\n\n
Before anyone opens the builder, a well-run agent project produces three files. A spec, typically a page or two. An implementation plan with the phases, exclusions, and exit criteria. And build instructions for the current phase, clear enough to paste in with minimal rewriting.\u00a0<\/p>\n\n\n\n
Those three files are the difference between a two-week build and a three-month rebuild. They are also the difference between an agent that does what you intended and one that does something adjacent to it, confidently and consistently. <\/p>\n\n\n\n
This is exactly the structure Insentra brings to every AI Momentum engagement. Before any agent goes live, the spec is complete, the phases are defined, and the build instructions are reviewed. That discipline is not overhead. It is the whole reason the outcomes land. <\/p>\n\n\n\n
If\u00a0you’re\u00a0wondering whether your organisation is ready to build an AI workforce, start with AI Momentum. The programme helps leaders move beyond experimentation by identifying practical AI opportunities, defining clear use cases, and building a roadmap for operational adoption. Before you invest in agents, automation, or copilots, make sure\u00a0you’re\u00a0solving the right problems in the right order.\u00a0<\/p>\n\n\n\n