An Agentic Factory Is an Architecture, Not a Tool Stack

I am building a SaaS product as a solo developer. Today, I do most of that work inside Herdr.

I open one pane with Claude Code and use it as a supervisor. That pane orchestrates other panes and terminals, also running inside Herdr, where Codex CLI and Claude Code handle separate software-development phases such as requirements, implementation, and testing.

The workflow already works. The next architectural question is not which coding agent is smartest.

It is where responsibility should live when the work stops being one edit in one file.

A single agent can inspect a repository, change code, run commands, and explain the result. That does not mean one session should own the objective, the plan, the implementation, the review, and the verdict.

When those responsibilities remain inside one opaque loop, it becomes difficult to answer simple questions: which constraint shaped the implementation, what was actually checked, and who decides what happens next?

I am choosing to evolve that workflow into a more explicit factory. The planned change is to replace the Claude Code supervisor pane with CAO, while keeping Herdr as the execution environment for the coding CLIs. Hermes becomes the operator-facing direction and context layer above it.

The cost is real: more setup, more handoffs, more state to observe, and more components to maintain. The decision is worth piloting only if separating the supervisor from the workers produces better continuity and reviewability than the workflow I use today.

This is the same pressure that made architecture concrete for me in Architecture Became Real When AI Made Me Faster: once implementation moves faster than review, an implicit boundary is no longer a harmless preference.

Capability is not responsibility

The simplest alternative is attractive: give one agent a repository, a powerful model, and enough tools to carry the work from request to pull request.

A second alternative is the workflow I use today: a Claude Code supervisor inside Herdr creates and coordinates worker panes for the individual SDLC phases.

Both can work for bounded tasks. The current Herdr workflow is already more structured than a single agent, but its supervisor role is still embedded in a Claude Code session. It becomes less convincing when a change crosses several boundaries: a request-context change that affects authorization, persistence, tests, and deployment; a migration that requires sequencing; or a feature whose implementation and review should not be owned by the same uninterrupted context.

The problem is not that one agent cannot perform each step. The problem is that capability across steps does not create separation between them.

A factory needs stages with evidence at their boundaries.

Orchestration hides several different jobs

The word orchestration is too broad to describe the architecture precisely. The systems I am evaluating occupy different layers.

Hermes is the operator-facing direction and delegation layer in this design. Its documented delegation model creates child agents with isolated context and their own terminal sessions. Whether that produces the right durable project continuity is an architectural question I still need to test.

CAO is the coordination layer. It coordinates multiple coding CLIs and lets them remain native processes rather than turning every worker into an abstract API call.

Herdr is different. It is an experimental, agent-aware terminal backend for CAO. Its lifecycle events—such as working, idle, done, and blocked—are signals that may be more useful than polling terminal output. They are not, by themselves, proof that the system understands software state correctly.

Archestra sits closer to a control plane. Its documented components include agent runtime, MCP orchestration, LLM and MCP proxies, guardrails, knowledge access, and observability. It addresses governance and infrastructure around agents rather than simply coordinating local coding sessions.

Port sits at the organizational edge of the model. Its Context Lake, workflows, agent management, interface builder, and governance features describe how agents fit into a larger software delivery lifecycle.

These systems are not interchangeable winners in a product comparison. They are examples of separable responsibilities.

The architecture I am choosing

The current workflow and its planned evolution are:

The current workflow and the planned evolution, with responsibilities separated by layer.

In the planned design, Hermes handles direction and context. CAO replaces the supervisor role currently played by a Claude Code pane and handles coordination. Herdr remains the execution surface and lifecycle signal layer for the coding workers. Codex and Claude Code handle bounded implementation or review tasks inside the repository.

Those are designed responsibilities, not yet observed facts about the complete system.

Archestra and Port remain possible later layers. Archestra becomes relevant if MCP servers, credentials, policy, isolation, and observability need a dedicated control plane. Port becomes relevant if the factory grows into an organizational system with many services, owners, standards, and workflows.

The architecture therefore has an extension path without requiring every component on day one.

A boundary should produce an artifact

Ownership is useful only when it leaves evidence.

For a cross-boundary SaaS change, the core path might look like this:

Each boundary should leave evidence that another person—or another session—can inspect.

The task brief should preserve the objective and constraints. This extends the argument in Planning Is Where AI Work Becomes Reviewable: a decision should become inspectable before execution makes it expensive to change. The delegation record should identify the worker and its bounded responsibility. The worker should return changed files, assumptions, and unresolved issues. Review should produce a verdict and verification evidence.

This does not make the process bureaucratic. It makes the boundary inspectable.

The questions I want the architecture to answer are concrete:

• What artifact records the original objective?
• What marks a handoff as complete?
• What signal distinguishes blocked from finished?
• What evidence is required before a reviewer accepts the result?
• Where is the next owner recorded?

If the answer is “the operator remembers,” the factory has not externalized enough responsibility.

Designed, observed, unresolved

A useful architecture must distinguish three kinds of statement.

A designed responsibility is what a layer is supposed to own.

An observed responsibility is what the running system actually handles reliably.

An unresolved responsibility is a boundary the pilot still needs to test, such as retry ownership, recovery after interruption, or the meaning of a worker’s done state. That is also a context problem: as The Problem Is Not Prompting. It Is Context Decay. argues, a later session can recover code more easily than the intent that made the code safe.

Without this distinction, an architecture diagram quietly becomes a production claim.

I am not making that claim yet.

I am evolving a working composition because it gives direction, coordination, execution, and implementation different places to live. The pilot will determine whether making those boundaries explicit is worth its cost for a solo developer.

A factory is not a pile of tools. It is a decision about where work, state, and evidence should live.