You can't design the agent platform first

At our NYC showcase on July 28, Wallaby went on immediately before Atlas. The ordering was the argument. Wallaby is one agent, built by hand, doing one very specific GTM research job. Atlas is the platform where anyone on the team can write an agent's instructions and put it to work.

Every team building internal AI walks the same three stages, and almost nobody plans for the third. Stage one: one narrow agent for one expensive, repeated job. Stage two: it works, so four more appear, each hand-built. Stage three: the bottleneck stops being whether an agent can do the job and becomes how anyone here builds one, and who is accountable for the result. A substrate solves stage three. Adding more agents just makes it worse.

Stage one is one job someone hates doing

Wallaby existed because a specific research task was expensive and happened constantly. Nobody scoped it as "GTM productivity." It was one job. That narrowness is why it worked, and it's why Wallaby got the most attention at our first applied AI showcase: people could see their own worst recurring task in it.

Stage one is cheap to reason about. One agent, one owner, one set of credentials, one person who knows what happens when it breaks. Governance is a conversation in a hallway.

Then four more show up

A working agent is what produces stage two. Someone in another function watches the demo, recognizes the shape of their own problem, and builds their own version. Each one gets hand-built, because hand-built is the only option available. Each carries its own integration credentials, its own prompt with the same institutional context pasted into it, and its own implicit owner.

Four agents still feels manageable, and it looks like a team that's winning. That's the trap.

The costs are all deferred. Nobody has written down which agent does what, nobody knows whose account sits behind a given integration, and the answer to whether an agent can read a given system is whatever its creator could reach on the day they built it.

Stage three arrives as a directory problem

We now have more than 80 team agents running on Atlas. The 80 is the interesting number. One agent proves a job can be automated; eighty is an operating environment.

Eighty changes the questions, and the failures it produces are administrative rather than technical. Someone asks whether an agent already exists for a job, and finding out takes longer than rebuilding it. Two agents do nearly the same thing with slightly different instructions and slightly different answers, which is worse than either one alone. A handle sits in a channel months after the person who made it moved teams. An agent's only real dependency turns out to be one laptop and one person's authorization grant.

None of that is a capability failure. Every one of those agents does its job. The problem is that agent-building outran agent-accounting, and sprawl shows up faster than governance because sprawl is the byproduct of success.

You can't design the substrate first

The obvious counterargument: if you know stage three is coming, skip to it. Build the platform first, make everyone build on it, never accumulate the mess.

I don't think you can. Atlas is the generalized version of what Wallaby proved, and that sequence isn't an accident of scheduling. Before Wallaby, we would have been designing an abstraction over work nobody had done yet. You learn what the substrate owes its users by building the specific thing, then building it again and noticing which parts you rewrote: which context every agent needs, and which instructions you keep copy-pasting into the next system prompt. A platform designed before that is a guess with a roadmap attached. You end up specifying integrations and permission models for jobs nobody has run.

The order matters, but the timing is tight. Build the bespoke thing first. Start building the substrate the second time you build the bespoke thing, not the fifth.

What a substrate has to own past about ten agents

We built Atlas for ourselves before releasing it to anyone else, and this is the list that shaped it.

Shared connections instead of per-agent keys. Each person connects their own account and can share that connection with the organization, so agents and teammates aren't stuck waiting on whoever owns the login. Forty agents holding forty private credential sets means forty offboarding tasks nobody has a list of.

An identity per agent, with a name it isn't allowed to lie about. An agent has a handle, a display name, and an optional avatar, and it answers in the thread under its own name. Names that impersonate the platform or a privileged role are refused outright, so workos, slack, admin, security, support, everyone, here, and channel are reserved. When something goes wrong at forty agents, the first question is which one did it, and a name is the cheapest possible answer.

Scoped access instead of whatever the creator could reach. Every agent is scoped at creation: whether it can save files, whether it can write to memory, which integrations it may touch, which workflows it may run. Agent instructions can't override the platform's rules about safety, secret handling, or which tools it may call, which is what makes it safe to let anyone on the team write those instructions. Isolated memory, server-side secrets, audit logs, no standing superuser.

Reuse that removes the reason to fork. Skills are written once and used by every agent that needs them. Memory keeps what an agent learns instead of restarting from zero each thread. More than 150 integrations out of the box, plus anything with an API, is the difference between building an agent and requisitioning one.

Every item on that list is something we handled informally at one agent and couldn't handle informally at forty.

The next two years are likely about consolidation, not new capability

Most internal AI work over the next two years will be consolidation rather than new capability. The models will keep improving, and that will mostly not be the constraint. The work will be giving forty agents the identity and ownership model that four agents didn't seem to need.

If you're at stage two right now, the useful thing to do this quarter isn't another agent. It's writing down who owns each of the ones you already have. Skip that, and the fortieth agent you build is the one nobody can turn off.

Or skip ahead and try Atlas today.