Moving from AI Code Review to the Outer SDLC Loop

I began building durable agent-work controls before loop and graph engineering became pervasive terms. The architecture points to a larger conclusion: code review is an essential verification layer, but governed software delivery requires an outer SDLC control plane.

AI code review was the first boundary I could see very clearly.

As coding agents increased the amount of code a team could produce, independent review became more important. Review was where context, judgment, and responsibility could re-enter a workflow that was producing changes faster than engineers could understand them manually.

But once you start designing around review, a larger systems question becomes quite difficult to ignore:

Who decides whether the work can advance after the agent finishes implementing?

A task may pass local tests and fail CI. It may pass CI and receive blocking review feedback. An agent may repair the problem, creating a new commit that makes the earlier evidence stale. A human may approve the pull request before another change lands. The code may merge while the expected release artifact never ships.

A review result contributes evidence. It does not own the durable state of that longer process.

The larger system is an outer software delivery loop:

intent → context → plan → change → verification → review → remediation → approval → release evidence → learning

A workflow graph can expose the route through that process. Production delivery still needs operating contracts for state, authority, evidence, retries, side effects, observability, cost, and human intervention.

That is the architecture I have been working toward through two open-source projects: ThreadLoop and Governed Agent Autonomy Patterns.

I started building them before “loop engineering” and “graph engineering” took the AI dev ecosystem by storm.

I was building the controls before I had the vocabulary

I created ThreadLoop in March 2026.

Its first commit on March 14 described a local-first system for preserving task intent, decisions, risks, validation notes, and reviewer guidance. I was concerned about a basic trust problem: important engineering context was trapped inside agent transcripts and temporary sessions.

A transcript can tell you what an agent said. It is a weak source of truth for what the task currently means, what changed in the repository, what evidence was collected, and which decision remains authoritative.

The project’s first milestone architecture described ThreadLoop as an explicit session-memory control plane for coding agents.

I created Governed Agent Autonomy Patterns on April 1 after the Claude Code source code leak happened.

The opening position of that repository was direct: AI coding systems needed a control plane around the model. Planning, permission, independent verification, tool trust, and visibility were treated as engineering boundaries for safe autonomy.

On April 2, the repository’s five-gate architecture made runtime accountability explicit. Operators needed to see execution state, trace activity, attribute usage and spend, and intervene when thresholds were crossed.

I am not claiming that I invented harness engineering, loop engineering, or graph engineering. I created these repos because durable context, bounded authority, independent verification, observable execution, and deterministic controls looked like necessary engineering work.

And then the terminology caught up to things I was already building around.

The projects evolved with the problem

ThreadLoop began as a way to preserve review context. That initial problem led naturally into lifecycle state.

If a coding task lasts longer than one agent session, the system needs to know which task is active, which repository revision it refers to, what changed, which evidence is current, and what action is permitted next. That pushed ThreadLoop from local artifacts into SQLite-backed session state, machine-readable protocols, deterministic next-action candidates, guarded transitions, proof receipts, repair rules, signed CI and review evidence, and a hash-linked audit ledger.

The current project models a software-delivery task as a governed lifecycle graph. A caller can ask what should happen next, but the caller cannot make a transition valid merely by requesting it. Policy and current evidence decide whether the transition is allowed.

Governed Agent Autonomy Patterns followed another path.

It began as a docs-first control model: plan before mutation, restrict dangerous actions, review new capabilities, verify independently, and keep execution visible. Those principles later became an executable governed coding-agent harness with exact-subject approvals, bounded tools, isolated execution, resource budgets, independent verification, and evidence-bearing receipts.

The repository also includes BoundaryBench, a deterministic conformance protocol for testing the gate logic against frozen cases and deliberately unsafe variants.

Both projects remain works in progress that I am building in public. Their responsibilities have become clearer as they have evolved:

• Governed Agent Autonomy Patterns controls one bounded attempt.
• ThreadLoop controls whether the longer-lived task may advance.
• An external runtime still decides when work should be scheduled.

Keeping those responsibilities separate has become one of the most important architectural decisions in this work.

Graph engineering is the topology

A workflow graph tells us which steps exist and how execution may move between them.

That matters. A graph can make planning, implementation, verification, repair, review, and human approval visible. Modern runtimes such as LangGraph also provide meaningful infrastructure for persistence, checkpoints, recovery, and long-running state.

Those runtime capabilities give us machinery for resumption. The application still owns the meaning of resumption.

Consider a graph that pauses for human approval before creating a pull request. While it is paused:

• the repository HEAD changes;
• the policy governing the action is updated;
• the agent’s tool permissions expand;
• the proposed PR content changes;
• the approval expires.

The graph may know which node comes next. The system still needs to determine whether the earlier approval authorizes the action that will now execute.

Retries expose the same distinction. LangGraph’s interrupt documentation explains that a resumed node begins again and that side effects before an interrupt must be idempotent. The edge back into the node does not prevent a second comment, branch, pull request, deployment, or payment from being created.

Production behavior requires additional contracts:

• stable run and operation identities;
• durable intent before an external effect;
• idempotency keys and deduplication;
• receipts proving what occurred;
• compensation or reconciliation when duplication cannot be prevented;
• evidence tied to the exact repository revision;
• approval tied to the exact action, target, scope, and policy;
• explicit retry, escalation, and stop conditions.

