A field report on how one technology leader used governed AI agents to expand engineering capacity, and what the experiment exposed about orchestration, control, and failure.
Zero Circle builds AI-native project finance infrastructure for mid-market climate, energy, and resiliency projects. We underwrite them into bankable records, match them to capital, and settle the transactions after close. We are an early-stage company with a small engineering team and a platform that has to serve pilots, customer-specific work, platform evolution, and production operations at the same time.
This paper is a field report on six weeks of engineering using a different operating model. A senior technology leader, an AI orchestration layer, and disposable specialist agents were used to shape a new platform foundation, establish governed delivery, provision a development environment, and operate bounded infrastructure changes. During this period, the technology leader remained out of implementation coding while the governed delivery process handled 40 pull requests, 36 of which were merged, alongside dozens of bounded execution, review, remediation, and reconciliation cycles.
The experiment did not aim to remove the human from engineering or claim that autonomous software engineering had been solved. Its focus was narrower: whether an experienced technology leader could move away from implementation and toward strategy, architecture, verification, and consequential decisions without lowering engineering standards.
The startup engineering capacity problem
Early-stage companies often need more engineering specialties than it makes sense to staff permanently. Product discovery, pilots, platform work, infrastructure, security, and operations coexist, but demand for each specialty is uneven. We were no exception.
The conventional alternatives are both expensive in different ways. Defer architecture, testing, security, or operational discipline and later productization becomes harder. At the other extreme, practices designed for larger engineering organizations can introduce more coordination overhead than an early-stage company can justify.
Startups often need mature engineering capability before they have the scale to support it.
Can one technology leader operate a broader engineering capability through governed AI agents while maintaining engineering rigor, independent verification, and human control over consequential decisions?
What we tested
The experiment had three actors. A Technology Leader retained product intent, risk tolerance, architectural direction, and consequential decisions. An Orchestration Service maintained the larger engineering objective and coordinated work. Disposable Specialist Agents supplied bounded execution and independent review.
The operating setup was deliberately simple. The orchestration layer maintained continuity across the larger objective, while specialist workers were short-lived and task-bounded. Workers could be replaced freely because authoritative state lived outside any individual session.
The framework itself was being built while it was being used. Role boundaries, design-review depth, evidence requirements, and orchestration behavior evolved in parallel with the platform and infrastructure work. This was not a laboratory exercise in designing an ideal lifecycle and then applying it unchanged.
Failures in delivery changed the operating framework, and the changes were immediately tested against real work.
An earlier precedent outside engineering
We had already explored a related idea through Pathfinder, an internal AI-assisted outreach and deal-origination tool that allowed one person to supervise prospect research, campaigns, and follow-ups that previously required more manual coordination. Repetitive execution became more configurable and delegable while important judgment remained human.
Engineering posed a different challenge because its decisions accumulate durable technical state.
Code persists, architecture compounds, and infrastructure remembers bad assumptions. A locally plausible change can still be wrong because of migration constraints, security boundaries, operational dependencies, or decisions that sit outside the immediate task.
That is why the experiment did not treat engineering as a queue of independent prompts. The orchestration layer had to maintain the intended outcome, challenge unnecessary work, and evaluate each bounded task against the larger system.
Why coding agents were only one layer
Repository-aware agents can plan, modify code, run tests, review changes, and participate in deployment. But implementation remains downstream of harder questions: what problem is being solved, which constraints apply, what evidence will establish correctness, and how a local change fits the wider system.
That context rarely lives in one repository. It is distributed across product intent, architecture decisions, task history, implemented state, operational evidence, and external systems. Coding agents therefore became bounded execution capabilities inside a larger engineering decision system, not the engineering organization itself.
A broader shift in software engineering
We were not encountering these questions in isolation. Industry work on agentic software engineering is increasingly extending beyond code generation toward orchestration, verification, and governance across the delivery lifecycle.
Gartner argues for verification-first delegation to AI agents across the software lifecycle. Deloitte describes software-engineering roles shifting toward orchestration, validation, and strategic oversight. Anthropic's AI-Native SDLC playbook describes a broader redesign of the software lifecycle around agentic execution, persistent artifacts, automated review, and human accountability at consequential decision points.
Our claim is narrower. This paper is not an argument that the industry has solved autonomous software engineering; it is a field report on what happened when we tried to build an operating model around these emerging ideas, including what failed.
The operating model
The three actors stayed constant across the experiment, even as the responsibilities and process around them evolved.
Human technology leader
The technology leader retained responsibility for business intent, risk tolerance, and consequential decisions, with attention focused on outcomes, constraints, trade-offs, and transitions where mistakes were expensive or difficult to reverse.
Orchestration Service
The Orchestration Service maintained the larger engineering objective, reconstructed current state from durable records, coordinated bounded work, and reconciled material results before deciding what happened next. That next step might be remediation, another specialist, independent review, completion, or a request for human authorization when required.
Disposable specialist agents
Execution was delegated to focused agents with bounded roles, authority, acceptance criteria, evidence requirements, and stop conditions. Specialist agents could be assigned to business analysis, architecture, QA, implementation, security, infrastructure, remediation, and independent review. The agents themselves were disposable.
Model 1: A specialist-led engineering lifecycle
The first model recreated many of the specialist perspectives found in a conventional engineering organization: business analysis, QA, architecture, engineering design, implementation, security, and independent review.
The point was the separation of concerns, not the number of roles. Business intent could be challenged before implementation, architecture could establish constraints, QA could derive tests independently of the implementation agent, and engineering design could translate accepted intent into bounded construction work. Reviewers could challenge a proposed change without inheriting the producer's reasoning.
Model 1 proved useful in practice. Over our early years, we had accumulated product, market, and customer learning through pilots, customer work, and repeated iteration. The challenge was to translate that learning into a clearer view of the platform we would need next, one that could support future growth without simply extending earlier design decisions and short-term additions.
The specialist perspectives helped translate a broad platform objective into durable engineering decisions. Architecture decisions established boundaries and migration assumptions. Engineering specifications translated those choices into implementable contracts. The target architecture separated stable platform responsibilities from business capabilities and external integrations, preserved controlled coexistence with the existing system, and defined dependency directions that future modules would have to respect.
The first platform foundation then tested whether those decisions could survive contact with implementation. It established the technical base, automated validation, and architecture checks that turned some design rules from written conventions into enforceable engineering constraints.
That was meaningful progress, but it is important not to overstate it. This phase established the foundation and structural shape of the new platform; it did not yet implement the substantive business capabilities described by that architecture.
Where Model 1 reached its limits
The first model's weakness became visible in infrastructure, but not because specialist roles were inherently wrong. The initial approach was proportionate to what looked like a bounded development-environment problem. It preserved useful properties such as explicit authorization, least privilege, fail-fast checks, and independent verification without introducing more machinery than the problem appeared to require.
As the work progressed, however, the problem changed shape. What had looked like a bounded infrastructure task began accumulating dependencies, exceptions, recovery logic, and operational handling around each new obstacle. Each decision could be justified in isolation. Together, they were becoming disproportionate to the outcome we were trying to achieve.
The orchestration layer was doing what we had asked of it: maintaining lifecycle state, dispatching bounded tasks, reconciling results, and advancing the next valid step. That was not enough. It was still too focused on progressing the current work rather than challenging whether the overall direction remained sensible.
The turning point came when the problem was reframed at the system level rather than treated as another local infrastructure obstacle.
The resulting architecture did not discard the valid security and authority lessons from the earlier path. It moved toward more standard infrastructure patterns and let mature tooling absorb more of the convergence and recovery burden. The important failure was not that one specialist produced a bad answer. It was that locally rational work could continue after the system-level direction had stopped being proportionate.
Local execution can be narrow; technical direction cannot.
What Model 1 taught us
Process has to keep earning its cost
Role separation, review gates, and durable artifacts reduced real risk. But process can become self-justifying. At one point, work on improving the agentic framework itself was frozen when non-blocking governance refinement began competing with visible platform outcomes. Governance exists to improve delivery, not to become the product.
Local correctness is not system correctness
A bounded task can be executed correctly and still be the wrong task. That was the failure mode the infrastructure episode made visible. From then on, work had to be judged at two levels: is this task correct, and does it still serve the larger engineering objective?
More state does not necessarily create more clarity
Early versions of the model accumulated substantial documentation in an attempt to reduce ambiguity and give each worker more context. In practice, that could have the opposite effect. Superseded decisions, long histories, and repeated explanations made it harder to distinguish what was current, authoritative, and relevant to the next decision.
The useful record was much smaller: current decisions, contracts, evidence, and unresolved risks needed to continue safely. Code and infrastructure state remained authoritative in version control, while task contracts, decisions, evidence, handoffs, and open risks were retained in the engineering system of record. A new worker or orchestration session could then reconstruct what it needed without depending on conversational history.
The goal was not more context, but a smaller, authoritative record of what still mattered.
Architecture needs an engineering-design bridge
Early iterations also exposed a gap between accepted architecture and implementation. Architecture could define consequential boundaries without specifying enough about interfaces, failure behavior, sequencing, and validation for a particular implementation task. Engineering-design ownership and independent design review were added where the risk justified them.
This was an important example of the operating framework changing because real delivery revealed a missing responsibility.
Model 2: Adaptive Technical Director Orchestration
The infrastructure episode produced the central change in the operating model. The orchestration layer evolved from advancing valid workflow transitions to acting more like a Technical Director: maintaining system-level direction, challenging whether work should exist, and adapting the specialist structure and review depth to the needs of the problem.
It now had to ask: should this work exist, is the problem decomposed at the right level, does a locally correct task still serve the larger outcome, how much specialist and review depth does the problem justify, and has a simpler engineering path emerged?
The three actors remained unchanged. The technology leader retained business intent, risk boundaries, and consequential authority. The orchestration layer maintained system-level direction. Specialist agents supplied bounded execution and independent review.
What changed was the operating logic. System-level technical direction became an explicit orchestration responsibility, while specialist capabilities were invoked according to the needs of the problem rather than arranged as permanent stages in one required lifecycle.
One control path remained invariant. The orchestration layer defined and delegated a bounded task; the worker executed it; and every material result returned to the orchestration layer for reconciliation against the larger engineering objective. From there, the next step could be remediation, another specialist, independent review, completion, or human involvement when consequence, risk, intent, or strategy required it.
We have now exercised this model on infrastructure. The harder test still lies ahead: applying it to the delivery of substantive business capabilities on our new platform.
Role depth follows the shape of the work
A substantive product capability may justify much of the richer Model 1 structure: independent business analysis, architecture, engineering design, test design, implementation, security review, and integrated acceptance. A bounded infrastructure correction may need only an executor, targeted independent review, and live verification.
The point is not fewer roles by default. It is to bring in the right independent perspectives for the risk at hand.
There is no single mandatory lifecycle.
Correctness needs independent evidence
AI makes implementation abundant. It does not make correctness abundant.
A worker's output was therefore treated as a claim to be tested, not as evidence of its own correctness. The goal was not to make the technology leader personally inspect every generated change, but to make important failures observable before they became accepted state and to ensure that progression depended on evidence that could challenge the producer.
The controls mattered because they caught real mistakes. Architecture rules were converted into automated checks so invalid dependencies could fail mechanically. Infrastructure work stopped when it reached the edge of its authority rather than silently widening permissions.
Our first controlled deployment provided a more concrete example. A malformed runtime configuration reached pre-activation checks and failed before the deployment became active. There was no automatic retry. The failure returned to the orchestration layer, was traced to its source, and required a targeted correction and fresh evidence before another deployment could proceed.
A separate security review exposed a subtler weakness: a verification control could confirm that the expected metadata was present without proving that the evidence actually corresponded to the exact inputs that had been inspected. The evidence looked stronger than the guarantee it provided. Progression stopped until the control was corrected and independently reviewed again.
These episodes reinforced a broader principle:
Assurance cannot depend on one senior person becoming the universal inspection bottleneck.
It has to be distributed across clear intent, bounded authority, independent checks, automated tests, architectural constraints, runtime evidence, and explicit control at consequential transitions.
For substantive business capabilities, we will need another layer. Unit and integration tests can pass while the intended business outcome is still wrong. In the next phase, we will extend independently derived acceptance testing to substantive business capabilities, add a small set of automated end-to-end journeys, and include selective human verification.
Evidence, not confidence, decides whether a consequential transition is allowed.
What this changed in practice
The practical benefit was not an abstract claim about replacing an engineering team. It was the ability to bring architecture, engineering design, QA, implementation, infrastructure, security, and independent review to bear when needed without permanently staffing every specialty or pulling the technology leader back into routine implementation.
The scarce resource was not simply coding capacity. It was senior technology attention. The operating model allowed more of that attention to remain focused on product and technology strategy, architecture, sequencing, risk, verification, and decisions with lasting consequences.
The evidence is operational rather than a productivity benchmark. The experiment demonstrated that meaningful engineering work could move through a governed delivery system while specialist execution remained elastic and senior involvement remained concentrated on higher-order decisions. It does not establish an equivalent headcount, an ROI multiple, or a general productivity claim.
Limits of the experiment
This remains one company's field experiment. The engineering work and the operating model evolved together, so the evidence is observational rather than the result of a controlled experiment, and causal claims should be treated cautiously.
Our new platform is also still a foundation. The work described here established architectural boundaries, delivery controls, infrastructure, release mechanisms, and the structural base for future capabilities. We have not yet demonstrated substantive business capabilities delivered end to end through the adaptive model.
Long-term maintenance, resilience, production-scale behavior, broader product and UX workflows, and portability across AI providers also remain largely untested. Provider diversity may eventually provide another source of independent challenge, but disagreement between models would not itself establish correctness.
The model should therefore be read as a field-tested operating hypothesis, not as evidence that one person can substitute for a mature engineering organization.
What comes next
The next test is the one that matters most: delivering substantive business capabilities through the adaptive model while preserving independent specification, architectural coherence, testability, bounded authority, and end-to-end evidence of the intended business outcome.
That phase also needs better measurement. Useful signals include intervention frequency, lead time, review yield, remediation, escaped defects, recovery behaviour, cost, and how reliably a fresh orchestration session can reconstruct the current engineering state.
As evidence accumulates, more low-risk execution can be delegated within explicitly enforced authority boundaries. High-consequence transitions should remain explicit human decisions until evidence justifies changing that boundary.
Conclusion
We began with a familiar startup constraint: the engineering capability we required was broader and more variable than the specialist capacity it made sense to staff permanently, while senior technology attention needed to remain focused on the decisions that shape the system.
Model 1 organized work through a specialist-led engineering lifecycle. It helped turn accumulated product and customer learning into architecture, engineering contracts, an executable platform foundation, and governed delivery. It also exposed an important limit: locally correct work can continue even after the overall direction has stopped making sense.
Model 2 emerged from that lesson. The orchestration layer took on a more explicit Technical Director role, maintaining system-level direction while the specialist lifecycle became adaptive. Specialist capabilities could be invoked according to the shape and risk of the problem rather than assembled into one mandatory process.
Code-generation speed was one of the least interesting outcomes. The more consequential possibility is that execution can become elastic while system-level judgment, independent verification, and human control over consequential decisions remain deliberately preserved.
Our framework is unfinished. The next threshold is whether the same operating model can deliver real business capabilities without weakening those controls or pulling senior technology attention back into routine implementation.
Selected external context
Gartner: Delegation Framework for Agentic AI in the SDLC (2026)
Deloitte: The impact of agentic AI in software engineering (2026)