The coding agents finished their tasks. The release was still broken.

Consider an enterprise application team using separate agents for implementation, tests and documentation. One works from an earlier requirement. Another tests a different revision. A third describes behaviour inferred from a ticket rather than verified in the application.

In this illustrative scenario, the delivery lead becomes an integration service for the agents. More output has arrived, but the team still lacks a reliable answer to a simple question: is this specific change ready for these users?

Our Forward Deployed Engineers would work with product owners, developers, QA, operations and security reviewers to examine the handoffs around a small class of changes. We would define acceptance at the business boundary, including roles, exceptions and expected failure behaviour.

A requirement such as “managers can export team data” needs resolution: which managers, which teams, which fields, which period and which access restrictions? An ontology can provide shared definitions for those concepts. Product and security owners must still approve the intended rules.

A Deep Agents-based harness is one potential foundation for longer tasks requiring planning, context management and delegation. It is not a separate assurance layer that magically makes agent output correct. In the proposed application, the harness would support a shared accepted objective, version-linked work and durable progress.

The coordinating system would require evidence against the same candidate revision before treating a change as complete. A failed integration check would return the issue to the responsible workstream. A handoff or interrupted session would preserve unresolved work instead of starting another contradictory attempt.

Automated tests, permission checks and business acceptance would remain distinct. Passing one would not imply passing the others. The first pilot would produce reviewable changes and evidence packets, with deployment controlled through the team’s existing release process.

Anthropic’s work on long-running harnesses highlights progress records and verification across sessions. It offers useful engineering lessons, not proof that a particular business application is ready for autonomous release.

Measure total time from an agreed requirement to an accepted change, including review, rework and exception handling. Include model, infrastructure and human costs. Track access-control regressions and escaped defects as separate adverse outcomes.

DORA’s delivery measures include change lead time, change fail rate and deployment rework. They provide a useful broader operating context. A faster coding step is not a successful investment if the release becomes less stable or senior reviewers spend longer repairing the result. The pilot should improve the delivery system as a whole.