From Individual Coding Agents to Supervised Engineering

Launching several AI coding agents is not the same thing as managing software development. A developer can open multiple terminals and give each model a task, but the resulting activity does not automatically preserve task dependencies, prevent conflicting changes, verify results, or reduce the time spent supervising. The more work runs in parallel, the more important it becomes to know which tasks are ready, what each worker is allowed to do, and which results have actually been accepted.

These questions shaped the next stage of Agent Operations, TENSA Engineering's supervised coding-execution system. Agent Operations began as a way to turn approved assignments into bounded coding work with known tests and independent review. It now serves as the engineering-execution foundation of TENSA Driveline, the broader project intended to connect software discovery and planning with controlled implementation. The combined Driveline workflow and its planned multi-project scheduler are not yet an operating unattended service; understanding that distinction is essential to the project's actual development story.

The first bottleneck was the operator

Early development established that Claude Code and Codex could carry out meaningful coding work within structured assignments. Agent Operations gained task-packet checks, workspace validation, prescribed test execution, artifact inventories, launch records, and process supervision. Fresh technical review also proved valuable when it found real defects that had passed available tests. These were useful components of a manually supervised workflow, and they made the results more reviewable than an unstructured conversation with a coding assistant.

The limitation was that a person still had to connect the stages. The operator prepared the assignment, launched the worker, inspected the result, arranged review, decided whether another repair was allowed, and preserved the next handoff. One bounded task could be manageable. Repeating those steps across many tasks created an expanding coordination burden, even when the coding models themselves worked quickly.

An attempt to solve that problem with increasingly elaborate process controls initially made things worse. By late September 2026, reviewer preparation could require roughly an hour and a half to two hours of operator time. In one instance, the reviewer then found a genuine blocking defect in about two minutes. The review was useful; the surrounding preparation had become disproportionate. Agent Operations was reset to an earlier validated implementation, with the discarded history preserved. The restored baseline passed 336 automated tests. That decision established a practical design requirement: new automation should remove measured operator work rather than add another layer of ceremony.

The managed-worker upgrade began with boundaries, not a scheduler

After the reset, Agent Operations did not immediately attempt to run many workers. The next objective was to take one approved task through more of its normal lifecycle without a person operating every transition. In October 2026, the upgrade planning defined a supervised architecture involving single-packet admission, bounded worker execution, independent read-only review, controlled repair, durable evidence, and eventual recovery and scheduling. The planning milestone was accepted on October 26 after independent review. That was acceptance of the plan and its constraints, not acceptance of a working managed-worker implementation.

The next milestone concentrated on the interfaces of Claude Code, Codex, and Grok. A supervisor cannot depend on a generic abstraction called “coding agent” if the underlying products report permissions, tool events, approvals, and exits differently. The experiments deliberately used small, disposable code fixtures so that observable behavior was easier to establish. A claimed permission denial without a recorded tool attempt was classified as unproven. A real denied command followed by continued Claude execution was a narrower demonstrated result. A fresh Grok review of Claude's actual change showed two separate roles could cooperate under manually established boundaries, but the reviewer did not run tests and the complete managed loop was not automated.

Those results helped identify a modest next implementation path: begin with a provider interface whose relevant behavior has actually been observed, keep deterministic validation and artifact checks, use a separately authorized read-only reviewer, and leave acceptance with the human. The intended sequence is deliberately incremental. An impressive dashboard or general-purpose provider router would not resolve uncertainty about what the underlying worker actually did.

Scheduling depends on accepted work, not available agents

A multi-project scheduler has to understand more than a queue of prompts. Consider three projects: one has a critical defect ready for repair, another has a feature blocked on an unaccepted interface, and a third has several independent tasks with distinct workspaces. Starting every available worker could waste resources or create conflicting changes. The scheduler must know which assignments are approved, which dependencies are satisfied, which resources are available, and whether prior results were merely produced or actually accepted.

