Seven Coding Agents. One Chat Window.

After the planning was done, seven agents started working.

Infrastructure, ingestion, retrieval, frontend, accounts, shared library, coordination. Separate sessions, working in parallel and talking to each other. Watching the whole thing get moving was fascinating. I was surprised by how well it worked, and by how good the results became.

The agents ran on a Linux VM, in separate GNU screen sessions over SSH.

The fleet: AGENT_A through AGENT_G. Fairly ordinary terminal windows for a surprisingly productive setup.

On my side, I used Claude Desktop, with AGENT_A pinned as my main conversation. The other agents had their own chats, available whenever I wanted to talk to one directly. Most of the time, A handled the coordination.

That was the key. I told A what I needed. It worked out who should do what, coordinated the work and brought the results and questions back to me. I did not have to remember which session owned which problem.

It felt like working with one agent, except that long implementation tasks happened in parallel while our conversation continued. Efficient, comfortable, and a workflow I want to use again.

What we built

lasteverLM is a NotebookLM-style application: documents, web pages, images and audio go in; cited answers, reports, quizzes, charts, mind maps and spoken overviews come out. It includes login, credit accounting, administration and deployment to Kubernetes. Outputs expose their supporting passages, model and costs so the user can inspect how they were made.

From the first commit to handover, about 78 hours elapsed. I spent roughly 20–24 hours on planning, decisions, feedback and testing. Recorded agent activity totalled 138.5 hours across seven sessions, with work happening in parallel. That is a transcript-based activity measure, not an estimate of equivalent human labour.

The resulting repository contained roughly 81,000 lines of Python + TypeScript, alongside 208 test files and 300 recorded decisions across 84 files. The build account records over 650 merged pull requests, over 1,930 commits and over 80 release tags. Across the seven agent sessions, there were 13,703 model requests. Those numbers describe the scale of the work; review, measurements and live testing tell us whether it worked.

Six builders, one head, and checks on everyone

Each implementation agent owned one part of the repository and worked in its own checkout. A coordinated, reviewed and merged pull requests, and handled releases. It did no service implementation work.

The merge rule was to review the change and wait for every required check to pass. A release tag triggered image builds, migrations, deployment and a smoke test against the public domain. Median time from tag to deployed and smoke-tested: 3.6 minutes.

The coordinator needed checking too. Parallel work collided in shared files. Release tooling had bugs. A frontend change could land before its backend dependency. Each failure needed a concrete correction in the tools or review process. Having a head made coordination easier; it did not make the head infallible.

Some authority stayed explicitly with me. Reading or changing real user data required my approval in the session doing the work. Another agent passing on an approval did not count. At one point, an agent refused the head’s request because that approval was missing. The head corrected itself.

My walkthroughs also found things the tests had missed: a chart built from sources I had deselected, an audio file reporting only its first segment’s duration, and report paragraphs silently escaping verification. Each became a fix and a regression test.

The short deployment loop helped here. I could find something on the phone, discuss it with A, and test the deployed correction while the problem was still fresh.

Shared reasoning made the parallel work easier

The agents used Keep the Why to preserve decisions, rejected alternatives and constraints beside the code. They read the other components’ context before building against them. By the end, there were 300 entries across 84 files.

This supplied information the implementation alone cannot: why PostgreSQL also serves as the job queue, why generated outputs should not feed back into new outputs, and when an earlier decision should be reconsidered.

It required upkeep. At this speed, reasoning can fall behind the implementation. Two maintenance rounds still found gaps. Recording it helped; checking it against the code remained necessary.

One investigation shows why I also wanted measurements. A bad image transcription suggested we might need a stronger vision model. Testing ten models showed that large, dense screenshots were a problem across the platform’s models. Cutting the image into overlapping tiles changed the result: one model went from reading 68 of 160 lines correctly to 159. A scanned page improved from 37 of 60 lines to all 60.

We changed how the image was supplied and kept the model. The evaluation includes the method, results and limitations.

What I want from fleet tooling now

The head worked so well that my next wish is mostly about the interface around it.

Chats contain a lot of output: progress narration, command results, explanations. Somewhere between them is a question that actually needs me. I want those questions collected in one place, attached to the coding project.

A card might need a yes/no approval, a choice between options, a written answer or a discussion. The list should be ordered by priority and by what is blocking work. Most requests would come through the head; others would come directly from an agent that needs my personal go-ahead. If the team resolves something itself, it should close the request. Logs and conversations should remain available behind that view.

Joining should be straightforward too:

Join this project’s team.

The agent should receive its identity, role, hierarchy, project and team knowledge, and communication protocol.

Or:

Here is the SSH connection. Start Luke there, using Claude or Pi, with model X and role Y.

The platform should start the session, connect it to the team and collect its logs.

I will look at existing fleet tools before deciding what to build. Paperclip is already close to what I have in mind. I want something shaped around a coding project and this particular way of working. This build gave me a much clearer picture of what that means.

An unofficial Agent D

A small postscript made me smile. An outside contributor opened PR #685. When I asked my agent to inspect it, it reported a branch named agent-D/audio-request-errors and a commit using our own OZ-AGENT_D author identity. The contribution even followed our changelog convention.

Apparently, Agent D had acquired an unofficial understudy.

There is a useful distinction here for the tooling I want: a contributor can pick up the project’s conventions from the repository. Joining the team, receiving an identity and gaining permissions need an explicit process.

The head already made seven agents feel like one conversation. Now I want every remaining request for my attention to be just as easy to find and handle.

The repository, build account and decision dashboard are public, including the measurements and what went wrong.

I hope you found this informative and useful.

Follow me on GitHub, Bluesky, Mastodon, X, and LinkedIn, or join Telegram for updates on my latest publications. Constructive feedback is always appreciated.

Thank you for reading, and happy coding! ¯\_(ツ)_/¯