The session that has been building our software all day has never read the code.
It has opened issues, groomed a board, sequenced the work, merged three pull requests, and kicked off the next slice. It has not opened a single application source file. That isn’t a limitation I’m working around. It’s the design I’m working toward.
Most teams reaching for AI coding agents start from the opposite instinct: one capable model, pointed at the whole repo, doing everything. It works impressively for an afternoon, then quietly falls apart. This is how we stopped that — an operating model instead of a prompt.
The thesis is one line: the main session coordinates; it does not build. The building is done by an org of specialist sub-agents that spin up, absorb the context they need, do one job, hand back a result, and disappear. The coordinator stays lean so it can keep coordinating; the specialists carry the weight, then set it down.
We first ran this on a real production build — a multi-tier trading platform we’re developing — and it’s now how we build everything.
The mistake everyone makes first
The failure mode of a single all-purpose coding agent isn’t intelligence — the models are more than capable. It’s context.
A coding session accumulates. It reads a schema, then a service, then three components, then a stack trace, then the docs to understand the stack trace. An hour later every read is still in the window, most no longer relevant, all competing for attention. The thread degrades: the agent forgets decisions made twenty minutes ago, re-reads files, contradicts its earlier work. It’s not a bug in the model; it’s a property of stuffing an entire build into one finite context window.
So the scarce resource isn’t the model. It’s the context window of the session you’re steering. Spend it on code and you have no room left to think. Everything that follows exists to protect that one resource.
The orchestrator: a coordinator that never touches the code
The main session — the one I actually talk to — has exactly one job: orchestration. It behaves like a good engineering manager, technical enough to know exactly what to delegate and to whom.
Concretely, it grooms the board, decides the next slice, dispatches the right specialist for each piece, checks CI and merges, and synthesizes what comes back. That’s it. It writes almost no production code. Any non-trivial investigation, diagnosis, or build gets handed off rather than done inline.
This is a discipline, not a default. The pull to “just quickly fix this one thing” is constant, and every time the coordinator gives in it loads the file, the surrounding code, and the test into its window — forever. The rule is strict: the orchestrator’s context holds the state of the work, never the content of the work.
The board is the system of record
If the orchestrator holds almost nothing in its head, something else has to hold the state of the project. That something is GitHub Projects.
The board is not a status dashboard. It is the memory of the project — the durable, external system of record that lets the orchestrator stay empty. Epics map to canonical feature areas; stories are issues under them; tasks are sub-issues. Bugs must link both a test case and a parent story, so nothing floats. Labels carry the taxonomy: feature area, client surface, sprint, status.
One convention matters more than it looks: work here isn’t binary between “in progress” and “done.” A feature whose data, service, and API are complete and tested but whose front end isn’t built yet is neither — we track it in a deliberate, documented in-between state that encodes our whole delivery model (below) onto the board, so it tells the truth about where a feature really is.
Because the board is external and durable, any session can reconstruct the project’s state by reading it. The orchestrator doesn’t remember what’s in progress; it looks. That’s what makes the coordinator disposable and the project persistent, not the other way around.
The live board, mid-build: epics are canonical feature areas; the progress bars roll up their stories.
The org: three waves, not a swarm
The specialists are where the work happens. We stood up an entire software organization as sub-agents — around seventeen roles, each with a sharp charter. The headcount matters less than the order they run in: a real org has a flow of control, and so does this one. Three waves.
Wave one, before a line of architecture: product and information design. This is the part most AI build setups skip, and the part we lean on hardest. The product manager owns what we’re building and why, and grooms it onto the board. The UX designer owns the flows. And the role we treat as non-negotiable — and that most people haven’t met: the information architect.
If you know the title at all, it’s probably from UX, organizing menus and labels. Ours owns far more: the entire vocabulary of the system — the taxonomy, the ontology, the glossary. Not just what things are called on screen: the services, the database tables and columns, the core code structures, all the way out to metric labels and log fields. One concept, one canonical name, everywhere. The IA runs first, harvesting those names before anything else consumes them, because names are load-bearing: when a feature carries the same name from the UI through the service to the table to the log line to the dashboard, you can correlate — trace one thing across every layer, in the app, in the instrumentation, in operational reporting. Get it wrong and you’re renaming things across six layers three weeks later, or worse, debugging a system where the same concept answers to four names. You never parallelize the work that establishes names with the work that uses them, so the IA runs alongside the PM and UX, ahead of the architects.
Wave two: the architects draw the blueprints. Informed by the PM’s intent and the IA’s vocabulary, the architects — data, systems, application, and just as deliberately operations and security — emit the blueprints, standards, and structure the engineers build to. They don’t write feature code; their success is measured one way, adoption. A blueprint nobody follows is a failure no matter how elegant, so they specify clearly, then audit adherence. That operations architecture holds a first-class seat here — not a thing bolted on after launch — is deliberate: observability, service-level indicators, alerting, and runbooks are designed into the first slice, because “we’ll add monitoring later” is how you end up flying blind in production.
Wave three: the engineers build to spec. Data, services, and front-end engineers, each manufacturing to the architects’ blueprints, shipping tests with every change, documenting the handoff to the next. Alongside them sit the operations engineer and the SRE — again, core, not an afterthought — plus security and infrastructure. QA verifies independently, and no bug may exist without a linked test case and a parent story. Then the architects audit the build against the spec, and the loop closes.
Through all of it, the orchestrator engages the coordinating roles at the start of every slice — PM, IA, UX, docs — not just the engineers.
The org that operates, not just builds
One moment shows why the operations roles earn their seats. During a build, our SRE sub-agent diagnosed a failing scenario, traced it to root cause, wrote the analysis, and filed four corrective-action tasks — each landing on the board as a story for the owning engineer, who fixed it. That is the whole argument for first-class operations agents: the system doesn’t just get built, it gets operated and self-corrects through the same board and handoffs as everything else. Build, observe, diagnose, correct — a closed loop, staffed end to end.
Ephemeral by design: context that evaporates
Here’s the mechanism that makes it pay off — the part most people miss.
When the orchestrator dispatches a specialist, that sub-agent gets its own fresh context window. It reads the schema, the services, the docs, the stack trace — all the heavy context the work requires — inside its own window, does the job, and returns a synthesized result: the branch it pushed, the decision it made, the answer. Then it’s gone, and every file it read goes with it.
None of that weight ever lands in the orchestrator’s context. The main session sees a two-paragraph summary, not the two thousand lines the specialist waded through to produce it. That is the difference between a session that degrades over hours and one that keeps rolling: the coordinator’s window fills with decisions and state (compact, durable, cheap) while the code, documentation, and dead ends live and die inside disposable workers. You get an agent reading ten thousand lines to fix a bug without paying for those ten thousand lines in the session you keep alive all day.
It comes with sharp edges we learned the hard way. You don’t peek into a running sub-agent to check progress — reading its transcript pulls all that quarantined context back into the window you were protecting, defeating the point. You trust the completion signal and wait. And parallel builders each need their own isolated git worktree: we learned that the day two agents sharing one working tree collided and one’s push landed on the other’s branch. Parallelism is a feature, but only with isolation.
How work actually moves: the tank tread
The org and the board serve a specific delivery model, refined over three decades of shipping systems that had to stay up: data-first, bottom-up, in vertical slices. Every feature is built from the bottom of the stack up — data first (modeled, migrated, real), then the service, its API, its tests, then a thin front-end touch to validate the slice. The front end lags on purpose: early on, “done” means the data and service and API are built and tested, not that the UI is finished. I call it the tank tread — each feature one link laid bottom-up, the platform advancing like a tread laying its own track. It’s why the board needs that “data and service done, front end pending” state: the tread mid-rotation, where “done” or “not started” would both be lies. Data engineer hands to services engineer hands to front-end engineer, QA verifying across it all. The process and the org chart are the same shape, which is not a coincidence.
A feature rolling through the tread, live: the IA lap first, then data → systems → services → a thin UX/FE touch. Five of seven laps done; deploy still Todo.
What didn’t work
The honest parts are the useful parts.
The first version over-trusted parallelism and under-invested in coordination — spinning up architects and engineers while skipping the PM and information architect. Engaging the coordinating roles from the start of a slice, not as cleanup, was a correction I made more than once.
And the board drifts unless the automation that adds every issue to it is switched on: a system of record only works if nothing escapes it.
None of these were failures of the AI. Every one was a failure of process, and every fix was an org-design fix. Which is the whole lesson.
Why it works: an org chart is an architecture
Strip away that this is AI and the design is deeply familiar. Separation of concerns. Single responsibility. A durable system of record so no component holds global state. Specialists with clear contracts and clean handoffs. These are the principles that make a distributed system stable, applied to the team building it.
That’s the reframe. We didn’t invent a new way to use a language model. We took the operating model of a good software organization — the one you’d design if the “engineers” were expensive, context-limited, and best used in short bursts — and made it literal. The org chart became the architecture. The model isn’t the team. The process is the team, and the model is how each seat gets staffed on demand.
Takeaways you can use
- Protect the coordinator’s context like it’s the scarce resource — because it is. The session you steer all day should hold state, not code. Once it starts reading source files to “just fix one thing,” you’ve lost what lets it run for hours.
- Make an external system the memory of the project. A board, issues, a durable source of truth. If the project’s state lives only in a context window, it dies with that window.
- Give specialists their own context and let it evaporate. Dispatch a focused worker, let it read everything in isolation, and take back a summary. Never peek into a running worker — you’ll pull its context into yours.
- Sequence the org; don’t swarm it. Names before the things that use them. Design before build. Independent verification after. A flow of control is what turns a pile of agents into a team.
- Isolate parallel builders. Separate worktrees per concurrent writer, or they will collide.
- Encode your delivery model into the board itself. If your process has a state the default columns can’t express, add the column. The board should tell the truth about where work really is.
- Model operations, not just engineering. Give observability, SRE, and incident response their own agents, put architecture and naming ahead of the build, and let ops file corrective work back onto the board. An org that can only build will ship what it can’t see.
Blueprint, not the binary — and what’s next
A fair question: are we open-sourcing our agent org so you can run it? No — the specific role charters, standards, and machinery are ours, and a real part of how we deliver. But the pattern above isn’t a secret, and it isn’t ours to hoard. Everything you need to build your own is in this article. Claude Code gives you sub-agents and isolated context out of the box; your version control and issue tracker give you the system of record. The blueprint is here. The build is yours.
There’s a second half to this story — the next piece. If an org of sub-agents can build a product, something has to decide which product is worth building — and then stand up that org in the first place. We built exactly that: a virtual incubator that takes a raw idea, does the research for an honest go/no-go (market sizing, competitive landscape, unit economics, all adversarially fact-checked), and on a “go” stamps out a brand-new startup already staffed with the org you just read about. The factory that builds the factories. That’s next.
How are you keeping your own agent sessions from drowning in their own context? I’d genuinely like to hear what’s working for you.
Paul Vilevac is the founder of Bleenq, with 31 years building secure, scalable production systems, now applied to AI/ML platforms and the way software itself gets built. CISSP, CISA, AWS Solutions Architect. This is the first article in Org as Code, a series on how we actually build — the operating model behind the software, not just the software.