This is the difference between concurrency and coordinated engineering. A project cannot safely consume a dependent component just because its builder said the task was complete. If independent review finds a blocking defect, downstream work may need to remain blocked. If a worker stops mid-task, the queue must preserve the existing candidate and evidence before considering another assignment. A ready task in one project may continue while a different project's task waits, provided the workers, workspaces, and resources remain properly separated.

The planned Agent Operations design therefore uses per-project queues and a shared worker pool governed by a supervisor. A future operator interface, AO Control, is intended to show ready work, active work, blocked tasks, evidence, reviews, and decisions requiring human attention. These are architectural goals under development, not features already demonstrated in a production multi-project environment. The dashboard should report actual task states; it should not invent progress percentages from model confidence or hide uncertainty behind a green status indicator.

The economics include review, repairs, and human time

A factory is not productive just because many workers are active. An inexpensive model that needs repeated fixes or extensive operator attention may cost more than a stronger model that produces an acceptable result sooner. The meaningful cost includes task preparation, compute, validation, independent review, repair attempts, failed launches, recovery, and human decisions.

Agent Operations has explored local coding models as potential future workers, but those experiments are not evidence that an automatic model router is ready. Local benchmark results may suggest candidates for narrow tasks; they do not establish permission behavior, tool compatibility, recovery, independent review suitability, or total operating cost. The approved direction is to integrate qualified local workers into the same Agent Operations execution system after the core cloud-managed path is demonstrated, rather than creating a separate local-model factory.

The project has a target of reducing routine task preparation to under fifteen minutes of human time, but that remains a target rather than a verified achievement of the future managed system. A meaningful evaluation will compare accepted engineering output against the full operator and compute effort required to obtain it. Counting model tokens, lines of generated code, or worker launches would be easier; those numbers would not answer whether the system is making software development more efficient.

The reset made this economic standard concrete. Additional process is not automatically valuable. A review that catches a blocker is useful; a workflow that takes two hours to prepare a two-minute review may need simplification. Good orchestration should reduce the repeated coordination needed for already approved work while keeping genuinely consequential decisions visible to the human.

Why Driveline connects planning to execution

Agent Operations is only one part of the larger engineering process. Before a coding task can be bounded, someone has to understand what is being built, examine an existing product when necessary, resolve competing requirements, and decide what success means. Argus Ventures is being developed to support that discovery and planning work. TENSA Driveline is the public identity for connecting approved planning with the supervised execution methods developed through Agent Operations.

That relationship should not be misunderstood as a claim that the complete integrated pipeline has already been built. The systems have separate development histories and responsibilities. The current Agent Operations foundation provides a manually supervised process with tested supporting components. The managed-worker upgrade has produced useful provider and review experiments, but unattended task recovery, coordinated multi-project execution, and an integrated discovery-to-delivery service have not yet been demonstrated end to end.

The separation is valuable. Product decisions and commercial commitments should be resolved before they become coding assignments. Execution tasks should stay within the authority they receive. Technical review should examine actual candidate evidence. Acceptance and delivery should require separate human decisions. Joining these responsibilities eventually should not blur the boundaries between them.

The next milestone is one complete managed task

The natural temptation is to move directly to a fleet of agents. The stronger engineering sequence is to prove one controlled assignment first: admit an approved packet, launch a worker whose observable interface is understood, capture its actual changes, run prescribed validation, obtain independent review, handle authorized repair when needed, and preserve a final human acceptance decision. Then test interruption and recovery deliberately. Only after those boundaries work together should the system pursue concurrency, dependency scheduling, or wider model routing.

This is the direction supported by the Agent Operations history through the November 2026 source checkpoint. The project has real demonstrations, accepted components, failed experiments, deliberate simplification, and unresolved gates. That is more informative than a claim that the factory is fully autonomous. The purpose of the next stage is not to remove the engineer from the process, but to reduce the amount of manual coordination needed to produce software whose scope, evidence, and acceptance are clear.

Continue reading

The first three articles in this series cover Enforced Boundaries, Tests Versus Acceptance, and Recovery After Failure. The TENSA Driveline project page explains the broader discovery-to-delivery direction; Controlled AI Systems and Safe Tool Interaction explain the underlying authority principles.