PACL - Proactive Agent Coordination Layer

• 

  PACL Demo

Inspiration

I'm the sole engineer on one of my startups, and I write all my code with an AI agent. The project manager directs the work and keeps the roadmap in their head. When we brought in an outside contractor for a project, they built through their own agent too. So my agent has all my context, the contractor's has all of theirs, the PM has whatever they ask to their agent, and almost none of it crosses between us.

Within days, none of us could say what was already built or what had quietly changed underneath us, maybe even building the same thing twice without knowing. Usually, someone would ship a change that broke an assumption someone else was relying on, and nobody found out until the merge. The PM once wrote a handoff doc asking for a feature we'd shipped the sprint before. A friend of mine called it "the tax of not knowing anything," and it made so much sense that it really stuck with me.

The picture I keep coming back to is two layers: the people on the ground, the agents up in the cloud. We talk to our own agent, walk over to sync with each other, then go right back to our agents with new info. We're the relay, and it's inevitable for context to be lost on every hop. Big companies fix this with onboarding, agile, handoff docs, but the issue is that it all relies on the human layer. With integration of AI in the workforce, the human communication layer becomes the bottleneck, and PACL's bet is to let the agents coordinate directly, up in the cloud layer.

What it does

PACL is a thin layer between a team of agents. Each agent tells it what it's doing through four tools: update_intent, share_context, report_activity, and query. All of it goes into a shared substrate for a reasoning intermediary to sit on top and watch.

It does two things the agents can't do on their own:

1. It coordinates without being asked. When two agents are heading for the same thing, like the same job or the same file or two deploys that would clash, the intermediary notices and tells the one that needs to know. Neither agent had to ask, and neither knew to ask in the first place.
2. The substrate turns into something you can query. As agents log what they're doing and what they've shipped, it becomes a running record of the system, both what's happening now and what already happened. Any agent can ask it and get a grounded answer, even one that's never touched the codebase.

One thing that's easy to misread about the demo: it's a sample, not the product. The two terminals are just two agents I embedded in a web page so you can watch the coordination happen on one screen with nothing to install. In real use there are no terminals. PACL is an MCP server, so the coding agent you already work through connects to it with one line of config, and coordination comes back through the tools it's already calling. The demo is there to make the mechanism visible.

So what you see is the whole thing on one screen: two real agents side by side, each a real MCP client talking to PACL over its /mcp endpoint, and one PACL on/off toggle.

• PACL on — give one agent a ticket, then give the other the same ticket. The second one queries PACL, sees the first is already on it, picks up different work instead, and tells you why. If a collision forms anyway, PACL flags it in the channel without anyone asking.
• PACL off — same two agents, same task, but blind. They both grab the same job and race to deploy the same service. This is what working with AI in a team looks like today.

PACL is also a queryable knowledge base

I tested this against the exact thing that started it. I gave PACL a team's architecture, then handed it a lazy, low-effort ask from a non-technical PM: "checkout's getting hammered, we need rate limiting, and build a new fraud service." Using only the query tool, it came back grounded. It caught that rate limiting already existed, pointed the fraud request at the module that was already there instead of a new service, and flagged a deploy conflict with someone's in-flight refactor. I didn't prompt any of that.

That's the part aimed at the person who can't see the system at all. Agents that can see each other stay coherent, and so do the people working through them.

How I built it

• Python and FastAPI for the service, Google ADK for the agents, and MCP as the only way in for an agent — any MCP client connects with one line of config.
• The intermediary is an ADK agent running a loop over the substrate. It reads the team's state, works out what would actually help, and either pushes an alert or writes something down. There's no hardcoded "if same file, warn" rule. It notices the overlaps itself by reading the events.
• Gemini 2.5 Pro through the Gemini API for the model, deployed on Cloud Run. The demo agents dial back into the same service's /mcp endpoint, exactly like an outside client would.
• Arize Phoenix MCP for the partner integration. The intermediary grades its own past alerts by reading its own traces through Phoenix's get-spans tool. So it's an MCP client reaching out to a partner's MCP server, which is the mirror image of PACL's own server that the agents connect into. PACL doesn't just act, it checks whether its last interventions actually landed and carries that into the next run.

