I Built an Agent Army in Codex. The Hard Part Was Management.
- Codex
- ai-agents
- automation
- engineering-management
- multi-agent
In August 2026, I wasn't trying to invent an AI organization. I was trying to finish a story that began with a dream I wrote down fourteen years ago. After a Dungeons & Dragons game brought it back to mind, I opened Codex and started working through the old notes and fragments.
That hobby project became an illustrated novella, a frozen review protocol, and a publishing pipeline. Over the next week I applied the method to software and began moving my professional SDK workflow into Codex.
I can't show the SDK internals, but I can show the pet projects that taught me the method. It is not about one brilliant model. It is about imperfect models producing work you can inspect, reject, and continue without holding the whole system in your head. I call it my agent army; the useful reality is an operating model built from bounded roles, separate acceptance, durable evidence, budgets, and human accountability.
Before the Codex app: I was connecting terminals by hand
I had already been using Claude Code heavily in the terminal alongside Codex CLI. They could see the repository, run tools, and make real changes. The problem was coordination: Claude had one context, Codex another, and planning lived somewhere else. If I wanted one model to challenge another, I moved the information myself.
I even wrote a tool that restored terminal contexts and forwarded replies between sessions. It worked, but I was still the message bus, scheduler, permission system, and failure monitor.
In August 2026, I found that the Codex app could keep long-running tasks, files, tools, subagents, and visible handoffs in one workspace. I supplied the roles, skills, repository memory, and rules. Different models could remain in the workflow; the row of terminal windows no longer had to impersonate an organization.
Separate Claude Code and Codex CLI contexts, connected by my own scripts and copied handoffs.
Codex kept the conversation, files, tools, roles, and agent collaboration in the same place.
Fresh task contexts, specialist roles, repository memory, separate review, and explicit release gates.
The tooling changed. The more important change was moving coordination out of my head and into explicit, inspectable boundaries.
The important change was not the interface. It was that coordination could become part of the project itself.
The book was my first laboratory
I did not begin by telling an agent to “write a book.” I brought Codex the old notes and a large amount of uncertainty. We worked through the world, character motivations, missing scenes, and what the story was supposed to make a reader feel. The repository became shared memory: manuscript, lore, decisions, visual canon, production state, and the Git history connecting evidence to a version.
Once the first complete manuscript existed, I stopped asking the least useful question in creative work: Do you like it?
Instead, I created isolated readers with different jobs: target reader, commercial editor, continuity critic, ambiguity advocate, hostile-but-fair skeptic, and narrower specialists. Each saw a clean manuscript and one role—not the other reports or the change I hoped they would praise.
I ran the frozen protocol across GPT and Claude. Earlier DeepSeek and Mistral audits stayed in a separate evidence lane rather than becoming extra votes in the same benchmark. I wanted to see whether isolated model families found the same failure mechanism.
One eloquent criticism is an opinion; several runs within one model family are correlated evidence. When different families locate the same causal gap and I can inspect it, the case becomes stronger—not proven by majority vote.
We froze the prompts and scoring structure so that a new version could not “improve” because I made the test friendlier. Before changing the manuscript, we recorded the suspected mechanism, intervention, expected effect, protected qualities, and revert condition.
The process produced a 290-page review build containing the novella, illustrations, and production material. Automated checks passed, but the release gate failed because several images lacked explicit canon locks. The PDF looked finished; the recorded state said otherwise, and I did not override it. Those images are now locked, but a fresh full-book run is still required.
That failure taught me more than a cheerful pass would have.
Then I tried the same method on software
The second pet project happens to be a game, but the game is not the point. I needed a test bench where agents had to change a real codebase, run an expensive engine, inspect behavior and visuals, and survive imperfect infrastructure.
Concept art for the software test bench and its planned protagonist. These images define a visual target; they are not evidence that the current build has reached it.
My first attempt let one capable agent interpret, design, implement, test, and judge the feature. It was fast and weakly designed: “it compiles” drifted into “it works,” then “it is better,” and finally “it is done.” Those are four different claims.
I separated the roles: a manager froze the outcome, an implementer changed code, a runner produced evidence, QA searched for behavioral failures, and visual and release reviewers judged the result. The creator was no longer allowed to accept its own work.
That structure caught failures the code-first checks in this iteration had missed. The source built, the automated behavior passed, the capture files existed, and QA accepted the technical packet. The art reviewer opened the images and rejected them: one was almost black, the critical feature was outside every frame, and the main character was unreadable at the captured scale.
The implementation had achieved its narrow technical objective. The product result was not acceptable. Both statements were true.
The experiment also destroyed my first fantasy about parallelism. On a 16 GB Mac, several agent sessions and their tool runs met Unity, its package manager, and its licensing process. Memory pressure climbed and the machine froze.
The fix was not a more powerful prompt. It was a scheduler: one heavy writer at a time, no new agent while Unity was active, separate worktrees for genuinely independent writers, cheap checks before engine runs, and a hard limit on implementation attempts.
More agents do not automatically create more autonomy. Reliable progress inside real constraints does.
The pattern transferred to my real work
My production SDK already had role-specific context, skills, conventions, and separate responsibilities. During the second week I began moving that workflow into Codex. The private results are too early to claim success, but the role-and-evidence structure was portable across creative, engine-based, and professional work—and often exposed failure instead of manufacturing a pass.
The reusable unit was not a “writer agent” or a “Unity agent.” It was the organizational pattern around them.
Meaning, scope, taste, irreversible decisions
Routes one bounded outcome and guards the budget
Researcher · Creator · Engineer
Separately tasked; tries to disprove completion
Decisions, artifacts, manifests, tests, handoffs
Creation and acceptance are separate jobs. The repository stores evidence; the owner receives decisions, not raw operational noise.
The owner defines meaning and boundaries. An orchestrator creates a bounded charter. Specialists make artifacts; a separate reviewer tries to disprove completion; the repository holds evidence. The owner returns for trade-offs, releases, changes of direction, or stalled and conflicting work.
That is the layer I now spend most of my time designing.
What autonomy actually looks like
I do not spend the whole day watching agents work. On weekday mornings, before my workday begins, I freeze bounded tasks for the book and software test bench, then leave those personal queues running unattended for five to seven hours. When professional work starts, I switch contexts and use agents actively for my normal engineering responsibilities. The repositories, task queues, and review cycles stay separate.
After work, I inspect what the personal-project shift produced: artifacts, tests, rejected claims, and decision packets rather than a stream of chat. In the evening I use smaller tasks for quick feedback, adjust the roles or process, and before bed assign longer jobs that can run until morning.
The products matter, but right now they are also instruments. My primary experiment is the method for developing almost anything this way: how long a task can run safely, where autonomy breaks, what evidence survives the night, and which intervention improves the next shift. Across the same calendar day, personal queues can keep consuming compute while I actively use separate agents for professional tasks. That is parallel compute, not parallel attention—and it explains why the token consumption looks nothing like one agent answering one question.
The less formal description is that I have been living on dopamine. Constant visible progress makes it surprisingly hard to sleep, even when the point of the system is that it can keep working without me.
What I would build first
If you are currently switching among several AI chats and moving conclusions by hand, do not start by creating twelve agents.
Start with one workflow that hurts and three roles:
- Manager — freezes one outcome, non-goals, acceptance criteria, and budget.
- Creator — produces the smallest coherent change or artifact.
- Reviewer — checks the result in a separate context and cannot quietly repair it.
Put the goal, decisions, and evidence in the repository. Require an artifact rather than a persuasive status update, make the reviewer cite what it inspected, and end after one outcome.
Only add another role when you can name the conflict, bottleneck, or missing expertise it resolves.
Roles need contracts, not costumes
Many multi-agent demos name a cast of brilliant developers and meticulous testers. Personalities can make a prompt pleasant. They do not create accountability.
An operational role needs five things:
- A defined input. What must exist before this role starts?
- A bounded output. What artifact or verdict must it return?
- Explicit authority. Which tools, files, and decisions may it touch?
- Forbidden actions. What must it route elsewhere even if it knows how to do it?
- A stopping condition. When is the task complete, rejected, blocked, or ready for a human?
“You are a careful QA engineer” is weaker than “you have read-only access, may not fix what you find, must map every failure to the frozen criteria, and may return only ACCEPT, REJECT, or NEEDS_OWNER_DECISION.”
Not every boundary is equally strong. Where possible, I use filesystem permissions, worktrees, allow-listed tools, and resource locks—the Unity lock belongs to the scheduler, not a polite prompt. Written instructions are weaker and cannot authorize a release without an evidence gate or human decision.
The model matters only after the job is well formed. I can route architecture and final review to a frontier model, exploration to a faster one, deterministic work to a cheaper one, and adversarial review to another model family. The roles should survive those substitutions. I often want Claude to challenge a plan produced in Codex; I do not want the challenger editing the implementation it judges.
Context should be assembled, not accumulated
One endless conversation eventually remembers too much: obsolete requirements, raw logs, abandoned hypotheses, and confident summaries from versions that no longer exist.
I now prefer fresh execution contexts assembled from durable layers.
A good role prompt is not a biography. It is the last layer in a stack of durable project context and a narrowly scoped task contract.
The repository is the institutional memory; the conversation is an interface to it.
For each project I keep a goal, decision log, current iteration, acceptance criteria, non-goals, evidence directory, and concise terminal handoff.
A fresh task reads what it needs for one outcome, writes evidence back, and ends. Strategic conversations remain useful because operational residue stays out. It is less convenient than one giant context and much easier to audit.
The bill taught me what parallelism really means
At the time, I paid about $100 per month for Claude and began Codex through a roughly $20 ChatGPT subscription. I moved to the roughly $100 option, then reached its weekly limit in about two days after adding software and SDK work. My next displayed upgrade was roughly €200; I am preserving the currencies I recorded rather than pretending they compare cleanly.
This is an August 2026 usage diary, not a pricing benchmark. Plans and allowances change, and I was running long, high-reasoning workflows across several projects. By the end of week two, both services were briefly out of budget.
The useful lesson is simpler:
“Concurrency is a spending policy.”
Launching five high-effort reviewers is a budget decision. Model, reasoning effort, agent count, retries, and task lifetime belong in the workflow contract.
My practical rules now look like this:
- One task, one outcome. A task that finishes one iteration does not silently begin the next.
- Separate creation from acceptance. Nobody grades their own homework.
- Cheap proof first. Use static checks or one focused reviewer before expensive builds, broad panels, or visual reviews.
- Evidence has provenance. A pass belongs to a particular source version, command, relevant environment and configuration, and immutable output.
- Authority and budget are narrow. Reviewers stay read-only; model, runtime, retries, and attempts are bounded; irreversible decisions return to the owner.
- Failure stops the loop. “Not proven” and conflicting verdicts return to the owner instead of silently launching another attempt.
- Change one process variable at a time. If the route and model both change, do not pretend the result proves which one helped.
The goal is not to minimize every token. It is to spend expensive reasoning where it changes a decision.
So I made this article review itself
Publishing an article about reliable agent workflows without applying the method to the article felt absurd. So a frozen snapshot went to four roles—a cold reader, commissioning editor, factual auditor, and practitioner—once with GPT and once with Claude. All eight internal reports returned revise.
Consensus, risks, and taste stay separate
Edit, preserve, verify, or reject
Eight readings are not eight independent sources. Cross-family convergence raises the priority of a finding; it does not replace inspection or authorial judgment.
Both families challenged the same overclaims and disagreed about the headline and how much of this section to keep. The private reports do not prove the article is good; they exposed claims I could inspect. The pipeline could neither edit nor publish, so the decisions—and responsibility—remained mine.
What remains human
I did not outsource what the book meant, which criticism mattered, what ambiguity to preserve, product direction, or responsibility for the SDK. Agents can inspect, implement, test, and challenge; they cannot absorb accountability. The human role moves upward, but it does not disappear.
My job is increasingly to design the organization: decide where context lives, split conflicting authority, define evidence and budgets, and intervene when the system reaches a real decision.
Prompt engineering can improve one response. Organizational design can make months of imperfect responses useful.
I started with a fourteen-year-old dream and a home-made relay between terminal windows. Two weeks later, the same organizational pattern was moving a book, a software experiment, and part of my professional workflow—without requiring me to watch every step.
Models, interfaces, plans, and limits will change. The durable skill is turning intelligence into an organization that can tell you when it is wrong.
Next, I plan to publish the concrete templates behind this setup: role contracts, task charters, evidence packets, and the rules I use to decide which model gets which job.