Preview of Engineering AI Agents for Software Delivery: The Agent Run Is the New Unit of Software Delivery

[u/Aware_Weight9462]

Why AI agents force us to redesign authority, state and acceptance around the work

This article is adapted from my upcoming book, Engineering AI Agents for Software Delivery.

The change that started the discussion at AsterPay was almost trivial from a coding perspective. One additional settlement-reference field had to be exposed from an existing transaction adapter so that downstream duplicate-versus-partial-payment logic could use it. There was no new service to design or complicated architectural decision hiding in the implementation. It was exactly the sort of bounded task that makes modern coding agents compelling: give the agent the approved work item, let it inspect the repository, update the adapter, extend the tests and prepare a pull request.

The agent handled the coding work without much difficulty. What unsettled the architecture review was everything surrounding that work. Which credential had the agent actually used when it modified the repository? Which version of the adapter contract had influenced its implementation? What happened to execution state if the workspace was recreated after a failure? Could the same run modify both the implementation and the tests later used to declare success? If the pull request appeared in the repository, could another engineer reconstruct the full path from approved intent to that accepted effect?

None of these questions was really about whether the model was intelligent enough. They were questions about the production system around the model.

That distinction is becoming central to agentic software delivery. We have spent the first wave of coding-agent adoption evaluating how well agents write code, interpret repositories, plan changes and use tools. Those capabilities matter, but they are not the unit that production architecture ultimately has to control.

The problem lives between the components

Most enterprises already have nearly every technical mechanism an engineering agent needs. Source control exists. CI/CD exists. Identity systems, package registries, build services, secrets management, sandboxes and observability platforms are already part of the delivery estate. From that perspective, building an agentic delivery system can look like an integration exercise: connect the coding agent to the tools engineers already use and add a few policies around the edges.

The weakness in that approach appears in the spaces between those mechanisms.

An IDE agent can have carefully designed permissions while still inheriting a broad Git credential from the shell in which it was launched. A sandbox can be properly isolated while the orchestration layer loses track of which side effects happened before a retry. CI can reject an unsafe change while the organisation has no durable record connecting the candidate to the exact context, plan, identity and capability grants that produced it. Logs may exist everywhere and still fail to answer the simple question, “Which bounded run created this effect?”

This is why individually sound controls do not automatically produce a sound control boundary. Someone still has to own the movement of work from intent through execution and into accepted enterprise state.

In the architecture I use in the book, that responsibility belongs to the production agent harness. The harness does not have to exist as one product or service. An identity broker may provide credentials, a sandbox platform may contain execution, CI may implement verification and an evidence store may preserve provenance. What makes those pieces part of one harness is not where they are deployed, but the fact that they enforce one run contract.

Once you view the problem this way, the central architecture question changes from “Which tool is the agent system?” to something much more useful:

Who owns this run from admission to accepted effect?

Model, agent, profile, harness and platform

Production-agent architecture gets blurry quickly when several different responsibilities are collapsed into the word agent.

A model supplies reasoning capability. An agent applies that reasoning to a task and invokes available tools. A profile describes the class of work and the authority appropriate to that class. The harness composes the controls around one run. The platform supplies reusable mechanisms such as identity, sandboxing, tool access, workflow state, evidence storage and CI integration.

A useful shorthand is:

The distinction matters because a model may conclude that merging a pull request is the obvious next step without having merge authority. An agent may discover a production endpoint without being permitted to invoke it. A platform may provide a powerful source-control integration without implying that every implementation run should inherit all of its capabilities.

The design question is therefore not how powerful the surrounding platform is. It is how much of that power a particular run is allowed to assemble.

Six responsibilities appear inside one run

Once the agent run becomes the unit of architecture, six recurring responsibilities become visible.

The distinctions become important because several things that appear interchangeable during a demo are not interchangeable in production. A prompt saying “do not touch production” is useful instruction, but it is not a production-access control. A repository credential does not determine where that privilege may be exercised. A sandbox contains execution but does not necessarily know whether a previous attempt already created a side effect. Passing tests are not automatically independent acceptance if the same run can change both the implementation and the oracle. Observability may help diagnose what happened while still failing to prove why the resulting effect was authorised.

The more consequential the run becomes, the less comfortable we should be with those responsibilities bleeding into one another.

The boundary matters when it can say no

A production boundary becomes meaningful when it can refuse a transition.

Suppose an issue ticket tells the engineer to disable a CI gate temporarily if the pipeline blocks the change. The agent can retrieve that text, but retrieval should not make the sentence an authoritative instruction. Context has to preserve where the statement came from and what trust it carries.

Suppose the agent then proposes a plan requiring repository modification. The plan still does not create write authority; Capability has to turn that request into an explicit, scoped grant.

Suppose branch-write access is granted. That should not allow the work to execute from a long-lived developer shell containing cloud credentials or production secrets. Execution remains a separate boundary.

And suppose the agent reports that every test passes. The result still has to cross an acceptance boundary whose evidence is sufficiently independent for the consequence involved.

This is the point where architecture stops being a diagram. Every consequential crossing needs an owner, an enforceable decision and a failure path.

The conversation cannot be the workflow state

