The AI Workshop — 02
Building a team of artificial intelligences instead of searching for one perfect AI.
In the previous episode, we started with a fairly simple suspicion: perhaps we had been spending too much time trying to answer a question that wasn't as important as we thought. The industry can spend weeks arguing about which model is the smartest, which one reasons better, which one writes better code, or which one has just surpassed everyone else on some benchmark. But once you start using multiple models to build real things, the question changes surprisingly quickly. It matters less which model is the best in absolute terms and more which one is best suited to the problem in front of you.
That was what started happening in our own work.
At first, there was no master plan. There were different AIs, different conversations, and problems appearing across different projects. Each model had its own peculiarities: some were particularly good at certain tasks, others had a way of reasoning that was useful in specific situations, and others simply worked better when we needed to review or structure something. What was interesting was that these differences, which initially looked like a nuisance, slowly became an advantage.
If two models produce different results for the same problem, one possible response is to decide which one is right. The other is to ask why we are forcing them to do exactly the same job.
That was when an idea began to change the way we worked:
Maybe we didn't need one AI that could do everything. Maybe we needed a team where each intelligence had a different responsibility.
And then we literally started hiring.
They weren't characters. At first, they were needs.
Dori, Piiti, Zeke, Cumpa, and IngEm did not appear as part of a team designed in advance. They emerged as the work presented us with different problems. Each new problem forced us to find a different way of approaching it, and over time we began associating certain tasks and ways of working with particular agents.
That detail matters because the specialization did not come from an arbitrary decision. We didn't say, "Let's create five characters," and then look for something for them to do. It happened in the opposite direction: the needs of the work created the roles.
Dori eventually occupied a space strongly connected to creativity, conversation, and exploring ideas. Piiti gradually became the teacher, helping us turn complex problems into structured learning. Zeke moved increasingly toward architecture and technical problem-solving. Cumpa became especially useful when we needed a critical perspective, someone willing to question a decision rather than simply develop it. IngEm, meanwhile, represents a much less glamorous but absolutely necessary concern: resources have limits, and any architecture that ignores those limits eventually becomes an imaginary architecture.
Over time, their names became less important than the responsibilities they represented.
That was probably the first real paradigm shift.
We were no longer thinking about "five different AIs."
We were beginning to think about a system of distributed responsibilities.
Specialization isn't just putting a label on a model
However, another problem appeared quickly.
Calling an AI "the architect," "the teacher," or "the critic" does not automatically make it behave like an architect, teacher, or critic. A label does not create a role. Real specialization requires context, responsibilities, boundaries, information, and a clear definition of what that agent is expected to do.
It also requires knowing what it should not do.
That may seem like a small distinction, but it becomes fundamental when multiple agents work on the same project. If everyone has access to everything, everyone can comment on everything, and nobody has clearly defined responsibilities, we don't really have a team.
We have several simultaneous conversations.
Specialization starts making sense when a capability becomes a function within an architecture.
An agent can be excellent at generating alternatives and, at the same time, be a poor source for validating those alternatives. Another might be exceptionally good at detecting inconsistencies but lack enough context to decide how to solve them. Another might execute a task with great precision while having no reason whatsoever to decide whether that task should be executed in the first place.
That means the differences between models stop being merely a matter of performance.
They become a property we can use to design the system.
Disagreement started becoming useful
There was another consequence we hadn't anticipated at first.
When you work with a single AI, it is very easy to interpret a convincing answer as a correct answer. If the model explains something confidently and the explanation sounds reasonable, our natural impulse is to continue working from it.
With multiple agents, another possibility appears: make one agent question another's work.
And then we discovered something that became much more important than it initially seemed.
Disagreement isn't necessarily an error. It can be information.
If Dori proposes a solution and Zeke finds an architectural problem, that doesn't automatically mean one of them is failing. It may mean they are looking at the same problem from different perspectives.
If Cumpa points out that a statement contradicts an earlier decision, that is exactly what Cumpa exists to do.
If Piiti notices that an explanation is too complex for the learning objective, she isn't contradicting the system. She is fulfilling a different responsibility.
Diversity of judgment starts functioning as a form of control.
And that led us to a rather uncomfortable conclusion: a team of agents that always agrees with itself probably isn't a very useful team.
We need agents capable of saying that something doesn't make sense. That a claim isn't sufficiently supported. That one decision contradicts another. That information is missing. Even that a technically correct solution may be the wrong decision for the project.
Sometimes, we need an agent capable of simply saying:
"No."
Not because AI should become an authority, but because a system in which every component tries to please the user can end up hiding its own mistakes.
Then the problem of limits appeared
IngEm represents a less glamorous part of this story, but probably one of the most important.
When we talk about artificial intelligence, we often talk about capabilities as if they were infinite. We can imagine specialized agents, coordinated systems, external tools, persistent memory, and increasingly complex processes. But all of that eventually runs somewhere, using actual resources.
Memory.
Compute.
Time.
Credits.
Latency.
Hardware.
Money.
Everything has a limit.
And when you work with limited resources, you start discovering that constraints aren't simply obstacles. They can also force you to make better architectural decisions.
A solution can be technically possible and still be completely impractical. Another can be less sophisticated but much more sustainable. A model can be excellent at a particular task but too expensive to use constantly. An automation can save work in one stage and create ten new problems in another.
Those decisions cannot be solved by asking which model is the smartest.
They are solved by understanding what role each component should play within the system.
The team still needed a director
But the further we went with this idea, the more obvious another question became—one that couldn't be solved simply by adding another agent.
If we have an AI for creativity, a teacher, an architect, a critic, and an engineer, who decides?
The easy answer would be to create a "supervisor agent" and give it responsibility for coordinating everyone else. It's an attractive solution because it seems to close the loop: if we have several specialists, we need another specialist to manage them.
But there is a problem.
The supervisor still needs to know what we're actually trying to achieve.
And that decision isn't purely technical.
Someone has to decide what "good" means. Someone has to establish priorities. Someone has to decide which constraints are acceptable and which aren't. Someone has to decide when a technically correct solution doesn't work because it contradicts the original intention.
That brings us back to the element that was present from the beginning and that is easy to forget when we talk about autonomous systems:
the human is still part of the architecture.
AI can expand our capabilities, explore alternatives, find errors, and execute tasks. But the intention connecting all those actions is still ours.
At least for now.
From a group of models to a workshop
Looking back, perhaps the most important change wasn't adding new models. It was changing the way we looked at them.
Before, we could think of Dori, Piiti, Zeke, Cumpa, and IngEm as different tools that we used depending on the situation.
Then we started seeing them as parts of a system.
That sounds like a semantic difference, but it completely changes the questions we ask.
We no longer ask only which model performs better. We ask who should handle a particular task. What information that agent needs. What information it should be allowed to modify. Who will review its work. What happens if it makes a mistake. What happens when it conflicts with a previous decision. What tools it can use and which ones should remain outside its reach.
In other words, we stopped thinking only about models and started thinking about architecture.
And that was precisely where our next problem appeared.
Because if multiple intelligences are working on the same project, they all need access to a shared reality. We cannot allow each one to maintain a slightly different interpretation of what has already been decided. We cannot depend on five separate conversations remembering, in five different ways, what is a fact, what was a proposal, what was rejected, and what was finally established.
We had managed to accomplish something that initially seemed rather difficult:
We had built a team.
Then we discovered that building the team was only the beginning.
Now we had to make sure they all worked from the same reality.
And that question led us directly to the next episode.
The AI Workshop — 03
An AI Shouldn't Be the Source of Truth
Because having memory doesn't necessarily mean having reliable memory.
And when multiple agents start building together, that difference can become one of the hardest problems to solve.
A shared context isn't automatically a shared truth.
That's where things get interesting.
Top comments (0)