Why I Built the Routing Layer Before Any of the Agents (and Why You Should Too)

The agent that gets the demo time on AI Twitter is the one that does the impressive thing on stage. The agent that quietly makes everyone else's agents work is the one nobody films.

If you are an operator with a day job and you are trying to build a stack of AI agents that actually does work in your business, the second agent is the one to start with. Not the first.

I sell cars for a living. Twenty years in automotive retail. No tech background, no computer science degree. I have shipped 22 production AI agents in the last 18 months on evenings and lunch breaks, and the single most important one was a piece of boring infrastructure called Paperclip that no customer will ever see. This post is the case for why I built it first, and why I would tell you to do the same thing now if you are starting from zero.

What is a routing layer for AI agents and why does it matter?

A routing layer is the piece of infrastructure that lets one AI conversation reach multiple tools through one auth surface.

The shape of the problem is simple. If you want an agent that reads a Gmail thread, looks up a matching contact in your CRM, summarizes what you owe the customer, and creates a follow-up event on your calendar, that single prompt has to reach four different systems. Each system has its own auth flow. Each one has its own API shape. Each one has its own rate limits and quirks.

You can do this two ways. The bad way is to build four separate integrations into the agent itself. Now every agent that wants to do the same kind of cross-tool work either copies that integration code or reinvents it. Six months in, the codebase is a mess and the auth flows have rotted in half a dozen places.

The good way is to put the integration plumbing into one routing layer and let every agent use it. The agent just says what it wants. The routing layer handles the connection to the actual tool. When you add a new tool, you wire it once at the routing layer, not at every agent. When an auth token rotates, you update it in one place, not seven.

The standardized shape this routing pattern takes today is called the Model Context Protocol, or MCP. The spec is open. The reference implementation is open. It is the closest thing the industry has right now to a common standard for "this is how an AI conversation reaches a tool."

Why does building the routing layer first matter?

Because every other agent's quality depends on it.

If you build the routing layer first, every agent you build after it is small. The agent's logic is "do this thing using these tools," and the routing layer handles the connection. Adding a new agent takes hours, not weeks. The boring part is already done.

If you build the routing layer last, or never build it, every agent you ship has its own integration code stuffed into it. The third agent has copy-pasted the second agent's Gmail logic. The fourth agent has copy-pasted the third agent's calendar integration. The agents are individually fine, but the system around them is rotting from day one. The first time you need to change how your CRM is reached, you have to update five agents instead of one routing layer.

The sequencing rule that came out of building Paperclip first: ship the boring plumbing before the glamorous demo. The demo will not work without the plumbing anyway. Once the plumbing is there, the demo ships in an evening.

Should I build the routing layer myself or use an existing platform?

It depends on who you are and what you want.

If you are a single operator and you want full control over your data and audit trail, building a small routing layer on top of the open MCP spec is realistic in a few evenings of focused work. You get to control which tools are wired, how auth works, and where the logs live. The tradeoff is that you have to maintain it.

If you have a small team and the integrations you need are already covered by an existing MCP server published by the tool vendor, using that is a reasonable shortcut. You skip the build, you give up some control over the audit trail, and you accept that the integration is only as good as the vendor keeps it.

The trap is the no-code agent platform that promises everything. Those platforms work fine for the demo because the demo uses the tools the platform already integrates with. They break the first time your real workflow needs a tool the platform did not anticipate. That break is not a temporary problem; it is the wall you cannot get past without leaving the platform.

If you are evaluating, the question to ask the platform is concrete. "Can your routing layer reach this specific tool I use, in the exact way my workflow needs?" If the answer is "we are working on that integration," that is the wall. Plan around it.

What is the minimum a routing layer needs to do for a small operator?

Three things.

One. Reach the four or five tools you actually use every day through one auth flow. Most operators have a core set of tools. Email, CRM, calendar, file storage, sometimes a chat tool. The routing layer needs to reach all of them through one auth setup, not five.

Two. Log every action it takes somewhere you control. Not in the platform's dashboard. In a place you own. For my stack the audit trail lives in a private GitHub repo, written to by the routing layer on every action. When a tool call breaks, the error is in the repo. When an audit question comes up, the answer is in the repo.

Three. Fail in a way you can read. When a tool call breaks, you should see the error in plain text and know which integration produced it. The routing layer that swallows errors and silently retries is the routing layer that loses you data on a Tuesday and you find out on a Friday.

Anything past those three is an upgrade you do not need to start.

What does the build look like at the operator level?

Five steps that held for the build I did.

Step one. Pick a hosting target. Railway hobby tier for a backend service is the cheapest reliable option I have used. The MCP server runs as a small service inside Railway. Other reasonable hosts exist; pick one you can maintain.

Step two. Wire the auth for tool number one. Pick the tool you use most. Email is usually a good first pick because the integration pattern teaches you what every other tool's auth flow will look like.

Step three. Write a small set of MCP tool definitions for tool number one. Read this thread. Send a draft. List the last seven days of messages. Start small. Each tool definition is a few lines of code, plus the actual API call to the tool.

Step four. Test the auth and the tool calls from a model. Spin up a Claude or OpenAI conversation that uses your new routing layer. Ask it to do the simplest thing that touches the tool. Read the output. Read the audit log. Fix what breaks.

Step five. Add the next tool the same way. And the next. And the next. The shape of the work is the same for each one. The first tool takes the longest. The fourth tool takes hours.

What is the right question to start with?

It is not "which routing-layer platform should I buy." It is "which tools do I actually need to reach from a single AI conversation, and is the open MCP spec the right standard for me to build on."

If you are an operator who wants to own the audit trail and ship agents at a real cadence, building on MCP is usually the answer. The spec is open, the model providers all support it, and the work compounds; every tool you wire makes every future agent faster to build.

If you are a small team that already pays for a platform that covers your tool set adequately, the build may not be worth it. You can revisit when the platform stops being good enough.

The broader documentation around how this stack fits together continues to update. The Anthropic developer docs and the Model Context Protocol introduction are the two pages I would tell an operator to read first.

If you want the full operator stack, including the routing layer and the agents that ride on top of it, the 10 agents lead magnet walks through all of it. The community where we ship in public is at skool.com/agent-empire-4291. Free.

While I sell cars for a living.

Michael