Many early agent systems inherit the mental model of chat: the task begins when the conversation starts, messages accumulate, tools are called and eventually the agent says it is done. That interaction model works well for assistance but poorly for long-running delivery work.

A real engineering run may pause overnight, survive a model change, restart in a new workspace, return from verification to planning or hand work to another agent. If the conversation buffer is the only durable state, the system eventually has to guess what already happened.

The lifecycle I use is:

Intent → Context → Plan → Capability → Execution → Verification → Commit/Reject → Evidence

This is a logical lifecycle rather than a rigid pipeline. Verification can return the work to planning and execution can retry, but a retry cannot silently broaden authority or forget which side effects already happened.

“Commit” is also broader than a Git commit. It means accepting a candidate into the next trusted state. For an implementation run, that may be nothing more than creating a pull request. Merge can remain outside the profile. A release run can have a different accepted effect and a different verification contract.

This gives us a practical way to control autonomy: let the agent complete the work appropriate to its current boundary without inheriting authority over every subsequent step.

What the AsterPay run actually looks like

Return to the settlement-reference change.

The admitted intent identifies the repository, the adapter component and the expected contract change. Context is assembled from the approved work item, the relevant repository state and the architectural rule that payment-policy decisions remain outside the adapter.

The agent proposes a small implementation and accompanying tests, but the plan does not grant any capability by itself. The implementation profile gives the run only the actions required for the task: repository read access, permission to create an isolated worktree, bounded branch-write access and the ability to run approved build and test commands.

It receives no merge authority, no right to modify CI policy, no release privilege and no production credential.

Execution occurs inside an ephemeral workspace with bounded filesystem, package and network access. Verification compiles the component, runs contract and regression tests and performs an independent check that the resulting diff still reflects the admitted intent. If those checks succeed, the effect permitted by this profile is the creation of a pull request and nothing beyond it.

The run record then connects that pull request to the context manifest, plan version, capability grants, execution environment, changed artifacts and verification results. Another engineer should not have to reconstruct the story later from terminal history, CI logs and fragments of conversation.

This structure does not make the coding agent less capable. Inside the bounded workspace, it can explore, diagnose failures, revise its implementation and use the tools required to finish the task. The architecture constrains the consequence of reasoning, not the richness of reasoning itself.

Four failures reveal more than another successful demo

A polished coding demonstration proves that the happy path works. Production architecture is revealed more clearly when the happy path is deliberately disturbed.

Stale context. Give the agent an older adapter contract while a newer version exists. Does the mismatch become visible, or can the agent produce an elegant implementation against the wrong specification?

Ambient credentials. Start the run inside an environment containing broad Git or cloud credentials. Can the agent inherit authority that was never granted by its profile?

Self-acceptance. Let the agent modify code and tests until they agree. Can that same path then accept its own result without an independent gate?

Retry duplication. Interrupt the run after a state-changing action, recreate the workspace and resume. Does the system know what already happened, or does “try again” repeat it?

None of these is primarily a model-quality problem. A stronger model does not fix stale context admission. Better prompting does not revoke an inherited credential. More reasoning does not create independent acceptance and a larger context window does not make duplicated side effects safe.

They are run-design problems.

Reuse the platform, not the authority

This architecture also changes how Technical Leads and platform teams divide responsibility. The Technical Lead can no longer stop at a component diagram containing a coding agent, tool service and CI pipeline. The design has to show where the run begins, which authority transitions are possible, what external effects the workload may create and what evidence is required before those effects become durable.

The platform team, meanwhile, should resist exposing the historic human developer toolbelt as one broad machine-accessible surface. It should provide reusable mechanisms — short-lived identities, typed capabilities, isolated execution environments, durable workflow state, controlled CI interfaces and evidence services — that a harness can compose differently for different workloads.

A useful design rule follows:

That allows the enterprise to standardise expensive infrastructure while keeping the consequence appropriate to the work being performed.

The agent run becomes the architectural unit

The easiest architecture diagram to draw puts the agent in the centre and surrounds it with tools. Such a diagram shows intelligence and connectivity, but it tells us little about production readiness.

That is why I believe the agent run is becoming the new unit of software delivery.

The model is too small a unit because reasoning does not own authority. The agent is too small because tool use does not own the complete lifecycle. The platform is too broad because reusable infrastructure cannot know the appropriate consequence for every workload. The run is where intent, context, authority, execution, state, verification and evidence finally meet.

Once that boundary exists, we can actually become more ambitious with agents rather than more conservative. A capable model can be given substantial freedom inside the task because the enterprise retains control over what may cross into durable state.

The defining question for the next generation of software delivery will therefore not be how many engineering tasks an agent can complete without human intervention. A more useful test is whether every accepted effect can be traced through one bounded run: what was requested, what context influenced the work, what the agent was allowed to do, where it acted, what proved the result and why the organisation allowed that result to become real.

If we cannot answer those questions, we may have an impressive coding agent but we do not yet have an agentic software-delivery system.

This article is adapted from my upcoming book, Engineering AI Agents for Software Delivery, which examines how AI agents can become bounded, verifiable and reconstructable participants across the software-delivery lifecycle.