Months before loop and graph engineering took the AI dev ecosystem by storm, I started building two open-source systems around durable state, governed execution, independent verification, and observable control. This post is about what building ThreadLoop and governed-agent-autonomy-patterns has taught me about software factories. Let’s dive in.

A software factory is a system that repeatedly turns engineering intent into software we can verify, ship, operate, and improve. That requires a way to preserve intent, govern execution, evaluate evidence, and recover when the work veers off from its original plan.

A graph establishes the possible routes for a software factory and codifies them. But what evidence should the code or pipeline provide to advance through each subsequent development phase? And who (or what mechanism) decides whether or not the work needs another verification pass?

Those are the questions I’ve been building around with ThreadLoop and Governed Agent Autonomy Patterns (GAAP).

I started ThreadLoop on March 14, 2026, to preserve task intent and review context beyond an agent session. GAAP followed on April 1, with patterns for controlling what an agent could do and how its work would be verified.

Looking back through the Git histories of those projects made me realize I was looking to address how we handle non-deterministic systems whose reasoning can change from one attempt to the next.

These repos were already organized around durable state, feedback, verification, observability, and authority before loop and graph engineering became pervasive language across the AI dev ecosystem most recently. IBM was still describing loop engineering as an emerging practice in July. And OpenAI published about harness engineering back in February.

So the vocabulary caught up to problems I was already building around.

ThreadLoop models an AI-assisted software-delivery task as a governed lifecycle graph.

It’s meant to preserve the meaning and progress of engineering tasks as you build. An agent session can end, a different agent can take over, and the task must persist and determine what is allowed to happen next.

The current implementation stores state in repository-local SQLite. It evaluates explicit transition requests against the repository, a proof plan, verification evidence, review evidence, and work repair history.

Here’s the simplified flow through its current PR lifecycle:

Ultimately, agent activity needs a durable system of record outside the agent’s own narration. And I want a task to retain its meaning and its rules across agents, interruptions, and revisions.

Governed Agent Autonomy Patterns was inspired from the Claude Code source code leak.

The industry was getting better at making agents capable of generating and executing changes. I was less convinced that we were getting equally good at controlling what those agents were allowed to do, verifying what they had done, or intervening while they were doing it. But the source code from the Anthropic team was a great piece of evidence for how to build coding agents with multiple governing layers at play.

The patterns I identified from the source code leak is what I care about for the future of agents for software development. Faster code generation without planning, permission, independent verification, tool trust, or runtime accountability feels operationally reckless at scale in real world engineering settings. And so we need fortified systems, operating models, and processes.

For that work in this AI era, agents need boundaries. And I see boundaries as a mechanism that could make autonomy sustainable on the path toward software factories.

GAAP works inside an individual agent run. It evaluates boundaries before an executor performs the protected effect. A protected effect is an explicitly described operation against something outside the model’s reasoning, such as a filesystem, process, network destination, or external service.

My project has recently graduated from documented patterns in Markdown to a Rust coordinator and runtime:

I implemented a five gate model that appears at different moments in the run:

Nondeterministic reasoning needs deterministic boundaries.

Essentially, I want agents to explore implementations while the authority to perform an operation sources from the harness surrounding the agent.

For example:

This is where I’m seeing determinism play its part in software factories: state transitions, authorization, evidence binding, budgets, idempotency, retry rules, stop conditions, and audit records.

Observability belongs in that same control surface, too.

I want to know the current phase, task identity, run identity, repository revision, policy version, execution target, approval state, capabilities used, evidence producer, usage, spend, and available intervention points.

And evidence carries through the system to determine what “good enough” is and if the system can allow code to proceed to the next gate. When the code, policy, scope, or capability changes, earlier evidence should be considered “stale” and verification should run all over again. Loops within loops.

My proposed integration would look like this:

A graph runtime can implement many of these controls. Graph engineering is the process topology for this. The software factory, however, needs contracts for evidence, authorization, side effects, replay, retries, repair budgets, intervention, release proof, and continuous learning.

My next milestone is to build the connection between a governed agent run, a verifiable receipt of what it produced, and a ThreadLoop decision that either advances the workflow or explains why it can’t advance. Hopefully, this can help me define more quality control specs for shipping code (semi-) autonomously.

From there, I want release evidence and operational feedback to share the same rigor for quality and governability.

That is the software factory story I’m building toward.

The AI dev ecosystem now has more vocabulary for discussing these ideas. This language makes architectures easier to compare, although it’s sometimes overwhelming and a bit too hype-driven for my taste. Luckily, I’ve remained focused on these two projects to tinker with what’s possible.

And as these systems evolve in public, I would love for other builders to challenge these boundaries. Our learnings will teach us more about the software factories we aim to build!