# The Right Agent at the Right Time

> Source: <https://dev.to/juststevemcd/the-right-agent-at-the-right-time-bml>
> Published: 2026-07-15 18:25:09+00:00

There are two ways I keep watching teams get AI wrong, and they are mirror images of each other.

The first team fights it. Every line an assistant writes gets rewritten by hand, because trusting it feels reckless. Generation is treated as a threat to be contained rather than a capability to be aimed. These teams perform a lot of ceremony and capture almost none of the speed, and they tell themselves that is the price of quality.

The second team surrenders to it. Requirements live in a chat log, the assistant produces a pull request nobody can properly review because there is no written intent to review it against, and the definition of done is "it ran once on my machine". This is fast right up until the moment it is catastrophically slow, usually around the third feature, when the context window fills up and the model starts quietly contradicting decisions it made an hour earlier.

Both teams are asking the wrong question. They are asking how much AI to use, as if the answer sits on a dial between zero and one. The useful question is different. Which work belongs to a machine, at which moment in the life of a change, and who holds the gate between one moment and the next?

That question has a good answer, and once you have it you can build a way of working around it. I want to walk through a development lifecycle that puts the right agent at the right time, wire it to the standards that keep the architecture honest, and describe the thin runtime you would put underneath to hold the whole thing together.

Two methods do the heavy lifting, and I am going to lean on the pieces rather than re-argue them.

Shape Up gives us the outer track. Work is shaped into a bounded pitch before anyone commits to it, then bet on at a betting table, then built by a team that owns the whole thing for a fixed appetite. The word appetite matters. We do not estimate how long a change will take and then miss the estimate. We decide how much the change is worth, fix that budget, and vary the scope to fit. When the work threatens to overrun, we cut scope, not corners, and we never quietly extend the clock.

OpenSpec gives us the engine inside that track. A shaped pitch is expanded, with a single command, into concrete artefacts: a proposal that says why and what, a set of specs whose acceptance scenarios define done, a design that records the approach, and a task list. The work is carried out against those specs, published, reviewed, and then folded back into a living source of truth. The specs sit in the repository next to the code, so the next change starts from an accurate picture instead of a fading memory.

There is a gap in that description, and it is the gap this piece is really about. The specs tell you what a change does. They say nothing about how your team has decided to build things. Left to itself, a model filling in a design reaches for whatever architecture is most common in its training data, which is almost never the architecture your team actually agreed on. You end up with a pattern you banned two years ago, or a queue where you standardised on handling things in the request, drizzled through the codebase one well-meaning pull request at a time.

The fix is to recognise that a healthy lifecycle has not two sources of truth but three, and to keep them apart.

The pitch owns why. It is transient, it belongs to one change, and it evaporates once the work is bet on or dropped.

The specs own what. They describe the behaviour of a specific change, and they get archived into a living description of what the system does.

Architectural Decision Records own how. They are durable, they cut across every change, and they record the standing decisions your team has made about the way you build. An ADR is a small, deliberately boring document: a status, the context that forced the decision, the decision itself, and the consequences you are signing up for. You do not edit an accepted one. You supersede it with a new one, so the trail of reasoning survives every change of mind.

Here is the move that makes ADRs earn their place in an AI-driven lifecycle. The accepted decisions become the constraints every agent works within, and a change that needs a new decision cannot proceed on an agent's say-so. Standards flow into the specs and the conversations, and new standards flow back out under human control. Consumed on the way in, produced on the way out, and a person in the middle of both.

If you list the stages a change moves through, shaped, bet on, proposed, built, published, reviewed, archived, and then ask a simple question at each one, who actually does the work here, you get three answers, not one.

Some stages are pure human judgement, and an agent has no business touching them. Deciding the appetite is a judgement about worth. Placing the bet is a decision about what we are willing to not do. Accepting an architectural decision is a commitment the whole team lives with for years. No model gets a vote on any of them.

Some stages are the machine drafting and a human correcting. Expanding a rough pitch into a detailed spec is exactly the kind of structured, high-value work a reasoning model is good at, and exactly the kind of thing a human should read and correct rather than write from a blank page. Drafting a pull request description from a spec is the same shape of work.

And some stages are effectively automatic. Folding a merged change back into the source of truth is mechanical. It should simply happen.

That is the whole design, and most agent tooling I see misses it by assuming every stage wants the same treatment. The question is never how clever the model is. It is where the authority sits. Architecture is the sharpest case of human authority in the list. An agent may apply an accepted decision, or draft a proposed one, and that is the ceiling of what it is allowed to do.

Once you see the lifecycle this way, what you build underneath is small. It is a workflow engine that knows the sequence of stages, knows which of them require a person, knows which agent belongs to each, and moves a change forward one step at a time. Nothing exotic. If you have ever built a workflow engine, you already know the shape.

What earns its keep is not the cleverness of the runtime but the rules it refuses to break. It will not skip a stage that needs a human. It will not run an agent at a stage where no agent belongs. It will not let a change outrun its appetite. And it will not advance a change on the back of an architectural decision no human has accepted. Four rules that teams normally rely on willpower to follow, moved into something that does not get tired and does not have a deadline.

