Yesterday I stumbled on a LinkedIn post about a new open standard for packaging Agent Skills and MCP servers: Agent Plugins, built with collaboration from players like Vercel, OpenAI, Microsoft, AWS, GitHub and Cursor.
I won't lie: at first, I felt that familiar punch in the stomach.
A while ago, I had already felt the first signal when I read an article by @lukeocodes about the transformation from MCP to stateless. That was part of the same direction I had been exploring for more than a month with IRC-A — Internet Relay Chat for Agents. Then this new standard showed up, and for a second the impostor syndrome came back. If you have ever felt that, I recommend this piece by @sylwia-lask . When I told her I was feeling exactly that, she gave me a few kind words that stayed with me.
My first thought was: “How come nobody saw this before?”
Then a better thought showed up: maybe people are seeing it now. Maybe some of us just noticed a little earlier that the agent era was starting to repeat mistakes that software engineering already spent the last 20 years fixing.
And that is exactly why I wanted to write this: not to compete with Agent Plugins, but to complement it.
Agent Plugins solves a real problem: packaging
The new standard matters because it attacks something very concrete: portability.
If every agent client asks authors to rearrange the same components in a different way, the ecosystem becomes repetitive and fragile. A shared format for Skills and MCP servers creates a clean floor. That is good for builders, good for clients, and good for the ecosystem.
But once capabilities are packaged, another problem starts to appear.
Not “how do we ship this capability?”
But “how do we govern what happens when an agent discovers and executes it?”
That is the layer I have been obsessing with.
The question that keeps me up at night
Today, a lot of multi-agent systems are still built like tightly coupled graphs. We hardcode flows, overload prompts with tool schemas, give conversational agents too much privilege, and then hope nothing weird happens.
But production systems do not run on hope.
So the questions I have been trying to answer with IRC-A are:
- How does an agent discover the right capability without carrying every API schema in its system prompt?
- How do we authorize one specific execution, with one specific set of parameters, for a short period of time?
- How do we audit and trace what happened across a decentralized agent network?
- How do we make sure a reasoning agent never touches database credentials directly?
- How do we isolate tools so prompt injection cannot become lateral movement?
- How do we add or remove capabilities without redeploying the whole orchestrator?
In other words: Agent Plugins may standardize the suitcase. IRC-A cares about customs, the boarding pass, and who is allowed to open the cargo door.
What IRC-A proposes
IRC-A is my attempt to bring old, battle-tested software engineering ideas into the agent era: Smalltalk-style message passing, IRC-like logical channels, capability pooling, secure-by-default SDK base classes, and a strict separation between reasoning and execution.
At a high level, the architecture looks like this:
- Cognitive agents are stateless. They reason, delegate, and compose answers, but they do not own database drivers or long-lived credentials.
- A BFA Gateway acts as registry, governance layer, and semantic customs office. It does not carry business payloads; it registers identities, capabilities, channels, and signs short-lived authorization.
- Capabilities are discovered semantically. Instead of stuffing every tool schema into every prompt, an agent asks the gateway what it needs, and the gateway resolves relevant capabilities through a vector index.
- Logical channels mask discovery. An agent should not even see capabilities outside its authorized channels.
- Execution happens through isolated MCP tool servers. Only the execution layer holds physical connections to core databases and enterprise APIs.
- Authorization uses ephemeral delegated execution tokens. The gateway mints short-lived signed tokens; the receiving tool verifies them offline and rejects anything outside scope.
That is the part I believe can complement the current wave: less prompt-bloat, less coupling, more auditability, more resilience, and a much smaller blast radius when something goes wrong.
I do not want to compete with Vercel. I want to build with that ecosystem.
As an Argentine developer, seeing Vercel push this space hits close to home.
Guillermo Rauch is Argentine too. I do not know him, but I would be lying if I said I am not hoping some of these messages eventually reach his radar. Not because I want to say “I did it first” — that does not matter. What matters is that the same problems are becoming visible to more people, and that means the timing is finally right. And also because another great-scale solution coming from the same South GBA would be genial!
I believe Agent Plugins is an important step for portability. I believe IRC-A can be a complementary step for secure runtime governance. But the biggest thing IRC-A brings to the table is plug-and-play capability: new agents and tools should be able to register, be discovered semantically, and start participating without rewiring the whole system. And I believe the next generation of agents will need both: portable capabilities and controlled execution.
So this is me putting the flag in the ground.
I am building the SDK, the framework, the diagrams, the whitepaper, and now the uncomfortable part: the marketing. Door to door. Message by message. A pulmón, while being unemployed, working on my startup — where this solution was born to solve the problem of connecting B2B agents on the same network — and trying to push through it.
But I am convinced this conversation needs to happen.
If you are building agent infrastructure, I would love your feedback. If you are working on MCP, agent runtimes, plugin standards, or secure execution boundaries, I would love to compare notes. And if this resonates with anyone around the Agent Plugins ecosystem, even better.
Not as competition.
As a complement.
Top comments (1)
Packaging and runtime governance are distinct layers, agreed. The detail I would press on is that a short-lived signed token is only as safe as the decision it binds.
The token should name the subject and delegating actor, tenant, audience/server identity, exact capability plus schema/version digest, canonicalized parameter constraints, purpose, resource scope, side-effect class, expiry, nonce/delegation depth, and approval/decision ID. The tool must re-authorize those claims against current local policy at dispatch—not treat a valid gateway signature as permanent permission. Revocation and emergency deny need to beat token expiry.
Semantic discovery also needs a security evaluation of its own. An attacker can craft descriptions that rank into privileged channels or exploit stale embeddings after a capability changes. Filter by hard authorization before vector ranking, sign registry metadata, bind results to identity/version digests, and test adversarial descriptions, channel-crossing attempts, stale caches, plugin replacement, replay, and confused-deputy delegation.
Finally, keeping business payloads out of the gateway helps confidentiality, but authorization often depends on payload semantics. A useful split is gateway-issued coarse delegation plus tool-owned fine-grained policy and typed validation. That preserves isolation without turning the gateway into an omniscient policy oracle—or the token into a bearer-shaped bypass.