Why We Pivoted from AI Automation to A2A Infrastructure

I want to write the honest version of this, not the press release version.

The press release version would say something like: "After deep market research and customer discovery, we identified a massive gap in the emerging A2A ecosystem and made a strategic pivot to capture first-mover advantage."

That's not what happened.

What happened is we spent two years building AI automation for small businesses — real estate agents, dental practices, home service companies — and somewhere in month eighteen we looked at each other and said "we're spending all our time on the layer underneath what we're actually building." And then we looked around and realized everyone was doing the same thing, and nobody had built the layer.

So we're building it.

What We Were Building

Agentcy started as what the market calls "AI automation for SMBs." That covers a lot of ground: AI chatbots for lead qualification, voice receptionists, automated follow-up sequences, appointment booking flows.

It works. It works well, actually. A dental practice that deploys an AI receptionist answers calls at 2 AM instead of losing them to voicemail. A real estate agent with a lead qualification bot stops spending Sundays texting tire-kickers. The ROI is real and the clients see it.

We have this stuff in production. It generates revenue. We're not abandoning it.

But here's what nobody tells you about building AI automation at scale: eventually your "agent" needs to talk to other agents. The chatbot needs to hand off to the voice system. The lead qualifier needs to pass context to the follow-up sequence. The appointment booker needs to check with the scheduling agent.

And the moment that happens, you're building plumbing. Manual, bespoke, fragile plumbing.

The Duct Tape Phase

Our first multi-agent handoff was somewhere around month eight. Two agents, one context object, a shared database, and a lot of "if the previous agent set this field, then do this."

It worked. Until it didn't. We'd restart one agent for a hotfix and the other agent would lose track of the handoff state. We'd add a new channel and have to rebuild the context bridge from scratch. We'd try to add a third agent to the chain and the whole thing would buckle under the weight of our own assumptions.

So we rewrote it. Better this time. More robust handoff logic, cleaner context format, explicit state machine.

Then we rewrote it again.

By the third rewrite I started asking the uncomfortable question: why is this so hard? We're not doing anything exotic. We're passing structured data between processes. Humans figured out how to do this with supply chains and org charts and email. Why do our agents keep forgetting who they're talking to?

The answer, when I finally sat with it: there are no identity primitives for agents.

The Problem Is More Fundamental Than We Thought

When a new person joins a company, a bunch of infrastructure gets created. They get an email address. A Slack account. An entry in the org chart. Permissions to systems. Other people can look them up. When they walk into a meeting, people know who they are because there's infrastructure behind that identity.

When you create an agent, you get... a process ID. Maybe a name if you're organized. That's it.

Every time the agent restarts, it's a new entity. Every time it shows up in a different channel, it's a stranger. Every time you want two agents to collaborate, you have to manually configure the trust relationship between them. You are the trust layer. You are the identity layer.

This doesn't scale. And the more complex the agent network gets, the more it doesn't scale.

We started looking around to see if someone had solved this. We found bits and pieces — session tokens here, a custom identity scheme there, a framework that bakes in some assumptions about closed trusted environments. Nothing portable. Nothing that worked across frameworks. Nothing you could describe as infrastructure.

The layer doesn't exist. That's not a complaint. It's a gap worth filling.

The Pivot

We didn't flip a switch. It was more like gradually turning to face a different direction.

First we started documenting the patterns we kept reinventing. Then we started thinking about what a proper identity primitive for agents would look like. Then we started sketching specs. Then we had a conversation where we said out loud: "We should build this. Not as a side project. As the thing."

The old business stays. Real estate and dental and home services content has SEO value and the products sell. We're not burning that down.

But the PRIMARY thing — the thing we're actually building toward — is infrastructure. The identity, trust, and coordination layer for agent networks.

We're starting with identity because you can't build any of the rest without it. A Passport needs something to be a passport to. A Registry needs stable identifiers to register. Distribution needs to know what it's distributing to.

Identity is the foundation. We're drafting the spec now.

What We're Not Sure About

I said honest, so let me be honest about this part too.

We don't know exactly what the right identity primitive looks like. We have a draft spec with a lot of open questions explicitly called out — key rotation, self-sovereign vs. operator-issued, what fields should be mutable. We'll make decisions, build, and learn.

We don't know whether to build this as a protocol (spec that others implement), a library (reference implementation you can use), or a service (we run it, you call it). Probably all three eventually, but the sequencing matters and we haven't nailed it.

We don't know how fast adoption moves. This is infrastructure. Infrastructure adoption is slow. We're building for a world where multi-agent systems are common and people have actually hit these problems at scale. We think that world is close. We might be six months early or two years early. Building anyway.

What we do know: every developer we've talked to who's built multi-agent systems has a version of the same duct-tape story. The problem is real and it's widespread and nobody has built the layer.

Why We're Writing About It

Because the useful posts are the ones that aren't finished yet.

We're going to write about what we're building as we build it. The specs, the design decisions, the things we tried that didn't work, the things we're uncertain about. Not polished case studies — working documents.

If you're building multi-agent systems and you've hit these problems, we want to hear from you. Not in a "book a demo" way. In a "let's figure this out together" way. The people who are living this problem are the people who should be shaping the solution.

---

Agentcy.services — Building A2A infrastructure in public.
Follow the build: github.com/Kosfootel/Agentcy-services