That last point is worth saying plainly. A rule that lives only in a wiki page is a suggestion, and suggestions lose to deadlines every time. A rule the runtime enforces is one the team can actually rely on, because it holds at six in the evening when the person driving it would have waved anything through.

Walk the stages and the shape of "the right tool at the right time" stops being a slogan.

At shaping, a fast and cheap critic argues with the draft pitch. It is not there to shape the work, because shaping is human judgement. It pushes back: is this appetite honest, or is a big piece of work wearing a small one's clothes, where are the rabbit holes you have not patched, and, importantly, does this work imply an architectural decision we have not yet made. Surfacing that last one before the betting table means the bet is placed knowing a new decision is coming.

At betting, there is no agent at all, and that absence is the most important design choice in the whole system. Betting is a decision about what we are willing to sacrifice this cycle, and I do not want a model anywhere near it. Deliberately wiring in nothing, and making that nothing visible rather than accidental, is how you stop the automation creeping into a place it should never reach.

At proposing, a reasoning model expands the pitch into the full spec, and this is where the standards do their real work. The accepted decisions are handed to the model as constraints, so the design it produces conforms to what your team agreed rather than to what is statistically popular. When the design fits inside those decisions, it cites the ones it stands on, so a reviewer can trace the architecture back to the record that authorised it. When the design escapes them, the model does not improvise. It drafts a new decision record, writes up the context and the tradeoffs, and stops. A design that contradicts an existing decision is handled the same way, as a proposal to supersede that record, which is a heavier call again and just as firmly a human one.

At building, a coding agent drives the work against the task list and reports where it is on the hill, still figuring things out or executing what it already understands. The agent is fast and trustworthy on the downhill, on the known work. When it reports itself stuck on the uphill for too long, that is your earliest possible warning, long before a missed task count would tell you anything. The standards ride along here too, because they constrain the code as much as the design.

At publishing, the drafting is mechanical and the action is not. An agent writes the pull request description from the spec and the decisions it cited, and then it stops. A person opens it. Anything that changes the world outside the repository stays behind a human hand.

At reviewing, a first pass by a model saves the human reviewer from wasting their hour. It checks two mechanical questions before a person looks: does the implementation satisfy every scenario in the specs, and does it conform to the decisions the design cited. A change that quietly wandered off its stated architecture gets caught cheaply, which leaves the human free to judge the only thing a human can, whether this is genuinely the right solution.

The temptation is always to remove gates for speed, so let me defend them.

Three kinds matter. The judgement gate, on shaping, betting, and review, where the work waits until a person approves. The architecture gate, where a proposed or superseding decision holds the change until a human rules on it. And the side-effect gate, on publishing, merging, and deleting, actions that reach outside the repository and must never fire on a model's confidence alone.

The failure mode of agent tooling is rarely a bad line of code. Review catches that. It is an irreversible action, or an unexamined architectural choice, taken confidently at the wrong moment. You put those behind gates precisely so the gate holds when the person driving it is tired and behind and would have clicked yes to anything.

The appetite is not advisory. When a change blows its budget, the work does not roll forward and nobody negotiates an extension. It goes back to shaping, to be re-shaped with what was learned and bet on again from scratch. The default is that unfinished work stops, not that it drags, and that default is the single healthiest habit Shape Up gives you.

The standards behave the same way, enforced rather than hoped for. Every spec and every agent conversation is bounded by decisions a human accepted, so the architecture cannot drift one convenient pull request at a time. And every new decision surfaces as its own gate rather than hiding inside a diff, so the team decides architecture on purpose, with the reasoning written down, at the moment the choice is actually made.

It is worth being clear about how these records relate to a plain conventions file, because most teams already keep one of those. A conventions file is the distilled current rule an agent follows day to day. It tells the model what to do. A decision record is the reasoning behind a rule, captured at the moment it was made, so that when someone later proposes to overturn it they are arguing with the original context rather than guessing at it. Keep both, and generate the conventions from the accepted decisions if you can, so the two never drift apart.

You might reasonably ask why a lifecycle needs a runtime at all, when the tools already give you the commands and the decision records are just files in a folder.

Because the process is exactly the thing that gets skipped under pressure, and the person under pressure is the worst possible guardian of it. The value of the runtime is that it holds the gate the human would not. It refuses to advance past review late in the day. It trips the breaker on the change everyone is emotionally committed to finishing. It leaves betting to people by having nothing to delegate it to. And it will not let a design invent architecture, because a proposed decision parks the change until a person signs the record. The discipline stops depending on everyone remembering to be disciplined and becomes a property of the system.

The heart of all this, the sequence of stages, the gates, the appetite, the decision log, has nothing to do with any particular framework or even any particular language. It is a workflow engine with mixed authority and a standards layer, and I would build it to stay independent of any framework and let the AI tooling plug in at the edges. Which, you will notice, is itself an architectural decision, the kind of thing that belongs in a record with its context and its consequences written down. The runtime ends up built the way its own decision log says to build things, and that is the whole idea quietly working on itself.

*Next time I want to open up the two agents I skated past here, the critic that argues with your pitch and the reviewer that reads AI-generated work for both correctness and conformance, because those are the two places where getting the model's role slightly wrong quietly poisons everything downstream.*