The graph exposes the route. These contracts make the route safe to operate.

The outer SDLC needs several authorities

I currently see five responsibilities in an agentic software-delivery system:

The graph runtime owns scheduling, wakeups, fan-out, and routing.

The execution authority controls what a particular agent attempt may do. It owns planning boundaries, permissions, trusted capabilities, isolation, budgets, and independent verification of that attempt.

Evidence producers observe the result. Repository state, deterministic tests, CI, code review, security checks, and release systems each provide different signals.

The lifecycle authority evaluates whether those signals permit the larger task to advance. It owns durable state, current-revision checks, transition guards, repair re-entry, and completion conditions.

Human and release authority handles the transitions that should remain accountable to people and operational systems: approval, merge, release, rollback, and acceptance of consequential exceptions.

A node reporting success cannot collapse all of these responsibilities into one claim.

The implementation agent is motivated to finish its attempt. The verifier is responsible for challenging the result. The lifecycle controller is responsible for deciding whether the task has enough current evidence to advance. A human remains responsible for decisions the organization must ultimately defend.

Nondeterministic reasoning needs deterministic boundaries

I do not want to make model reasoning deterministic. That would miss much of the value agents provide.

Agents are useful because they can explore, interpret ambiguity, generate alternatives, and respond to feedback. Those are inferential behaviors. Variability is part of the capability.

The operating boundaries around that reasoning need a different standard.

A state transition should either satisfy its guard or fail with a specific reason. An approval should authorize an identifiable subject. A proof receipt should refer to a particular commit. A budget should have a defined threshold. An idempotency key should resolve to one protected operation. An audit event should preserve what decision was made and on which evidence.

This is how you prevent nondeterministic reasoning from silently acquiring lifecycle authority.

The same principle applies to evidence freshness. “The tests passed” is too vague for a long-running system. Which tests passed? Against which commit? Under which setup? Using which policy? Was the workspace modified afterward?

A new commit can make an earlier test result stale. A capability change can invalidate tool approval. A changed patch can invalidate verification. A revised action can invalidate human authorization.

Evidence must be current, not merely present.

Observability becomes useful when it is connected to control

Agent observability is often discussed as a tracing problem.

Traces are valuable. They help us understand which model ran, which tools were called, how long each step took, how many tokens were used, and where a failure occurred. OpenTelemetry’s developing GenAI conventions already describe identifiers and attributes for agents, workflows, tool calls, evaluations, and usage.

But a trace showing that an agent called a tool does not establish that the call was authorized. A span showing that a verification node completed does not establish that its evidence still applies to the current code. A dashboard showing that the workflow is expensive does not enforce a spend limit.

Operational observability needs stable identities and an authority model around the observations.

Operators should be able to determine:

• which task and attempt are running;
• which repository revision is being changed;
• which execution phase is active;
• which tools and permissions are in scope;
• which evidence has been produced;
• which approvals are current;
• how much time, usage, and spend have accumulated;
• which threshold will cause the system to ask, block, stop, or escalate.

That last step turns visibility into runtime accountability.

ThreadLoop enforces a deliberate boundary here. Its audit ledger records lifecycle decisions, while its OpenTelemetry path is a read-only consumer of a verified export. Telemetry can help operators inspect and analyze the workflow. It cannot send an event back into ThreadLoop and authorize a transition.

Otherwise, a delayed collector, malformed event, compromised dashboard, or duplicated log could influence lifecycle authority.

Observability should make control easier to exercise. It should not quietly become the control.

Why the two systems remain separate

The division between my two projects can be reduced to three questions:

The next integration direction is a proof-carrying handoff between execution authority and lifecycle authority.

A governed run needs a stable identity bound to the task, repository, baseline revision, plan, capability set, policy, and budget. The harness can then return a narrow receipt describing the result and its independent verification. ThreadLoop can validate that receipt against current repository state before deciding whether the task may advance.

A successful governed run would still never advance the lifecycle automatically. The caller must request the transition, and the transition must re-evaluate the evidence that authorizes it. That distinction preserves the value of both systems.

Code review made the larger system visible

Code review was phase one because it exposed the responsibility boundary.

Independent review remains one of the strongest evidence producers in an agentic SDLC. It introduces judgment the implementation agent does not own, evaluates the change against broader context, and gives the workflow a reason to repair or stop.

At Qodo, this is why we treat review as infrastructure for code quality and governance rather than a final glance before merge. The review layer needs enough context to surface meaningful risk, and its findings need to participate in a workflow that can remediate and verify the result.

The outer loop carries that responsibility further.

It preserves what the task means, which evidence remains current, which authority is acting, why a transition was allowed, what shipped, and what the organization should learn from the outcome.

I am continuing to build ThreadLoop and Governed Agent Autonomy Patterns in public because I want these operating contracts to be inspectable and challengeable. The useful feedback now is deeper than whether the graph looks sensible.

Where does your agentic workflow lose authority, evidence freshness, or observability when it has to survive a real retry, a changed commit, a delayed approval, or a release that does not go as planned?