How We Built Our AI Agent Operating Infrastructure

We built our AI agent operating infrastructure — what we call our Agent Operating Infrastructure (AOI) — by stacking four layers: a Conductor workforce that defines agents, teams and workflows; a Claude Max-plan execution layer that backs each agent with a real claude -p coding session; an Agent Bridge that binds a session to a seat and lets seats hand work to one another over a message bus; and the BOG operating model (Build · Operate · Govern) that gives every team the same shape. On top of that infrastructure runs a daily content engine — the very thing that drafted this article. The result is a platform that increasingly builds and operates itself, with humans setting strategy and holding the release gate.

We did not set out to build a novelty. We set out to solve a concrete problem: a five-vertical platform needs more engineering throughput than a small human team can supply, and the cheapest unit of additional capacity available to us is an AI agent with a real coding environment. Everything below follows from treating that agent as a first-class member of the org rather than a chatbot bolted onto the side. Here is how each layer works, and why we made the choices we did.

Conductor — the workforce, not the runtime

Conductor is where the workforce is described. It holds the agents (each a named seat — AI CTO, COO, PM and the rest), the teams (such as the DevOps team and the QA team), and the workflows that string tasks together. Conductor is deliberately a thin coordination layer: it knows who exists and what they are responsible for, but it does not, by itself, write code. That separation matters. By keeping the org model in Conductor and the execution elsewhere, we can reorganise the company — add a seat, re-point a reporting line, spin up a new team — without touching the machinery that actually does the work.

The Claude Max-plan execution layer

The execution layer is the part most teams get wrong, so we were explicit about it. A Conductor agent on its own is just metadata; to do anything it needs a working coding environment. We back each agent with a host-side Claude Code session via tools/conductor/run-agent.sh, which launches claude -p against the repository on a real machine using our Claude Max plan.

We chose a host-side CLI over a serverless function for a hard technical reason: claude -p cannot run inside a serverless runtime — there is no CLI binary and no subscription context there. So the agent-provider lives in the cw/host layer instead of in the web app. The pay-off is large. Each agent gets the full toolchain — file edits, Bash, git, the database — at a flat Max-plan cost rather than a metered per-token API bill. That single decision is why our cost-control discipline targets metered SaaS (build minutes, managed Postgres) and leaves the agent fleet as a flat-rate line item.

Running real coding sessions on a shared repository creates its own hazard: two agents editing the same working tree will corrupt each other's commits. We solved that with git worktree isolation — any session that will commit works in its own checkout, so agents run genuinely in parallel without standing on one another. The execution layer is therefore not one big session but many small, isolated ones, each scoped to a single unit of work and torn down when it is done.

The Agent Bridge — cw connect and the message bus

An execution session is powerful but anonymous. The Agent Bridge gives it an identity and a way to collaborate. When a session runs ./tools/conductor/cw connect <seat>, it binds to that seat — inheriting the seat's role, inbox and memory. From then on the session can send and receive work over a message bus using verbs like cw handoff, cw reply and cw broadcast. A QA seat can hand a release note to the COO; the CTO can hand a drafted article to the CMO. Because the bus is durable, a handoff survives the session that sent it — the next session to connect to that seat picks up the inbox. The bridge also enforces guardrails: any message that asserts human authority without a cited source triggers a provenance warning, so no agent can quietly mint a decision in a human's name.

BOG — one shape for every team

BOG, our operating model, says every team is a self-contained unit that Builds, Operates and Governs its own surface, with light first-line governance in-team and central standards as the backstop. It is fractal: the DevOps team is the gold-standard template, and new teams copy its role shape rather than inventing their own. BOG is the structure that lets us add capability without adding coordination overhead — the model scales because each cell looks like every other cell.

The daily content engine

The daily content engine is AOI applied to itself. A scheduled routine briefs a content seat, the seat drafts an article against our pillars, and the draft lands in the resources system as status='draft' — never auto-published. A human (the CEO) reviews and publishes from the admin console. This article is a live example: an AI CTO seat wrote it, and Michael Quan reviews it before anyone reads it in production.

That last point is the whole philosophy in miniature. The infrastructure is autonomous in execution and human-gated at consequence. Agents decide and ship within their mandate; humans hold strategy, spend and the production release gate. It is how a small team runs an enterprise that spans Tutorwise, Traderwise, Trainerwise, Beautywise and Adspots — and how we keep velocity high without letting the machine make the calls that should stay human.