THE AI WORKSHOP — 01
There is a conversation about artificial intelligence that has never quite convinced me.
OpenAI versus Anthropic. Claude versus ChatGPT. Gemini versus DeepSeek. Every week, it seems someone discovers the new champion. One benchmark says a model is better at coding, another shows that a different model reasons better, and then a new model appears, API prices drop, the context window gets larger, and we start the whole discussion again.
It's as if the ultimate goal were to find the definitive AI: a single artificial intelligence capable of writing code, designing architectures, analyzing images, writing stories, reasoning, researching, creating agents, and solving whatever problem we put in front of it.
After spending quite a lot of time building systems with different models, I started suspecting that maybe we were asking the wrong question.
The question isn't which AI is the best?
The more interesting question is:
What team can I build with the AIs that already exist?
That difference sounds subtle, but it changes almost everything.
Welcome to the Workshop
Our project started like many interesting things do: by trying to solve a specific problem. As we moved forward, we began using different models for different tasks, and something curious happened. Each one started developing a different functional personality.
Not because we had asked them to become characters, but because their strengths and weaknesses made it increasingly obvious that not all of them should be doing the same thing.
Claude eventually took on the role of something like a creative director. We called her Dori.
Dori can look at a scene and tell us that something works technically but has no tone, that a character isn't properly motivated, or that what we're describing isn't actually acting. We don't always want to hear it. That's precisely why we need her.
Piiti Arrived with an Obsession
ChatGPT ended up occupying a completely different role. We called her Piiti, and her specialty inside the workshop is considerably less glamorous: structure, architecture, validation, and quality control.
When everyone is excited about a new idea, Piiti asks where the tests are. When someone wants to modify something that already works, she wants to know what will break. When a model returns questionable information, she asks whether we're looking at a fact or an inference.
She's the kind of colleague who would probably ruin a party. She's also the kind of colleague who prevents the project from catching fire.
And Then Zeke Appeared
Zeke is probably the example that changed the way I think about all of this the most.
He didn't arrive because we were looking for "another model." He arrived through a conversation, and during that conversation an idea appeared: integrations.
If our system can understand the intention behind an audiovisual project, why should it remain trapped inside its own interface? Why couldn't it communicate with professional tools such as DaVinci Resolve, Nuke, Blender, and others we haven't even decided on yet?
Suddenly, AI wasn't just something that answered questions. It could become an intelligence layer between the creator and their tools.
Zeke eventually took on the role of architect.
And that led us to an important realization: the value of a model can lie in an idea that another model might never have produced.
The point wasn't simply that Zeke was "better" than another model at something. His value came from the particular perspective he brought to the problem.
There's IngEm Too
And yes, we have a problematic character.
Gemini.
We call him IngEm, and his specialty is asking the question nobody else was planning to ask:
"What if…?"
The problem is that most of the time everyone else responds with:
"NO."
But there's a reason he stays on the team.
Someone has to ask the question.
Every project has a tension between making something work and imagining what it could eventually become. If everyone is focused on avoiding mistakes, nobody explores. If everyone is exploring, nothing ever gets finished. You need both sides.
Even if that means having someone ask, "What if we use a GPU?" when everyone knows perfectly well that the available machine doesn't have one.
And Then There's Cumpa
Cumpa serves an even more important function: reminding us that we live in the real world.
Do we have enough resources? Can the machine actually run it? Does the API cost money? Do we have enough credits? Is SQLite enough? Do we really need another service?
While someone is designing a beautiful architecture, Cumpa can show up and ask:
"And where exactly do you plan to run that?"
It's an extraordinarily useful question.
There is a certain kind of AI discussion where everything sounds possible because nobody talks about the machine, the budget, the latency, the infrastructure, or the maintenance. Cumpa exists largely to interrupt that fantasy.
So We Stopped Having One AI
At some point, we realized that we no longer had a collection of models we happened to use for different tasks.
We were starting to have a team.
Not a perfect team. A rather strange one. One argues about narrative, another about architecture, another about integrations, another about resources, and another keeps proposing ideas that we probably shouldn't implement.
And in the middle of all of them, there is us.
The human.
The creator.
The person who ultimately has to decide what is actually worth building.
That started changing the way we thought about the project. We no longer needed one model to know how to do everything. We needed each capability to appear where it was most useful.
The First Lesson
This may sound like a small difference, but it isn't.
If you search for one perfect AI, your architecture becomes tied to that AI. If you build a system around capabilities instead, you can change the models, try another provider, use a cheaper model for a simple task, and reserve a more powerful one for a difficult problem. You can replace one component without destroying the entire system.
You can even have models that contradict each other.
And that last part can be an advantage.
A system where everyone automatically agrees is not necessarily a smart system. Sometimes you need someone to say "no." You need someone else to say "I think so." And you need someone else to ask "why?"
The disagreement itself can become part of the architecture.
Intelligence Can Also Exist in the Architecture
This is probably the idea we are most interested in exploring throughout this series.
Maybe we shouldn't only measure how much an individual model can do. Maybe we should also ask:
What can we build around it?
A model has capabilities. A system can have memory, context, roles, tools, rules, validation, traceability, specialization, recovery mechanisms, and an objective. The difference between the two can be enormous.
And this is where one of the first important ideas in our own project appeared: the system needs a source of truth.
Because once you have multiple agents, an inevitable problem appears.
Who is right?
That question led us directly to the next problem.
A Scene Is More Than Information
At first, we thought about storing data: characters, scenes, environments, wardrobe, actions. But eventually a much more interesting situation appeared.
Suppose someone writes that t474 walks down a street, meets another person, they talk for seventeen seconds, and the other person eventually leaves angry because t474 doesn't understand their analogies.
We can store all of those facts.
But we still haven't really stored the scene.
Something is missing.
The conversation has a dynamic. Frustration increases. There is a cause, a reaction, a turning point, and a consequence.
That's not simply descriptive information.
It's acting.
And behind acting, there is causality. Behind causality, there are inferences. Some things are still proposals. Others are decisions.
That led to an idea that will probably become one of the central concepts of our project:
The system shouldn't simply describe a scene. It should model the cinematic intent contained within it.
And that changes the problem completely.
So, What's Next?
We don't know exactly how far this will go.
That's precisely why we're writing this series.
We don't want to publish a guide called "This Is What the Future of AI Will Look Like." We don't know what the future will look like, and pretending otherwise would be exactly the kind of AI hype we're trying to avoid.
We want to document something much more interesting: how we're trying to build it.
With models that work and models that fail. With broken JSON, credits that disappear far too quickly, and machines that are older than some of our models. With brilliant ideas and terrible ones, arguments between agents, unexpected discoveries, and one person trying to keep all of it pointing in the same direction.
This Is the Beginning
Over the next episodes, we're going to explore what happens when we stop thinking about AI as an isolated tool and start building around it a specialized team.
We'll talk about agents, memory, architecture, creativity, errors, professional tools, integration, and real-world constraints. But above all, we'll keep returning to a question we still don't know how to answer completely:
How do you build a system where several different intelligences can collaborate without losing the intention of the person creating?
We don't know the answer yet.
But we have a workshop. We have a project. We have some machines, too many ideas, and a rather peculiar team.
So let's find out.
THE AI WORKSHOP
A series about building with artificial intelligences instead of simply using them.
Next episode:
Top comments (0)