# Building Software With a Team of AI Agents

*What happens when agents stop being the bottleneck, and what I'm learning about planning, shared memory, review and cost.*

By Hamed Taheri. Working draft, revised October 15, 2026. PR counts through October 15; other numbers through October 14. [Full playbook](https://hamedtaheri.com/playbook/v0.1.0/playbook.md) · [Give to your AI](https://hamedtaheri.com/playbook/v0.1.0/agent/start.md)

I don't write the code. Agents do most of the implementation; I decide what to build, define it so an agent can finish it, and check what comes back. Almost a year ago, I began redesigning our development process around that split: from one session per feature to scripted pipelines that prepare, implement and review work in parallel.

In October, my account passed September's merged-PR total within 11 days. Earlier gains came from running more sessions in parallel, letting them message each other, and getting single sessions to work longer, check their own work and stay inside guardrails. In October, the agents got shared memory and a new system to run them: scripted pipelines that prepare, build and review each task. That's when output jumped.

The bigger surprise was where the work waited. In the pipeline's first nine days, more than half the runs ended with an approval carrying a condition only a person could clear. The agents stopped being the constraint; my decisions became the queue.

This is the method behind those numbers, the failures that shaped it, and what I haven't measured yet.

## What changed in my work

[//]: # (visual:proof-cards)
- **$16.38 → $5.30 per task, coordination included.** October 5: one long coordinating session, about 20 tasks. October 10–13: scripted pipeline, 64 tasks marked done.
- **$1.86 → $0.48 for the same task.** A lean worker made 8 model calls instead of 21 and met every acceptance check.
- **37 stops instead of 37 guesses.** Workers that hit a gap in the brief handed the task back, for cents each.
[//]: # (/visual)

## How the work flows

[//]: # (visual:pipeline-flow)
1. **Me and a coordinating session** plan, write specs and launch runs. The coordinator never reads code or diffs; in the October 10–13 window it was still 49.6% of spend.
2. **A preparer** turns the spec into a six-field brief, or answers NOT READY. Median $0.18.
3. **A worker** implements one brief in its own worktree, under a dollar cap, and opens a draft PR. Median $0.43.
4. **A reviewer** without edit tools checks the exact revision. Median $0.11.
5. **I clear the gate** and merge into an integration branch. Release to production is a separate, supervised step.
[//]: # (/visual)

Agents review every PR against its acceptance checks. I read the gate: the verdicts, the conditions and the PRs held for me. Nothing reaches production without a person.

[//]: # (visual:run-outcomes)
Where 206 agent runs ended, October 6–14: 120 were approved by the AI reviewer and then waited for my decision; 31 were approved with nothing blocking; 37 stopped at a gap in the brief instead of guessing; 18 ended another way.
[//]: # (/visual)

## The seven practices I use

Each practice came from a failure. Four of them:

[//]: # (visual:incident-cards)
- **$36.70:** an agent refreshed 8,336 cached pages one at a time. Now a hook blocks it.
- **9 rounds:** one PR, patched one finding at a time. Now one deep review, one complete fix, one confirmation.
- **0 columns:** a spec named a shared table without its columns, and the worker guessed. Now specs carry the exact table definition.
- **90 MB:** free disk left mid-run. Now every batch starts with a free-space check.
[//]: # (/visual)

### 1. Prepare a task an agent can finish

A worker once invented column names for a table another task created, because my spec named the table without listing its columns. Mocked tests passed. Now every worker gets **outcome, acceptance checks, spec, files, verification commands and branch**, and a shared table comes with its exact definition.

[//]: # (visual:brief-card)
An illustrative brief. Outcome: part B writes every imported row with a status. Acceptance: valid rows imported, invalid rows rejected with a reason, queries run against a real Postgres. Spec: pinned to a commit. Files: exact line ranges plus part A's table definition. Verification: the module's tests and one real-database run. Branch: its own, stacked on part A.
[//]: # (/visual)

Product decisions are where I spend most of my time. My session asks them in rounds of three or four multiple-choice questions, each option with a why-yes and a why-no. On October 14, I groomed about 59 tasks in seven rounds. [Prepare work](https://hamedtaheri.com/playbook/v0.1.0/playbook.md#1-prepare-work-agents-can-finish)

### 2. Give each session a focused job

My coordinating session plans and routes; it never implements. Separate headless processes prepare, implement and review, each with only the tools it needs, a budget and its own worktree. A default worker inherits every tool and instruction. Trimming that took the same task from $1.86 to $0.48.

[//]: # (visual:lean-worker)
Same task: the default worker made 21 model calls, peaked at 109K tokens of context, cost $1.86 and missed one acceptance check. The lean worker made 8 calls, peaked at 45K, cost $0.48 and met them all.
[//]: # (/visual)

Discovery and changing requirements stay interactive. [Execution and scripts](https://hamedtaheri.com/playbook/v0.1.0/playbook.md#2-run-more-useful-work-with-less-supervision)

### 3. Review the whole change before patching

One PR took nine fix rounds and about $6.68 because each review found the next nearby problem. Now I use **one deep review, one complete fix and one confirmation**, with depth matched to risk. A new finding in the same area goes to a person for design review, never to round three. Tests must exercise the layer that changed: mocks hid the table bug above. [Review and delivery](https://hamedtaheri.com/playbook/v0.1.0/playbook.md#3-review-verify-and-deliver)

### 4. Count the workflow, including failed attempts

A cheap worker can hide expensive coordination. In the October 10–13 window, my coordinating session was 49.6% of all spend, so it now routes and never reads code. I count preparation, failed attempts, reviews and the coordinator, and keep money paid, API-priced usage and accepted work as three separate numbers. My target is $1–2 per task with a hard cap of $5; over $2 means the task should be split. [Cost and evidence](https://hamedtaheri.com/playbook/v0.1.0/playbook.md#4-manage-usage-and-cost)

### 5. Keep useful state outside the conversation

Team memory holds tasks, owners, decisions, handoffs, messages and guidelines. A new session retrieves the state it needs instead of the whole conversation, and a handoff keeps the evidence and the next action.

I use Personize, the entity-driven memory layer we build; our own development became its use case. A table and a markdown file are enough for one developer with one tool. Shared identity, safe claims and governed retrieval start to matter when several people and tools share the same work. Queue claims aren't atomic yet, so I run one coordinator. [Memory and kit](https://hamedtaheri.com/playbook/v0.1.0/playbook.md#5-coordinate-through-shared-memory)

### 6. Put important limits in code

An agent spent $36.70 refreshing cached pages one at a time when one wildcard would have cost about half a cent. A sentence in the instructions hadn't stopped it; a hook now does. Scripts, permissions and human approval guard anything expensive or irreversible. These guardrails aren't a sandbox: on a shared machine, run workers in containers with scoped credentials. [Guardrails](https://hamedtaheri.com/playbook/v0.1.0/playbook.md#6-guardrails-security-and-production)

### 7. Save the lesson and test it again

Every rule above started as a recorded failure: the change, the outcome, the cost and what broke. An agent can draft a sanitized finding; a person decides whether to share it. I'd like other teams' findings too, especially the ones that contradict mine. [Learning and contributions](https://hamedtaheri.com/playbook/v0.1.0/playbook.md#7-record-and-share-learnings)

## What this does and doesn't show

[//]: # (callout)
- **My numbers, on my work.** The runner is tuned for one TypeScript backend with a known test setup. These practices are candidates to test, not guaranteed results.
- **Activity is not value.** PR and session counts measure activity, not hours saved, and PR size varies.
- **Costs are API-priced usage, not invoices.** Most of the work ran on a subscription. The two cost windows count tasks differently, so $16.38 to $5.30 is not a matched comparison.
- **Several things changed at once.** Preparation, execution, review and memory all changed in October; I can't yet separate their effects.
- **Not measured yet:** my own minutes per task, and reverts or follow-up fixes in the 30 days after merge. Both are next.
[//]: # (/callout)

How every number was counted: [evidence and definitions](https://hamedtaheri.com/playbook/v0.1.0/evidence/README.md).

## Where this is going

We work with tens of agents today. The direction I'm building toward is hundreds or thousands working in parallel alongside developers, sharing context and coordinating complex work. Those held runs show what has to change first: human decision capacity, not agent capacity. That means batched decision inboxes, versioned claims so several coordinators can run safely, and budgets that cover a whole fleet.

## Try one change, or pass this to your AI

Pick one bottleneck and three checkable tasks. Track acceptance, every attempt, cost and your own time before adding parallel work. The [workflow assessment](https://hamedtaheri.com/playbook/v0.1.0/playbook.md#ai-development-workflow-assessment) finds your main constraint in twelve questions, and the [pilot guide](https://hamedtaheri.com/playbook/v0.1.0/agent/pilot.md) walks through the test.

```text
Read https://hamedtaheri.com/playbook/v0.1.0/agent/start.md.
Compare these practices with our workflow, following our project rules.
Propose one change and three tasks to test it. Include acceptance checks,
a total budget covering review and retries, and cost and human-time measures.
Don't start paid runs yet.
```

The templates, memory starter and measurement tools are in the [starter kit](https://hamedtaheri.com/playbook/v0.1.0/starter-kit.zip). The production runner scripts aren't public yet; [ask me](https://calendar.app.google/UVoMSwMPxo1ypDkH9) if you'd like to see them.

I'm curious how much further experienced developers, product managers and CTOs could take this. [Read the full playbook](https://hamedtaheri.com/playbook/v0.1.0/playbook.md), or [book a call](https://calendar.app.google/UVoMSwMPxo1ypDkH9) to compare notes.