Vol.071 — Multi AI agents or a single AI agent — which one is the correct path?

Date: 2026-10-13 | Newsletter · Multi to Single Agent Journey #1 of 10
I will give the answer first, because this series is not going to make you wait ten issues for it: there isn't one. There is a trade, and this is the story of how I found out which side of it I was on.
I thought I had a team
By September this year, Functional AI Partners and DCC Group were being run day to day by six AI staff, each with a name, a job, an instruction file, a memory file and a folder of its own: a webmaster, a PR writer, a promotion executor, a customer-service agent running on n8n, a designer and an M&A desk. Beside them sat a seventh, nicknamed the Doctor, whose job was to diagnose and rewrite the other six.
I had not designed this as a team. I had built them one at a time, as the work appeared, the way you hire. Each one was good at its job. If you had asked me in August whether the structure worked, I would have said yes.
Two small jobs that nobody owned
Two ordinary pieces of work. The first was the rebuild of the DCC website, which needed the webmaster, the PR writer and the designer to hold the same picture of where things stood. They could not. Each kept its own memory, filed under its own name, and the project — which belonged to all three — had no file of its own. The second was the Action Calendar, which every staff member was supposed to act on. Because it belonged to everyone, it was maintained by no one.

Then I read the records of one fortnight, 3 to 17 September, staff by staff. Two of the six had produced nothing. Four were working, plus the Doctor. And a large share of my own turns in that fortnight were spent on what I could only call AI staff babysitting: answering "waiting on Zenta" lists, killing or re-pointing items, cascading one-line decisions into six sets of files. I had built a team, and the team's output was a queue of things waiting for me.
Wait — they were never separate?
When the Doctor went through the structure, one line stood out, and it is the reason this series exists. In the tool I use, skills and connectors are account-level. All six staff had always been able to see all twenty-eight skills and every connector. What was actually separated was the instruction file and the folder — the memory. The multi-agent structure was buying separation of memory at the cost of fragmenting it, and buying nothing else. The division of labour I thought I had was a division of what each one could remember.
That reframed the question. I had been asking "how do I make six agents coordinate?" The real question was "why do I have six memories for one business?"
I had it! I need to change. But how?
On 17 September I decided to run one agent instead of six. Three reasons, in the order they mattered to me.
First, the functions are few. When I wrote down what the marketing staff actually did for me, it fitted under one job title. The M&A desk is an assistant's job. Six was a headcount for work that did not need dividing.
Second, coordination has to be solved before it is scaled. A single agent spends longer at the start of every session working out what the task needs — more state to read, a longer ritual — and I accepted that cost deliberately. If I cannot make one multi-function agent run smoothly, a team of them will reproduce the same coordination failures at a larger scale. Whatever rules make the one agent work become the base for any later expansion, or for going back.
Third, it was a chance to find out which skills each function really uses — starting from what I ask for and how I ask it, not from what I had imagined the staff would need.
What I did not do was throw anything away. Every project, file and rule the six had built stayed until the one agent had proved itself against them. That sentence cost me nothing to write and saved me months: a reset would have been a rebuild; a consolidation was a three-week programme.
So which is right? Sorry — that depends on you
Here is the honest version of the trade, as I see it after the fact. A team of agents suits work that is truly parallel, or work that must be kept apart for a reason you can name — confidentiality, a client wall, a regulator. It also suits a founder who likes running a team and will put in the coordination work that a team demands. One agent suits work where the hard part is keeping one set of facts straight across many kinds of task, and a founder who would rather fix one file than reconcile six.
I was the second kind. The point of this series is not to persuade you to be. It is that every problem I hit next — memory, files, rules, apologies, skills, automation, folders, my own to-do list, cost — turned out to be a problem of working with AI staff at all, not of the six-or-one choice. Each of the next nine issues takes one of those problems as its door. You can enter through whichever one is yours.
