The Choreographed Agentic Workflow: Scaling AI Code Generation via Deterministic Governance
The Administrative Trap of AI Pair Programming
When engineers first adopt autonomous AI coding agents, the experience feels like magic. You describe a feature, and the agent spins up, modifies files, runs a test, and produces a working implementation.
But as you scale this workflow to manage entire systems or sequence multiple tickets, a frustrating pattern emerges: the human becomes a synchronous administrative bottleneck.
You find yourself continuously monitoring the agent’s progress, copying and pasting standard prompts, manually initializing feature branches, waiting for test suites to compile, running complexity benchmarks, compiling engineering memos, preparing merge requests, and cleaning up merged branches.
In this setup, you are no longer acting purely as an architect or director. You are working as a:
- Workflow scheduler
- State tracker
- Agent router
- Quality gate auditor
- Branch cleaner
- Release administrator
The bottleneck isn’t that a human is involved in the loop—human judgment is the single most valuable resource in software engineering. The bottleneck is that your involvement is synchronous and polling-based.
If an agent completes a task in five minutes while you are away making coffee, the entire pipeline sits idle for hours. To scale AI-assisted development, we must automate the administrative bureaucracy surrounding agent execution while preserving human control exactly where it matters.
The Three Systems of Agentic Delivery
To untangle this bottleneck, we must separate our development workspace into three completely decoupled systems:
- The Reasoning and Requirements System (Human + ChatGPT): The upstream collaboration engine. This is where we brainstorm features, explore trade-offs, identify edge cases, and formalize clear, structured tickets.
- The Execution System (Specialist Agents): The down-the-line builders (such as Antigravity and its specialized subagents). They write code, write tests, and generate technical evidence within tightly scoped sandboxes.
- The Control System (The Workflow Controller): The deterministic glue that tracks state, enforces governance policies, collects evidence, and manages transitions.
The most common mistake teams make is trying to force an LLM to play the role of the Control System.
The LLM Orchestration Fallacy
An LLM is a probabilistic system. It operates on heuristics, patterns, and probabilities. This makes it exceptional at creative problem-solving, code synthesis, and architectural advice.
However, it makes it a terrible workflow controller.
An LLM cannot reliably guarantee that a mandatory security audit was executed, that unit test coverage didn’t regress, that a specific version-controlled skill was applied, or that a code change didn’t violate scoping rules. If you ask an LLM to decide whether a workflow is allowed to advance, it will eventually hallucinate compliance, bypass critical gates, or route tasks to the wrong subagent.
The Control System must be entirely deterministic. It should be a state machine written in traditional, hard-coded software (such as Python, Bash, or SQLite) that enforces strict, rule-based policies.
The orchestrator recommends. The controller authorizes. The specialist executes. The evidence proves. The human approves.
Designing High-Leverage Asynchronous Gates
A choreographed workflow should run autonomously between designated human gates. Rather than continuously supervising execution, the human is paged only when a transition requires qualitative judgment.
For a robust software pipeline, there are exactly three places where human judgment is materially valuable:
Gate 1: Ticket Approval (Product & Scope)
Before an agent touches the code, you must determine: Is this problem worth solving? Is the scope defined by the ticket appropriate? Are the acceptance criteria clear?
Once approved, the deterministic controller takes over, initializes the feature branch, resolves the required specialist agents from policy, and starts execution.
Gate 2: Implementation Review (Conceptual Correctness)
After execution, you must verify that the implementation is conceptually sound. Unit tests and benchmarks prove that the code is syntactically and structurally correct, but they cannot verify if it solves the wrong problem, introduces an inappropriate abstraction, or damages the system’s long-term architecture.
Gate 3: Release Authority (Merge to Integration)
You must retain final release authority over what enters your primary integration branches. The agent pushes the branch, prepares the merge request, attaches the verified evidence, and pauses. Once you merge it, the controller automatically triggers branch cleanup and selects the next ticket in the queue.
The Anatomy of a Compact Decision Package
To make human gates effective, we must reduce the cognitive load of a review as close to zero as possible. An agent should never ask you to wade through raw terminal logs or guess what changed. Instead, the controller should compile a Compact Decision Package built on three pillars:
1. Separation of Fact from Interpretation
The package must clearly distinguish objective evidence from the agent’s subjective commentary:
- Objective Evidence (Facts): Green test counts, static typing results, exact line changes, cyclomatic complexity delta, public interface signature modifications, and new dependency additions.
- Agent Interpretation: Risk assessment, architectural commentary, areas of uncertainty, and suggested human review focus.
2. Exception-Based Reviews
Most successful tickets should be boring. Instead of listing every file that didn’t change and every test that passed, the package should hide compliant metrics and highlight deviations:
Checks Passed:
✓ Acceptance criteria met
✓ Unit tests green
✓ Typing strict
✓ Complexity stable
ATTENTION REQUIRED (Deviations):
⚠ One new external package introduced (aiohttp).
⚠ Public constructor signature changed in executor.py line 42.
⚠ Two existing test suites were modified rather than only adding new tests.
By focusing your attention exclusively on the anomalies, you can review and approve a ticket in seconds rather than minutes.
3. Decoupling Integration from Release
We must distinguish between merging code into integration (low-stakes, high-frequency) versus releasing code to production (high-stakes, low-frequency).
By automating the safe, evidence-backed accumulation of micro-tickets into an integration branch throughout the week, we eliminate the daily administrative drag. We can then reserve our deep, comprehensive architectural reviews for a single, scheduled release window.
Moving Toward Choreographed Autonomy
You do not need to build or adopt a complex orchestration platform to start choreographing your workflows. You can build it incrementally:
- Deterministic State Store: Track active tickets, branch names, completed stages, and paths to collected artifacts in a simple YAML or JSON state file.
- Policy-Based Routing: Define a static YAML configuration mapping ticket types to mandatory agents and quality gates:
refactor-policy: mandatory_agents: - python-coder - qa-regression-agent - smell-auditor gates: - ticket_approval - implementation_review - merge_approval - Evidence-Driven Transitions: A state is marked complete only when the deterministic controller verifies the existence of expected artifacts (such as a JSON test report or a markdown engineering memo).
By shifting our focus from flat, unstructured conversations to choreographed, policy-driven workflows, we remove the friction of administrative bookkeeping. We stop babysitting our agents and start choreographing them—freeing our minds to focus on intent, architecture, and design.