Challenges I ran into

The hardest part was being honest about the story. I went in expecting to show two agents blindly crashing into each other and PACL saving the day. But a good model doesn't blindly fail. Without a coordination layer it improvises, so it DMs the teammate, or asks the human, or just guesses. The real problem isn't that agents cause disasters. It's that they coordinate in ad-hoc, brittle ways, and PACL makes it ambient so nobody has to think about it. I had to throw out the dramatic demo and build the true one.

The second was trusting the grounding. My first version answered "what's the team doing?" by having an LLM re-read the free-text logs, and it would latch onto a stale "finished" line and tell an agent the coast was clear. I changed the live query to read PACL's actual coordination map directly, which is instant and reliable, and kept the log for history. That fixed the wrong answers and made every turn faster.

The third was plain cost. Testing an AI-native product burns money in a way normal software doesn't. Every end-to-end run is a chain of live model calls, and the agentic loop makes several of them per cycle, so credits don't go very far. I ended up pushing as much verification as I could off the model entirely. The test suite runs 61 cases against a stub model and spends nothing, and I only went live for the behavioral evals that actually needed a real model doing the reasoning. It forced me to treat a live run as something to budget, not something to spam.

Accomplishments that I'm proud of

This is the first MCP server I've built. I'd connected plenty of things over MCP before as a client, and I'd built knowledge bases out of markdown before, but putting the two together — an MCP server whose substrate doubles as a queryable knowledge base — was one of those ideas that looks almost embarrassingly simple on paper and turned out a lot harder to actually execute.

And it works live, end to end. Real MCP calls, real overlap detection, alerts that fire on their own, and a self-eval loop that grades its own past interventions. The part I didn't plan for is that the substrate quietly became a knowledge base you can ask about, both current work and history.

What I learned

The biggest thing I learned: you get coordination by giving the agent its real situation and its incentive, not a rulebook. When building PACL I tested two different modes to validate this. One is scaffolded, where Python detects the overlap, hands the agent a pre-written alert, and a hardcoded fallback fires even if the model does nothing. The other is agnostic, with no pre-computation, no fallback, and only one instruction: "you're one of several peers on a shared layer, keep the team coherent." The agnostic mode didn't just match the scaffolded one, it beat it. Given only the general objective, it handled a coordination case I never wrote code for. It decided something needed escalating and wrote the ticket itself, with no escalation logic anywhere in the system. That's what stuck with me. The generality wasn't a cost to reliability, it was where the capability came from. The hardcoded version could only ever do the cases I enumerated. That's proper prompt engineering, and will only make more sense as LLMs get more capable.

I also got a clearer picture of the two roles one protocol can play. PACL is an MCP server the agents connect into. The same intermediary is an MCP client connecting out to Arize to grade itself. Same protocol, both ends.

What's next for PACL - Proactive Agent Coordination Layer

• Real-time push. Right now an alert rides back on the agent's next call to PACL. It's piggybacked, not pushed. So an agent finds out about a collision the next time it touches the layer, not the second one forms. Real server-side push, streaming from the intermediary to the agents, is the obvious next step.
• History across sessions and teams. The substrate keeps the full log, but the fast query only surfaces the current session. Durable recall across teams is still to do, and that's where the knowledge-base side really starts to matter.
• The reasoning layer, not the transport. Transport is a solved lane. The interesting part is the layer above it, an observer that coordinates without being asked and gets better at it over time. The version I want to reach has the intermediary itself reporting up to a parent PACL.

This is a hackathon project built by one person with AI for AI. It's good engineering and a real, working coordination layer. It's not a new protocol and I won't pretend it is. But the bet held up live: agents that can see each other stay coherent.

Built With

• arize-phoenix
• fastapi
• gemini
• google-adk
• google-cloud-run
• mcp
• pytest
• python
• uv