Intent Is the Missing Layer for Agents
The hidden coordination problem behind agentic work.
The hidden problem in agentic work is not instruction. It is intent.
Something changes when agents stop answering questions and start doing work. A prompt is no longer just a request. It becomes a control surface. You are handing a system partial authority over a workflow and hoping it understands not only the task, but the shape around the task: what matters, what is allowed, what has to be proven, where the work should land, and when it should stop.
This is where agent systems get strange.
The agent may read the repo, make a reasonable plan, use the right tools, and still produce an outcome that feels wrong. Not broken, exactly. Wrong in the way someone can follow the written request while missing what everyone meant.
That gap is intent.
Most agent failures are not dramatic reasoning failures. They are coordination failures. The system says “fix this issue” or “turn this spec into work” but does not say what kind of change this is, what proof counts, what risks matter, what depends on what, or who owns the next decision.
Humans carry that context around quietly. We know when a test failure is expected. We know when a comment is blocking. We know when “make it work” means the smallest patch and when it means rethinking the design. Agents do not know any of that unless the system gives it to them.
Prompts are too fragile
The usual answer is to write better prompts. Longer prompts. Stricter prompts. Prompts with capitalized rules and anxious checklists. That helps, but only up to a point.
A prompt is a fragile place to store operational intent. It is easy for the agent to miss, hard for the rest of the system to inspect, and usually gone after the run. Even when it works, nothing else can rely on it.
Intent has to become state
The lesson is simple: intent needs to become state.
An agent should not just receive “go do this.” It should receive a work object that says: here is the goal, here is the scope, here is the baseline, here are the acceptance criteria, here are the dependencies, here is the allowed writeback path, and here is the evidence required before this can move forward.
That sounds like process, but it is mostly just making explicit what human teams already keep implicit.
Once intent becomes state, the system can enforce it, display it, resume from it, audit it, and hand it to another agent without relying on memory or vibes.
Work graphs and ChangeSets
The pattern I keep coming back to is a work graph made of ChangeSets.
A work graph captures the shape of the mission: what needs to happen, what depends on what, what can run independently, and what should wait. It gives the system a view of the work that is larger than any single agent run.
A ChangeSet is the durable unit of intended change. It carries the goal, scope, baseline, acceptance criteria, required evidence, and promotion policy. Agent runs are attempts to advance a ChangeSet. They do not define it.
That distinction matters. If an agent fails halfway through, the ChangeSet still knows what it was trying to become. If another agent resumes, it can continue from the same intent instead of reconstructing the task from chat history.
Boundaries matter
This matters most at the boundaries where agents touch the outside world.
If an agent will create a pull request, it needs to know where the work is supposed to land before it starts writing. If it will update an issue, it needs to know whether it is shaping, committing, asking, or closing. If it will run tests, it needs to know what failure proves and what failure blocks.
Without that, the agent infers.
And inference is where the weirdness comes from.
The agent sees a repo, a branch, an issue, a test result, a comment, a partial implementation. It makes the most coherent local move. Sometimes that move is exactly right. Sometimes it is wrong because the missing information lived outside the system.
From the agent’s point of view, those cases look the same.
The fix is not to remove judgment from the agent. Agents need judgment. But judgment should operate inside explicit boundaries.
The agent can decide how to implement a change. The system should decide what change is being advanced. The agent can decide which files to edit. The system should decide what evidence is required before publication. The agent can explain uncertainty. The system should decide whether uncertainty pauses the workflow.
Put more bluntly:
The agent executes. The system carries intent.
What this changes
That split changes a few design choices.
First, the durable object should not be the run. A run is just an attempt. It can fail, pause, resume, timeout, or be replaced. If the run is the source of truth, every interruption raises the same questions again: what was this trying to do, what has already happened, and should the next agent start over?
The durable object should be the intended work. The run advances it. The run does not define it.
Second, evidence should be externalized. Agents are good at narrating what they did, but narration is not proof. If tests matter, record test results. If CI is the source of truth, record CI. If approval is required, attach approval to the work object, not to a disappearing chat transcript.
Third, agents need structured ways to stop. If the repo is not ready, the target is ambiguous, the acceptance criteria cannot be tested, or a credential is missing, the agent should not improvise. It should raise an exception. Stopping is not failure. It is part of the control loop.
Fourth, prompts should teach procedure, not carry truth. A prompt can tell the agent how to work: read context, create a failing test, wait for CI, request promotion, raise an exception if auto-merge fails. But the prompt should not be the only place where the system knows the baseline, status, evidence, or policy.
Prompts are for behavior. State is for truth.
Humans move up the loop
This also changes how autonomy feels. The goal is not to remove humans from the loop. The goal is to move humans to the right part of the loop. Humans should set intent, define policy, review exceptions, and inspect outcomes. They should not have to babysit every step because the system cannot remember what it meant five minutes ago.
Many agent systems accidentally recreate a very expensive intern. The agent can do work, but the human has to keep the whole context alive: what the task meant, what has already happened, what is safe, and what should happen next.
That is not autonomy. That is delegated typing with extra supervision.
A better system makes the context durable enough that the human can step back without the workflow dissolving.
The practical version
The practical version is not complicated:
Give every agent run a clear work object.
Put intent, scope, baseline, dependencies, and acceptance criteria on that object.
Treat evidence as system state, not agent prose.
Gate risky actions with policy.
Let agents raise exceptions instead of improvising.
Treat each run as an attempt to advance durable work.
Better models do not remove the need for structure. They make structure more valuable because they can act on it.
The next generation of agentic systems will not be defined only by smarter agents. It will be defined by better ways of supplying intent to agents: work objects instead of task strings, policies instead of reminders, evidence instead of claims, exceptions instead of silent drift, durable state instead of chat memory.
Agents do not just need to know what to do.
They need the system to know what it means.
Work with CognicellAI
CognicellAI helps teams design the operating layer behind production AI workflows: secure execution, durable state, telemetry, approvals, and governance that turn agent prototypes into systems the business can trust.
If your team is trying to move from “we have an agent prototype” to “we can operate this safely in production,” consult with CognicellAI.