Why we built one agent, not many 

Customer.io is one interconnected domain. A churn signal is relevant to your content. Your content is relevant to your segmentation. Your segmentation is relevant to your timing. When everything talks to everything, how you architect your agent isn't a technical footnote—it's the whole game.

The multi-agent pattern is everywhere right now. You've probably seen it: a sales agent, a marketing agent, a content agent, each scoped to its own slice. It maps cleanly onto org charts, which makes it intuitive to explain. It's also the wrong architecture for what we're building.

Here's how we thought about it.

Before we decided how many agents to build, we had to figure out how an agent should actually work.

We were extending our assistant with new abilities, and it wasn't meeting our standards. It was built around tools—every capability required its own, every workflow its own agent. The more powerful we tried to make it, the harder it got to reason about—and paradoxically, it got less reliable. The complexity was growing, but the capabilities weren't. When you give LLM tools they try to use them. When you give them many tools, they fail to use them correctly. We were not satisfied with that direction at all.

So we went back to the drawing board. We looked at systems that had actually solved this well, and we noticed something: the most capable ones were also the simplest underneath. We asked ourselves, what's the smallest set of primitives that can compose into arbitrarily complex behavior?

We landed on four: read, write, search, and execute. That's it. The agent can read from its environment, write to it, search for information, and execute actions inside the platform. Everything the agent does is an expression of one or more of those four things. Nothing lives outside them.

If you've used Claude Code or any of the coding agents, this might sound familiar. That's actually where a lot of our thinking came from. We'd been running agentic systems internally for support, for data analysis, for engineering and we kept seeing the same pattern. The most effective setup was always a simple one: a long-term memory, a description of how to behave, and access to a small set of powerful primitives. The system that we’ve built for our support team had basically those same building blocks, and it figured out a DKIM misconfiguration from a completely nondescript support ticket. We never taught it that. It just had the right primitives and the room to reason.

So alongside the primitives, we gave the agent two other foundational pieces. Personality and purpose: a stable identity that governs how it behaves, what it prioritizes, and how it communicates. And extensible memory: context that accumulates across conversations rather than resetting every time. The agent learns and adapts and improves through use.

The last piece is the agentic loop itself. This is what takes the primitives and turns them into something useful. Given a goal, the agent reads what it needs, searches for what it doesn't have, reasons about what to do, executes, and observes the result. Then it does it again. What looks like sophisticated behavior—connecting a churn signal to a reactivation campaign, revising copy based on performance data—is really just the loop running the same simple building blocks in different combinations.

This matters for how you think about complexity. The instinct in agentic system design is to handle complexity by adding agents. One agent gets overloaded, so you split it. One agent lacks expertise, so you specialize it. But if your primitives are right and your loop is sound, complexity doesn't require more agents—it requires more iterations. The system scales through depth, not proliferation.

That's why we ended up with one agent. Not because we underestimated the problem, but because we built something that didn't need to be fragmented to handle it.

Specialist agents make sense when your problems don't overlap. A medical agent and a personal assistant have nothing to say to each other—keeping them apart is clean, not costly. But that's not what we're building.

Splitting an agent across Customer.io's domain doesn't create specialists. It creates gaps. And we know what those gaps look like, because we lived through the multi-agent version. Every boundary between agents is a place where knowledge has to be serialized, handed off, and reconstructed. A place where two systems can contradict each other. A place where something falls through.

We saw this exact dynamic play out with our internal open Claude instances. We went from one to forty-something in three weeks. Each one was focused on its own thing, and the coordination overhead was real—security problems, people having to administer all these separate machines, things finding ways around the restrictions we'd set up. The multi-agent model asks you to do hard coordination work in exchange for a benefit you were never going to get anyway.

Here's the part that changes how you think about specialization entirely.

In a multi-agent system, a human has to define the boundaries. Someone decides what the sales agent handles and where it hands off to the content agent. Those boundaries are drawn in advance, encoded in the architecture, and then defended forever—updated every time the real world doesn't match the map.

Our agent doesn't work that way. Skills are structured instructions that teach the agent how to handle specific workflows. Execute is the primitive that acts on them. When the agent receives a request, it routes itself—reading the available skills, determining what applies, and composing a response from them. No human has to draw the boundary in advance. The agent finds the path.

This means adding capability is just adding a skill. You write a markdown file that describes a workflow, and the agent knows how to use it. The architecture doesn't change. The orchestration layer doesn't grow. We wrote the whole agent in about four weeks, and the way it gets more capable is the same way a person does: by learning, not by cloning itself.

The specialization is real. The fragmentation isn't necessary.