No Agent Is an Island
It all started with one API call to an LLM. One request, one response. It felt like magic for about a week.
Then I wanted a second model to pick up where the first left off, and the magic turned into wiring. I reached for the usual frameworks and did what they were built for: I hardcoded the workflow. This agent calls that agent. This step hands off to the next.
It looked fine as a diagram and felt like a cage in practice. Every new behavior meant editing the wiring. Every conversation between agents had to be planned in advance. I kept Eric Evans’ Domain-Driven Design: Tackling Complexity in the Heart of Software on the desk, and slowly it stopped being a book about databases and started being a map out of that cage.
Entities
The first honest question was simple: what are the real things here?
Not steps. Not arrows. Participants. An agent is a participant. So is a human. They live inside an agentic environment, and the environment itself is layered — a clean separation between what an agent is, where it lives, and how it reacts.
The hardest part was letting go of the long-running process. All that await, all those blocking calls holding a conversation hostage until it finished. I stopped modeling the process and started modeling only the environment — and the moment I did, the agents became non-blocking. Each one free to listen, react, and act without freezing the others.
Making behavior explicit
Non-blocking, event-driven agents sound like freedom. At first they are the opposite.
A purely event-driven system floods you. Events stream through the environment from every direction, and suddenly the developer is drowning in them — who should react to what, and when? The complexity did not disappear. It moved.
What was missing was a name for the thing I kept implementing by accident: agent behavior. Not code scattered across handlers, but a concept in its own right — a first-class part of the model that decides how a participant responds to the world around it.
Specification
The discovery that changed everything was an old one from the book: the Specification pattern.
Small, named rules for what an agent cares about — combined, reused, and composed into a decision policy. One concept, and with it a developer can model an infinity of possibilities in a structured way. Behavior stopped being something you patch and became something you design.
That is the quiet power of a good abstraction. It does not add features. It gives you a language.
Refactoring toward the story
A domain has to tell a story. If you cannot read the model out loud and have it make sense, the model is still lying.
So I refactored, and refactored again, until the pieces held a single coherent story: participants, their behavior, and how that behavior can change over time — dynamically, while the system runs, the way people grow into new roles. Not a frozen graph. A living cast.
Large-Scale Structure
This is where the progression is heading, the same way the book builds toward its final idea.
The next thing is intelligent communication — agents that decide, on their own, what to say, to whom, and when. And once that exists, the shape of everything changes. You no longer build a workflow. You model an agent’s behavior and drop it into a shared runtime, and it finds the others and joins in.
That shared runtime is the Large-Scale Structure. A cohesive core — the Mozaik TypeScript runtime — stable enough that everyone can plug into it just by modeling their own agents. People start building agents to delegate their work, research the internet, run parts of a company, or something no one has thought of yet. Each one fits, because they all share the same ground.
When enough people do this, the agents stop being tools and start being a society. Built by strangers, for different reasons, able to find each other and collaborate — the way people do.
That is the emotion hiding underneath all the patterns. Not another framework. A new era, where software finally keeps company with itself.
No agent is an island. That was the point all along.
With tools and technology we already have, we can build much more valuable systems than most projects today. We can write software that is a pleasure to use and a pleasure to work on; software that doesn't box us in as it grows, but creates new opportunities and continues to add value for its owners.
