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 · Give to your AI

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

How the work flows

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.

The seven practices I use

Each practice came from a failure. Four of them:

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.

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

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.

Discovery and changing requirements stay interactive. Execution and scripts

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

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

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

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

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

What this does and doesn't show

How every number was counted: evidence and definitions.

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 finds your main constraint in twelve questions, and the pilot guide walks through the test.

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. The production runner scripts aren't public yet; ask me 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, or book a call to compare notes.