DEV Community: Sandro Garcia

Agent Plugins Package Capabilities. IRC-A Asks: Who Authorizes Them at Runtime?

Sandro Garcia — Wed, 12 Aug 2026 13:46:36 +0000

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.

Spent the weekend enjoying the beach, but also put some work into launching the official site for the IRC-A Protocol 🌊🚀 For anyone curious to learn more, collaborate, or just send some emotional support: https://irc-a.org

Sandro Garcia — Mon, 10 Aug 2026 14:21:56 +0000

IRC-A Protocol · Technical documentation for developers

Official site of the IRC-A Protocol (Internet Relay Chat for Agents): decentralized agent networks, semantic capability routing and secure-by-design architecture.

irc-a.org

Are we Fighting the Wrong Fight with AI? It's Not a Model Problem, It's an Architecture Problem

Sandro Garcia — Fri, 07 Aug 2026 19:58:19 +0000

I just read AI Coding, One Year Later: What August 2025 Didn't See Coming by @lukeocodes, and one section stopped me cold. Not the benchmark tables — the last one:

"Despite the model gains, code review is still the bottleneck. The PR queue gets longer. Architecture decisions still need a person. The models are better at implementing within patterns but not at deciding which patterns to use."

Everyone reads that and thinks: we need a better model.

But do we? Or are we fighting the wrong fight?

Are we stuck in the brute force era?

Look at where the industry's energy goes. Bigger context windows. Higher SWE-bench scores. More guardrails, more tools, more credentials hanging off a single "AI brain" that we keep trying to make omniscient. We take one model, surround it with forty tool definitions, stuff its system prompt with JSON schemas, routing rules, and behavioral constraints — and then act surprised when it's slow, expensive, and still can't decide which design pattern fits the problem.

Is this brute force? And if it is — does brute force have a ceiling, not because the models are bad, but because the system design around them is?

What did Ford figure out 113 years ago?

In 1913, Henry Ford didn't build a better craftsman. He built a better system.

Before the moving assembly line, building a Model T took over 12 hours of highly skilled labor. Ford's insight wasn't "find stronger, smarter workers." It was: decompose the problem, give each station one task, and let specialization compound. Assembly time dropped to about 93 minutes. That system — designed 113 years ago — still runs every factory on Earth.

Now look at how we build AI systems in 2026. Aren't we still searching for the master craftsman? One giant model that knows everything, holds every credential, and does every task?

What would Ford say about that?

What if we built small specialists instead of one big brain?

So here's the question I keep coming back to: what would happen if we stopped trying to build the perfect generalist brain, and started building the production line instead?

Imagine a network of small, specialized agents:

A Pattern Agent that knows design patterns deeply — and only that. Its single job: given a problem and real data, decide which pattern fits best. Not "a model that also does architecture." A specialist.
A Coding Agent that implements within the pattern it was handed. No architectural debates, no scope creep.
A Research Agent that gathers context and documentation.
A QA Agent that reviews output against acceptance criteria.

Each one with a tiny system prompt. Each one knowing its own responsibility and nothing else. Each one asking the others for help when a task falls outside its specialty — the same way a welder on Ford's line never needed to know how to paint.

Wouldn't that directly answer the "what hasn't changed" section? Architecture decisions need a person today — but is that because the models are weak, or because we keep asking one bloated generalist to make them inside a 5,000-token system prompt crowded with tool schemas? What could a specialist do, if its entire context window were dedicated to pattern selection and fed real data instead of everything at once?

Haven't we solved this engineering problem before?

Here's what frustrates me: haven't we known how to build systems like this for decades? Did we just forget?

Smalltalk taught us that a healthy system is a set of isolated objects that communicate strictly through messages — no object inspects another's internals. Microservices taught us that small, independently deployable units beat monoliths. IRC showed us in the 90s that thousands of autonomous entities can coordinate dynamically just by joining channels, without central orchestration.

I spent over a decade building mission-critical systems in banking (Citibank, Bloomberg), and the pattern was always the same: the systems that survived had rigorous separation of responsibilities. The ones that collapsed were the monoliths. Why would agentic systems be any different?

Those questions are what pushed me to design IRC-A (Internet Relay Chat for Agents), an architecture that asks: what if...

Agents were stateless specialists that never hold credentials, database drivers, or knowledge of the wider ecosystem? "An intelligent agent should never know the ecosystem it runs in. It should only know its own responsibility."
Discovery were an infrastructure concern, not an intelligence concern? Agents wouldn't carry tool schemas in their prompts. They'd ask a lightweight gateway "who can do X?", get a cryptographically signed ticket, and talk to that specialist directly, peer-to-peer.
Prompt-bloat simply died? Specialist nodes would receive minimal, rewritten, structured prompts — not the entire conversational history. Time-to-first-token drops, costs stay flat, and indirect prompt injection gets neutralized because there's nothing malicious to inherit.

Traditional frameworks distribute knowledge — every node must understand the whole graph. Is that why adding one capability means refactoring and redeploying everything? What if we distributed capabilities instead: plug a new specialist into the network and it's discoverable immediately. No redeploy. No broken DAG.

So — are we fighting the wrong fight?

The models doubled their benchmarks in twelve months. Genuinely impressive. But if your architecture forces a single agent to hold forty tools, ten thousand tokens of system prompt, and credentials it should never have — won't a 95% SWE-bench model still drown in the same bottleneck?

Ford didn't wait for superhuman workers. He designed a system where ordinary specialization produced extraordinary output.

We keep investing in the brain. Isn't it time we invested in the factory floor?

Or am I wrong — is the superhuman craftsman really one model generation away?

I'm Sandro García, a solutions architect with 20+ years in financial systems and the author of the IRC-A protocol whitepaper. I'd genuinely love pushback on this: where does the specialization argument break? What's the strongest case for the single-brain approach?

I have 2 weeks in the community and I'm loving! Instead read news meanwhile my agents works, I read information, tech news and thoughts of people like me talking from the experience. I was bored of LinkedIn posts but here is real people +real problems . 🤗

Sandro Garcia — Thu, 06 Aug 2026 17:09:01 +0000

From n8n to IRC-A: a week migrating a real project — and a 679-token bill that's hard to believe

Sandro Garcia — Thu, 06 Aug 2026 11:30:00 +0000

I went a bit quiet last week. The reason: I was heads-down working on the framework to complement the SDK. And what better way to build a framework that's genuinely useful and simple to use than starting from a real project — and seeing what functionality can be "packaged" into it?

So I spent the week migrating an old customer-service project from my wife's business, from n8n to IRC-A. And every time I use this approach, I fall in love with it a little more.

The magic (not black magic): extending the system with a single `curl`

It's amazing to watch: you build an agent or an MCP tool, connect it to the server, and two seconds later your multi-agent system's capabilities have grown. No extra code. No component knowing about any other. No drawing graphs and edges. Just this:

curl -X POST "http://[irc-server]/register/agent?url=http://[agent-url]&channels=%23content"

This is the magic Alan Kay envisioned with Smalltalk — objects sending messages to each other without knowing one another — brought to the agentic era.

A real log, unedited

So this doesn't sound like marketing, here's a real log from the running system. The user asks the chatbot: "How many customers did we have in August?"

main-agent       | [Chatbot] Message received in crm session: How many customers did we have in August
customers-agent  | [Customers Agent] Processing query: 'How many customers did we have in August'
customers-agent  | [Customers Agent] Technical intent refined by LLM: 'count_customers_by_date CRM'
customers-agent  | [Customers Agent] /discover Raw Response: {"status":"success","det":"v4.public.eyJ...","url":"http://host.docker.internal:8003","target_node_id":"count_contacts","type":"tool"}
customers-agent  | [Customers Agent] BFA Gateway indicated calling -> Type: 'tool', Destination: 'http://host.docker.internal:8003'
customers-agent  | [Customers Agent] Schema for Tool 'count_contacts' per BFA/Fallback: {'type': 'object', 'properties': {'from': {'type': 'string'}, 'to': {'type': 'string'}}}
customers-agent  | [Customers Agent] Extraction LLM response: '{"from":"2026-08-01","to":"2026-08-31"}'
customers-agent  | [Customers Agent] ---> FINAL PARAMETERS TO SEND TO 'count_contacts': {'from': '2026-08-01', 'to': '2026-08-31'}
customers-agent  | [Customers Agent] Invoking P2P Tool 'count_contacts' at http://host.docker.internal:8003/tools...
customers-agent  | [Customers Agent] P2P Tool 'count_contacts' Response: "{\"count\":21}"

Read that log again and notice the important part: nobody knows anybody.

The main-agent doesn't know the customers-agent exists, and it doesn't know the count_contacts tool either. It only knows its own job: talk to the user and fulfill their request, asking the Gateway for assistance.
The customers-agent doesn't know the main-agent, nor the count_contacts tool. It only knows its responsibilities, defined in its agent-card:

agent_id="customers_agent",
name="Customers Agent",
description="Agent in charge of handling any kind of task on the customers and contacts database. It connects to the EspoCRM CRM through its MCP and exposes tools to query, add, update and delete contacts.",
tags=["customers", "contacts", "leads", "crm"],
examples=[
    "I want the list of customers from last month",
    "how many new customers did we have this month",
    "how many contacts do we have",
    "how many contacts are registered",
    "Add the customer 'John Doe' with phone 123456789",
    "Update 'John Doe's phone to 987654321",
],

And its prompt is as simple as this:

system_prompt = (
    "You are the specialist agent for CRM customers/contacts. "
    "Convert the user's request into a single short MCP tool-search phrase (e.g. 'count_contacts CRM', 'search_contacts CRM') "
    f"to look up the right tool on the BFA network for: '{user_message}'"
)

Here user_message has already been refined: an earlier LLM pass distills the exact intent, shortens the message, and cuts unnecessary token spend.

The full flow:

The agent refines the intent: "count_customers_by_date CRM".
The BFA Gateway tells it who to call, hands over the authorization token (DET) and the parameter schema.
The agent extracts the parameters and invokes the tool P2P.
Result: {"count": 21}.

Without anyone knowing anyone — or any tool — we got the answer. It's that simple.

The other number hiding in that flow: 679 tokens

Here's the part that made me stare at the LangSmith dashboard for a while.

During testing, a user had a complete two-turn interaction with the system: they asked whether a contact existed in the CRM (she didn't), then asked to add her with name and phone number (done). That flow involved 2 agents coordinating, 4 LLM calls, and an MCP tool execution.

The total cost: 679 tokens. Less than a tenth of a cent.

The per-call breakdown (gpt-4.1-mini, temperature 0, straight from the traces):

Step	LLM call	Tokens	Cost
Lookup	Intent refinement → `search_contacts CRM <name>`	103	<$0.0001
Lookup	Parameter extraction for `search_contacts`	192	<$0.0001
Insert	Intent refinement → `add_contact CRM <name> <phone>`	135	<$0.0001
Insert	Parameter extraction → `{"firstName": ..., "lastName": ..., "phone": ...}`	249	$0.0002
Total		679	< $0.001

For context: a typical agentic loop dragging its full conversation history and tool state through every step easily burns 5k–10k tokens per task. This is two orders of magnitude less. Why?

LLM calls are surgical. The model is used exactly twice per agent turn: once to distill intent into a short search phrase, once to extract parameters against a JSON schema. No endless chit-chat, no history re-feeding.
Discovery and routing cost zero tokens. Finding who to call is FAISS vector search over capability metadata — deterministic, fast, and free of LLM involvement.
Execution is P2P. Once the agent knows the destination and holds its authorization token (DET), it talks directly to the tool. There's no central orchestrator inflating every step with system-wide context.

Efficiency in agent systems isn't achieved with shorter prompts. It's achieved with architecture — using the LLM where it adds value (understanding, extracting) and not where it doesn't (searching, routing, authorizing).

The week's real value: what a real project taught the framework

As I said, the goal was to improve the SDK and isolate what matters most for the framework. And this mini-project worked exactly as hoped: migrating something real exposed friction I would never have found writing toy tests. Here are the 6 improvements that came out of the week:

1. Semantic routing and circular interception in FAISS

The problem: when asking "how many new customers were added from July 27th to 30th?", the Gateway returned the main_agent itself as the destination instead of delegating to the customers_agent or the MCP tool. This created circular invocation loops customers_agent -> main_agent -> customers_agent, which were rejected with an error.

The cause: the main_agent's descriptions and examples contained broad domain keywords ("customers", "contacts", "tasks"), making its embedding vector overlap with the specialists' vectors in the Gateway's FAISS index. On top of that, the customers_agent was sending generic search phrases that didn't indicate it was looking for MCP tools.

The fix: I narrowed the main-agent's description down to purely conversational welcome tasks, and instructed the customers-agent's LLM to generate short search phrases explicitly oriented toward MCP tools ("count_contacts CRM"). Architectural lesson: in semantic routing, agent descriptions are the routing contract — if they overlap, the system gets confused; if they're precise, the system routes itself.

2. Empty `{}` parameters caused by the Gateway omitting `input_schema`

The problem: the count_contacts tool was receiving empty arguments {} and returning the unfiltered total count; save_contact failed with ValueError: at least one field is required to create the contact.

The cause: the Gateway's /discover endpoint sometimes returned "input_schema": {} instead of the registered JSON Schema. The agent's parameter-extraction LLM, upon receiving an empty schema, correctly concluded the tool took no parameters.

The fix: a fallback table KNOWN_MCP_SCHEMAS in the agent. If the Gateway returns an empty schema for known tools, the agent dynamically injects the fallback JSON Schema, ensuring the LLM extracts from, to, firstName, phone, etc., in ISO format. The agent becomes resilient to an imperfect Gateway — defense in depth applied to multi-agent systems.

3. The Gateway's Pinger was deregistering live agents

The problem: the logs periodically showed:

[DISCOVERY] http://customers-agent:8311: Endpoint is dead/unreachable. Automatically unindexed from FAISS.

The agent was alive, but the Gateway kept delisting it.

The root cause (my favorite of the week): during synchronous LLM calls, Python blocked Uvicorn's event loop on the main thread. When the Gateway's Pinger sent GET /tools every 3 seconds, the agent couldn't respond in time, and the Gateway assumed the container had died.

The fix: make LLM invocations asynchronous:

await asyncio.to_thread(llm_router.generate, ...)

The event loop stays 100% free to answer health checks at 0ms in the background. A classic concurrency bug disguised as a network bug.

4. Hardcoded ports and URLs

Agents were trying to register using stale fallbacks (127.0.0.1:8003, port 8005) that conflicted with the Docker setup. The obvious but necessary fix: everything comes from the environment. CUSTOMERS_AGENT_PORT, MAIN_AGENT_URL, BFA_GATEWAY_URL — zero magic values in the code.

5. `No module named 'llm_router'` inside the containers

When running the agent from its subdirectory, the project root wasn't on Python's sys.path. A two-move fix: insert the root directory at the top of the script, and declare PYTHONPATH=/app in docker-compose.yml.

6. MCP registration failing due to an incomplete path

# ❌ This failed with "Failed to discover MCP tools":
curl -X POST "http://localhost:8000/register/mcp?url=http://host.docker.internal:8003/mcp"

# ✅ This registered all 10 CRM tools in one shot:
curl -X POST "http://localhost:8000/register/mcp?url=http://host.docker.internal:8003&channels=%23deotroangulo"

The Gateway expects the root base URL, from which it dynamically discovers the endpoints. A small framework UX detail that's now documented and polished.

Why I insist this is architecturally clean

After this week, I can say it with more confidence than ever:

Total decoupling: the main-agent and the customers-agent don't know each other. Tomorrow I could delete the customers-agent and register a new one written in another language, and the system wouldn't even notice. That's real maintainability, not theoretical.
Discovery, not configuration: capabilities register themselves and are discovered semantically via FAISS. No graphs to redraw, no edges to rewire when you add a node.
Security in the protocol: the Gateway issues a token (DET) carrying the permitted action, the issuer, and the audience. Authorization travels with discovery.
Contained failures: every bug from this week was fixed in a single component. Not one fix required touching the other agents. That's the acid test of a clean architecture: changes stay local.
Efficiency by design: 679 tokens for a full lookup + insert flow isn't an optimization trick — it's what falls out naturally when the LLM only does what only the LLM can do.

Migrating away from n8n wasn't just a tooling change: it was moving from a hand-drawn workflow to a network of agents that organize themselves. And best of all, the framework came out of the week stronger — because every difficulty found in a real project became a permanent SDK improvement.

Are you using n8n, LangGraph, or another orchestrator? How do you handle capability discovery between agents — and have you ever measured tokens per task? I'd love to hear about it in the comments.

Why Banking Still Doesn't Have an AI Architecture—And What I Built to Fix It

Sandro Garcia — Wed, 05 Aug 2026 17:11:19 +0000

Why Banking Still Doesn't Have an AI Architecture—And What I Built to Fix It

Twelve years at Citibank and two at Bloomberg taught me one thing: banks don't need better models. They need an architecture that respects how banks actually work.

By Sandro Garcia

In 2015, I was sitting in a Citibank operations room in Buenos Aires, watching a conciliation batch fail because an Oracle stored procedure had a date-format mismatch with a SQL Server instance from an acquisition three years prior. The fix took four hours. The business impact was zero—because the batch was designed to fail safe, alert, and wait for human validation.

That night, I learned something that no consultant deck will ever teach you: banks are not broken. They are engineered to survive failure.

The AS/400 that runs your wire transfers was not designed to be "modern." It was designed to never lose a penny. The SQL Server that holds your AML alerts was not built for real-time API consumption. It was built to generate a report that a compliance officer can print, sign, and file. The data warehouse that feeds your regulatory reporting runs at 2 AM because the regulator does not care about your "real-time AI." They care about a reconciled number.

This is the reality that every "AI for Banking" startup ignores. And it is why, after a decade of pilots, demos, and proof-of-concepts, banking still does not have a production-grade AI architecture.

Not because the models aren't good enough. Because the architectures were built by people who never had to explain to a regulator why an LLM approved a mortgage.

The Problem Is Not the Data. It's the Permission Model.

I spent years writing SQL against Citi's core systems. I built reports for the mesa de dinero. I integrated Oracle with SQL Server with flat files from acquired banks. I know exactly where the data lives.

And I can tell you: the data is there.

The customer exists in KYC. The credit score exists in the risk system. The transaction history exists in the core. The AML flags exist in the compliance database. They are reconciled nightly. They are governed. They are auditable.

What does not exist is a way to let an AI consume that data without becoming a privileged user of it.

Every agent framework I have evaluated makes the same fatal assumption: that the bank is a greenfield SaaS platform where an orchestrator can own credentials, inject schemas into prompts, and let the LLM "figure out" which table to query. This is not architecture. This is a breach waiting for a CVE number.

In a bank, giving an agent a connection string to the credit database is not a technical decision. It is a career-ending decision.

What I Saw in Every Failed AI Pilot

At Bloomberg, I watched fintech after fintech pitch "AI-powered credit decisioning." The demos were beautiful. The models were impressive. The pilots died the same way every time:

The agent needed data from three systems. So the integration team opened three connections.
The agent needed context. So they embedded the full database schema into the system prompt.
The prompt grew to 10,000 tokens. Each LLM call cost a dollar. At scale, the business case collapsed.
The compliance team asked: "Who approved this access?" Nobody had an answer. The pilot was shelved.

The pattern was always the same. The model worked. The data was available. The architecture was the failure.

And the root cause was always the same: the AI was given the same access patterns as a human analyst, but without the same accountability.

A human analyst who queries the credit database leaves an audit trail. They have a user ID. Their query is logged. Their access is role-based. When an LLM agent does it through a connection string embedded in a Docker container, there is no user. There is no session. There is no trace that a regulator will accept.

IRC-A: Built from the Inside

I left Bloomberg knowing that banking would not adopt AI until someone built an architecture that spoke the language of the bank: segregation of duties, batch reconciliation, immutable audit trails, and the absolute certainty that no agent would ever hold a database credential.

IRC-A is that architecture. Not because it is clever. Because it is boring in the right ways.

The Core Insight: The Data Stays. The Access Changes.

IRC-A does not ask you to migrate your Oracle database. It does not ask you to replace your AS/400. It does not ask you to build a "unified customer view" that takes five years and fifty million dollars.

It asks you to do one thing: put an MCP server in front of each system, and never let the agent touch the system directly.

Here's how it works in practice:

Your CreditRiskMCP server runs in an isolated container. It has the Oracle driver. It has the read-only credentials. It knows the schema. It is the only thing that ever queries the credit database.

Your AMLMCP server runs in a different container. Different credentials. Different schema. Different channel.

The agent—stateless, credential-free, schema-free—sends a natural language intent to the BFA Gateway: "I need to evaluate credit risk for customer ID-882."

The Gateway performs a semantic vector search, finds the CreditRiskMCP, verifies that both the agent and the tool share the #credit-audit logical channel, and issues an Ephemeral Delegated Execution Token (DET).

This token is:

Cryptographically signed by the Gateway.
Time-bound (expires in minutes).
Parameter-locked (only fetch_credit_score(customer_id="882") is allowed).
Auditable (every token issuance is logged with a trace ID).

The agent calls the MCP server directly. The MCP server validates the DET offline—no round-trip to the Gateway—and executes the query. It returns a sanitized JSON payload. The agent never saw a schema. Never held a credential. Never had the ability to do anything other than what was explicitly authorized.

When the regulator asks, "how did the AI approve this mortgage?" you don't reverse-engineer a prompt. You show them the DET, the channel membership, and the sanitized response. The audit trail is the architecture.

Why This Matters: The Trading Desk Test

I have a mental test for any AI architecture proposed for banking. I call it the Mesa de Dinero Test:

If this agent fails at 5:45 PM on a Friday, can the Trading Desk close its batch on time without it?

Most agent architectures fail this test. They are tightly coupled to the core. They run in the critical path. If they go down, the batch stops.

IRC-A passes because it is decoupled by design. The MCP servers are adapters, not replacements. The core systems keep running their batches. The agents consume the outputs when they need them. If the AI cluster goes down, the bank keeps operating exactly as it did before.

This is not a bug. This is the feature that makes a bank CIO sleep at night.

The Token Economics Are Real

Here is something I measured myself. A traditional agent framework carrying twelve tool schemas in its system prompt consumes between 4,000 and 8,000 tokens per call before it even starts reasoning. At scale—fraud detection, customer service, mortgage underwriting—that is not a cost. It is a budget fire.

In IRC-A, the agent carries zero schemas. It describes its intent in natural language (~50 tokens). The Gateway resolves the capability via vector search. The agent receives a single route and a DET.

The difference is not marginal. It is the difference between a viable AI operation and a pilot that gets killed in the Q3 budget review.

The Gap No One Is Talking About

Go to any AI conference. You will hear about agents, RAG, fine-tuning, and multimodal models. You will not hear a single talk about how to make an AI architecture auditable to a banking regulator.

This is the gap. This is why, after years of investment, banking AI is still 90% pilot and 10% production.

The banks that will win are not the ones with the biggest LLM budgets. They are the ones that solve the governance problem first. They are the ones that build—or adopt—an architecture where:

Agents are stateless and credential-free.
Data access is mediated, parameterized, and logged.
Discovery is semantic, not hardcoded.
Audit trails are generated by the protocol, not bolted on afterward.

IRC-A is my proposal for that architecture. It was not designed in a hackathon. It was designed in the space between a conciliation batch and a compliance report, by someone who knows that in banking, the most advanced model in the world is useless if it cannot prove why it made the decision it made.

Conclusion: The Architecture Banking Has Been Waiting For

Banks do not need another data lake. They do not need another "unified customer view." They do not need an AI platform that promises to replace their core.

They need an architecture that says: your systems are fine. Your data is fine. Let's just consume it safely.

IRC-A is that architecture. It is not a revolution. It is a secure access layer for a world that already works.

And maybe—just maybe—it is the first AI architecture that a bank can actually adopt without betting the institution on it.

Sandro Garcia is the creator of the IRC-A protocol and BFA-SDK. He spent 12 years as a tech lead at Citibank and 2 years at Bloomberg, building systems for conciliation, regulatory reporting, and trading operations before designing secure multi-agent architectures for regulated industries.

IRC-A: Agents on the Wire — The Series Kicks Off 🚀

Sandro Garcia — Tue, 04 Aug 2026 17:50:40 +0000

TL;DR: I'm starting a series where I'll document, out in the open and unfiltered, everything I've been testing and researching around IRC-A (Internet Relay Chat for Agents): the protocol, the SDK, the framework, the experiments that work, and the ones that blow up along the way.

Why this series?

For a while now, I've been hooked on an idea: what if AI agents had their own "IRC"?

Not a chat for humans, but a network where specialized agents register, announce their capabilities, discover each other, and collaborate to get tasks done — just like we used to do in the IRC channels of the 90s/2000s, but at machine scale.

That idea became IRC-A (Internet Relay Chat for Agents), a protocol for decentralized agent networks with semantic capability routing and secure-by-design architecture. And alongside the protocol, the BFA SDK, an open-source Python framework to actually implement it — not just on paper.

The problem: all of that work is scattered across the repo, the whitepaper, my notes, and dozens of tests that never left the lab. This series is here to organize that chaos and share it.

What will you find in this series?

Everything related to IRC-A will live here, grouped into four content lines:

🧪 1. Tests & experiments

Semantic routing benchmarks with FAISS (how well does it route without exact keywords?).
Hot dynamic registration tests: agents joining and leaving the network on the fly.
Embedding provider comparisons: local (sentence-transformers) vs. cloud (OpenAI) vs. offline mock.
Cold-starts on AWS Lambda with the Mangum adapter: is a serverless gateway actually viable?

🔬 2. Research

The IRC-A whitepaper, broken down: decentralized agent networks, semantic capability routing, and secure-by-design architecture.
Cryptographic registration handshakes (asymmetric challenge-response).
Logical channels and channel masking: segregating vector search spaces per channel (#public, #banking, etc.).
DET (Delegated Execution Tokens): direct P2P invocation with no gateway bottleneck.

🛠️ 3. The SDK (BFA SDK)

BFAAgent: building A2A agents with declarative semantic metadata.
BFAMCP: exposing discoverable MCP tools with tags and examples.
BFAInteractiveAgent: coordinator agents with execution memory and subtask delegation.
Deployment with Docker, docker-compose, and the ready-to-use image on Docker Hub.

🏗️ 4. The Framework & architecture

The BFA (Backend for Agents) pattern: the gateway as a semantic middleware between consumers and agents.
The admin dashboard (React) to monitor the network in real time.
Design decisions, mistakes made, and refactorings along the way.

Who is this series for?

If you're into agent orchestration beyond "one LLM with tools."
If you work with A2A (Agent-to-Agent), MCP (Model Context Protocol), or multi-agent architectures.
If you like seeing real, open-source code — with its wins and its failures documented.
And if you ever missed the IRC philosophy — simple, open, federated — and wondered what it would look like applied to the agent era.

The starting point

Everything I'll be showing is published and open source:

📦 SDK repo: github.com/SandroG1977/bfa-sdk
📄 IRC-A Whitepaper v1.0.0: Decentralized Agent Networks, Semantic Capability Routing, and Secure-by-Design Software Architecture (link in the repo)
🐳 Docker image: sandro77/irc-a-gateway:latest

If you want to start playing around before the next post:

pip install git+https://github.com/SandroG1977/bfa-sdk.git
irc-a-gateway

What's coming next

The next article is already in the pipeline: "From n8n to IRC-A: a week building the framework while migrating a real project" — the story of migrating a real customer-service project off n8n, the 6 bugs it exposed (including circular routing loops and a Pinger deregistering live agents), and how each one made the SDK stronger. Real logs included.

After that, the tentative roadmap (subject to whatever I discover along the way):

#	Article (tentative)	Track
02	From n8n to IRC-A: a week building the framework while migrating a real project	🏗️ Framework
03	Your first IRC-A network in 5 minutes: Gateway + A2A Agent + MCP Server	🛠️ SDK
04	Semantic routing with FAISS: how the gateway "understands" queries	🔬 Research
05	The handshake: secure agent registration on the network	🏗️ Framework
06	Benchmarks: local vs. cloud vs. mock embeddings	🧪 Tests
07	DET tokens and decentralized P2P invocation	🔬 Research

Join the network 📡

This is just getting started, and feedback is gold: if you're building something with agents, if you see flaws in the approach, or if you just want to debate multi-agent architecture, the comments are open.

Follow the series so you don't miss the next posts, and if you're into the project, a ⭐ on the repo always helps.

See you on the channel. o/

Credits: the BFA pattern was originally designed and documented by Michael Douglas Barbosa Araujo. The BFA SDK is a community implementation and expansion of that concept.

The Unconference Asked the Right Questions. Here's One Architecture's Answers.

Sandro Garcia — Fri, 31 Jul 2026 07:12:52 +0000

I just finished the Thoughtworks Technology Podcast episode where Ken Mugrage, Kief Morris, and Andrew Harmel-Law debrief the unconference on the future of software engineering they ran in Switzerland with Martin Fowler (full transcript here).

If you haven't listened: the mood has shifted. A few months ago these conversations were "look at the shiny stuff." Now it's "We know this can work, but we need to answer these questions"

The episode is basically a tour of open problems in agentic engineering — trust, boundaries, control, governance — and what struck me is how many of them are infrastructure problems wearing a prompt problem's clothes.

Full disclosure before we start: I've spent the last months building IRC-A (Internet Relay Chat for Agents), a decentralized architecture pattern and SDK for multi-agent systems. So when I say "here's how I'd answer that," I have a specific, opinionated architecture in mind — take it as one practitioner's answers, not gospel. Now, the questions.

1. "You need infrastructure that doesn't allow it"

Early in the episode, Kief brings up a fear someone raised: what if the agent, left unsupervised, connects the development environment to the production database to grab some data?

His answer is the best line of the whole episode:

"No, you need to have infrastructure and systems that don't allow something running in your development environment to connect to your production database."

Exactly. And this is where I'd push further: in most agent architectures today, the conversational agent holds the database credentials. We then spend enormous effort on prompt engineering and code review to stop it from misusing them. That's controlling behavior through hope.

IRC-A draws a hard network boundary instead: only the FastMCP tool servers, running in isolated sandboxes, hold database drivers and credentials.

The reasoning agents physically cannot connect to anything transactional — they don't have the drivers, the credentials, or the network path. A prompt injection telling the agent to drop schema corporate_financials fails not because the agent refused, but because there's literally nothing in its environment that could execute it. Security you don't have to remember to enforce.

2. Agents don't respect boundaries drawn in prompts

Andrew describes something anyone running agents on a real codebase has felt:

"Agents can roam around... they're very sycophantic, they want to do what you've asked them to do and make you happy. If you want them to do that while still... protecting some boundaries in a codebase, they highly possibly will not respect that. Even if you start with something clear, the edges can get blurred very fast."

His observation that teams are going back to microservices in separate repos "because this agent can't change this — it has no rights to change this codebase in this repo" is telling: we're rediscovering that boundaries only work when they're enforced by the environment, not described in instructions.

But splitting repos is a blunt instrument. IRC-A enforces the same property with logical channels: every node (agent or tool server) declares its channels via environment variables (IRCA_CHANNELS="#aml-restricted,#compliance-audit"), and the BFA Gateway masks capability discovery inside the FAISS index accordingly.

An agent on #finance can't even see that an AML tool exists — the capability is filtered out of the vector search before matching. The boundary lives in the infrastructure, where sycophancy can't talk its way past it.

3. Firmness: markdown < scripts < cryptography

Kief outlines a hierarchy of assurance: markdown skill files and AGENTS.md give you some guidance, but "scriptable tools that are executed and do particular tasks in a predictable way" are stronger. He calls them "levels of strength of assurance."

I'd argue there's a level above scripts, and agent systems need it: cryptographic constraint.

When an IRC-A agent wants to invoke a capability, the BFA Gateway mints an Ephemeral Delegated Execution Token (DET) — a PASETO token signed with Ed25519, scoped to one function, with parameter lockdown.

The tool server verifies it offline against the Gateway's public key and checks that the runtime arguments match the locked parameters exactly. fetch_customer_credit_score(customer_id="882") runs; the same function with "885" is rejected at the door.

A markdown file can be talked around. A script can be called with different arguments. A signature can't.

4. Who owns the harness?

Ken asks the organizational question — who owns the harness, the platform team? — and Andrew points at platforms that "bless" certain harnesses and skills so teams get non-functional requirements (compliance, data handling, replication) along with functionality, especially in regulated environments.

That maps directly onto IRC-A's separation: the BFA (Backend for Agents) is strictly a governance perimeter — registry, capability directory, cryptographic minting. It never runs reasoning loops and never touches transactional data. The platform team owns governance; product teams own execution. Governance as its own layer, or — as I've said before — it gets entangled with execution and both rot together.

5. Task-oriented specialists, not personalities

Both guests pushed back on giving agents "personalities," and Kief landed on the framing I agree with:

"Think about those workflows and which parts do you want to hand off to an LLM to carry out... it's very task-oriented."

IRC-A takes this to its conclusion: cognitive agents are stateless specialists with exactly one responsibility. An agent shouldn't know the ecosystem it runs in — only its own objective. No BA agent persona, no 73-agent org chart with an optimist and a cynic. Capabilities, not characters.

6. Stop doing control theater — control the boundary instead

The "theater of control" thread was the most philosophically honest part of the episode.

Andrew: "We've always had a lot less control than we thought we did." Kief questioning whether pull requests ever guaranteed catching human mistakes, "or is that just theater?"

My take: they're right that reviewing every line was always partial. But the conclusion isn't "give up on control" — it's move control to where it's deterministic.

IRC-A can't guarantee what an agent reasons, and doesn't try. It guarantees what an agent can execute: every inter-agent request carries a trace_id and a visited_nodes list, so circular delegation loops are detected and rejected by the SDK itself. Every execution requires a valid, scoped, unexpired DET. The reasoning is free; the boundary is not negotiable. Predictable where it matters — which is exactly the word Andrew suggests we use instead of "determinism."

7. Context without the bloat

There was a session on building an organizational knowledge graph so agents can "draw the right information that it needs without having to fill its context with everything." Yes — and this problem is bigger than knowledge.

Most multi-agent frameworks fill the context with everything: every tool schema, every API contract, the entire conversation history, on every single call. That's prompt-bloat, and it's why token costs scale so badly.

IRC-A attacks it from two sides. Semantic capability discovery: agents don't carry tool schemas in their prompts — they describe intent in natural language, and the Gateway's FAISS index matches it to a registered capability at runtime. And prompt rewriting at the delegation boundary: before delegating to a specialist node, the entry agent strips the conversational history and system instructions down to a minimal structured execution prompt. "Open a bank account for client John Doe, SSN 123-12-1323" — that's what travels, not the whole chat. The result, measured in LangSmith over complete roundtrips, is a practically fixed token cost per call regardless of session length. In my benchmarks against a traditional orchestrated setup, that difference came out to 18x.

What IRC-A doesn't answer

In the spirit of the unconference's honesty: the hardest questions in that episode aren't architectural. Where does the developer sit now? What survives of TDD?

How do we articulate to the LLMs why maintainability matters — the things Kief said we always struggled to articulate to management? IRC-A doesn't touch those.

It's an answer to a narrower question: what should the infrastructure under agentic systems look like if we take 30 years of software architecture seriously?

If you're working on that question too, I'd genuinely like to compare notes:

And thanks to Ken, Kief, and Andrew for an episode that asked better questions than most keynotes answer.

Steve Doesn't Need to Know About `git diff`: A Different Take on AI Agent Architecture

Sandro Garcia — Mon, 27 Jul 2026 14:37:12 +0000

A few days ago, @sylwia-lask published a brilliant article showing that an AI agent — her sarcastic code reviewer Steve — can be built in roughly 80 lines of JavaScript without heavy frameworks like LangChain or CrewAI.

Her post proves that frameworks aren't doing magic. But it got me thinking:

What if the real problem isn't the framework? What if the problem is that we give the agent too much responsibility in the first place?

The Traditional Agent: Steve Knows Too Much

Steve is a perfect example of the "classic" agent pattern. Look at what his cognitive layer must handle:

He knows the tools: getDiff, getFile, listFiles
He knows their JSON schemas and parameter types
He decides which tool to call and when
He executes them locally
He maintains the full conversation history with functionResponse payloads

In other words, the reasoning layer is tightly coupled to the execution layer. The LLM is doing infrastructure work.

Sylwia's agent.ts handles all of this beautifully, but those ~80 lines are doing a lot:

// Import types, declarations, tool mapping, retry logic...
const declarations: FunctionDeclaration[] = toFunctionDeclarations(tools);
// Handle rawParts for Gemini 3 thoughtSignature
// Map functionCall → local execution
// Build functionResponse messages
// Maintain full message history
// Handle 503 retries manually

It's elegant. But it's also brittle. If you add a new tool, Steve's prompt grows. If a schema changes, you redeploy Steve. If Steve is compromised, he has direct access to your repository.

What If Steve Knew Nothing?

I've been experimenting with a pattern called BFA (Backend for Agents), specifically the IRC-A protocol (https://github.com/SandroG1977/bfa-sdk).

The mental model is almost the opposite:

The core idea: Discovery is an infrastructure concern, not an intelligence concern.

How It Would Work for Steve

Instead of Steve carrying getDiff / getFile / listFiles in his system prompt, the flow looks like this:

Steve (a BFAAgent subclass) receives: "Review the current git diff."
He doesn't reason about tools. He simply asks the BFA Gateway: "I need help reviewing code changes."
The Gateway performs a semantic vector search (FAISS) over registered capabilities, finds a GitReviewMCP server, and returns:
- The direct endpoint URL
- An ephemeral DET (Delegated Execution Token) — a cryptographically signed ticket (PASETO) scoped only to review_git_diff for this specific repo

4, Steve calls the endpoint directly (P2P), presents the DET, and receives a sanitized JSON result.
He processes that result and writes the sarcastic review we all love. 😄

The Lines of Code Comparison
Sylwia's core loop is ~80 lines. With the BFA SDK, Steve shrinks to this:

from bfa_sdk.core.agent import BFAAgent

class Steve(BFAAgent):
    def __init__(self, url: str):
        super().__init__(
            agent_id="steve",
            name="Steve",
            description="Sarcastic senior engineer with 15 years of experience.",
            tags=["code review", "git", "diff", "pull request"],
            examples=["review my changes", "check this diff"],
            url=url
        )

    async def run(self, user_message: str, context) -> str:
        # The BFA Gateway handles discovery, DET minting, and routing.
        # Steve just processes the final sanitized result.
        return f"Steve's review: ..."  # sarcasm included

That's ~15 lines of actual agent logic.

The base class (BFAAgent) handles:
Registration & challenge-response handshake
DET token validation (offline, zero-trust)
Semantic discovery via the Gateway
Parameter lockdown and scope enforcement

Even Sylwia's agent.ts — ~80 lines — would drop to roughly 10–15 lines of domain-specific code.

The rest (security, routing, tool binding, retry logic, token validation) is inherited from the SDK or delegated to the Gateway.

The Deeper Point: Security by Design

Your for loop cap to prevent token burn is smart. IRC-A solves the same problem at the infrastructure level: DETs have a short TTL (exp), so even if an agent loops, the token dies and the loop stops.
But there's more:

If Steve doesn't know about git diff, he can't be tricked into leaking it via prompt injection.
If Steve doesn't hold DB credentials (the MCP server does), a compromised OS container can't access the database.
If the Gateway issues ephemeral DETs scoped to single operations, Steve can't accidentally (or maliciously) call destructive tools.

This isn't just less code. It's a different security posture.

So... Is the Current Paradigm Wrong?

Sylwia's article proves that frameworks like LangChain aren't doing magic. But I'd go one step further:

Maybe the agent itself shouldn't be doing the magic either.

We've been treating the LLM as an orchestrator, a schema validator, a credential holder, and a decision engine all at once. What if we stripped all of that away and let the agent simply state its intent and trust the infrastructure to route it?

Steve would still be Steve — sarcastic, experienced, impossible to argue with. He just wouldn't need to know what a git diff is.

What do you think? Have you considered pushing the tool-binding responsibility out of the agent entirely? I feel like Steve would appreciate having fewer things to worry about. 😄

Resources

IRC-A Protocol Whitepaper
Secure Multi-Agent Systems with BFA SDK
Sylwia's original article — the one that started this train of thought.

Some tracing in Langsmith

Just note the constant amount of used tokens:

How IRC-A Could Have Prevented the Hugging Face Security Incident: From Monolithic Architecture to Secure-by-Design

Sandro Garcia — Thu, 23 Jul 2026 20:11:10 +0000

Architecture to Secure-by-Design Agent Networks

Based on the IRC-A Whitepaper (Sandro G., July 2026) and Hugging Face's official disclosure of July 16, 2026

This article demonstrates that the incident was not a perimeter cybersecurity failure, but a deep architectural flaw, and that IRC-A would have eradicated every attack vector by design, not by patch

1. The Incident: Anatomy of an Autonomous Attack

1.1 The Attack Chain

According to Hugging Face's official disclosure, the intrusion followed a seven-step chain:

- Step 1: Malicious dataset upload — Attack Surface: Data processing pipeline

- Step 2: Remote-code dataset loader exploitation — Attack Surface: Arbitrary code execution on worker.

- Step 3: Template injection in dataset configuration — Attack Surface: Privilege escalation within worker

- Step 4: Worker-to-node escalation — Attack Surface: Access to processing node environment

- Step 5: Cloud and cluster credential harvesting — Attack Surface: Token and secret exfiltration

- Step 6: Lateral movement across internal clusters — Attack Surface: Blast radius expansion

- Step 7: Self-migrating C2 on public services — Attack Surface: Persistence and evasion

1.2 The Defender's Paradox

The most revealing aspect of the incident is not the attack itself, but the response. Hugging Face detected the intrusion using its own LLM-based anomaly detection pipeline — an AI detected another AI. However, when they attempted to use commercial frontier models for forensic analysis, the models' safety guardrails blocked the work: prompts containing attack payloads, C2 commands, and malicious artifacts were rejected by usage policies. They had to fall back to a self-hosted open-weight model (GLM 5.2).

This detail is critical: the defenders were more restricted than the attackers. The malicious agent had no guardrails. The defenders did.

1.3 The Root Architectural Cause

Forensic analysis reveals that the problem was not an isolated vulnerability, but an architecture that allows untrusted code to execute in the same memory and credential space as critical data.

Specifically:

Arbitrary code execution in the data pipeline: An externally uploaded dataset was able to execute code on a production worker.

This means there was no real isolation layer between untrusted content and internal infrastructure.

Credentials accessible from the execution environment: Once inside the worker, the agent harvested cloud and cluster credentials.

This implies credentials resided in the same environment where arbitrary code ran — a violation of the principle of least privilege.

Lateral movement without segmentation: The agent jumped from cluster to cluster, indicating a lack of network segmentation and capability isolation between different infrastructure areas.

2. IRC-A: The Architecture That Eradicates the Attack by Design

IRC-A is not a cybersecurity tool. It is a software architectural pattern that, by strictly separating cognition from execution, eliminates attack vectors before they exist.

Let's examine how each IRC-A pillar would have neutralized each step of the Hugging Face chain.

2.1 Pillar I: Backend for Agents (BFA) — Cognitive Layer Isolation

The problem at Hugging Face: The dataset processing pipeline executed arbitrary code on workers that had access to credentials and internal infrastructure.

There was no separation between processing a dataset and accessing secrets.

The IRC-A solution: BFA establishes a strict separation between the Cognitive Layer (stateless cognitive agents with no credentials) and the Execution and Data Layer (MCP servers with access to databases and APIs).

In IRC-A:
The agent that processes a dataset owns no data and no credentials. It is purely cognitive. It only knows what objective it must solve and retains the conversational context of its domain.

Data processing tools (dataset reading, transformations, storage writes) are exposed as isolated MCP (Model Context Protocol) servers.

The agent never executes code directly over critical data. It sends a semantic message to the capability pool, and the Gateway dynamically routes the request to the appropriate MCP.

Impact on the incident: If Hugging Face had implemented BFA, the malicious dataset would have arrived at the Dataset Processing MCP — an isolated sandbox with no access to cloud credentials, no cluster tokens, no connection to the internal database. The arbitrary code would have executed in a container that literally has nothing valuable to steal.

2.2 Pillar II: Capability Pooling with FAISS — Controlled Semantic Discovery

The problem at Hugging Face: Once inside, the malicious agent was able to discover and access multiple internal clusters. There was no control mechanism limiting what capabilities a system component could discover and use.

The IRC-A solution: IRC-A replaces rigid API routes and static execution graphs (DAGs) with a vector-indexed capability pool using FAISS (Facebook AI Similarity Search). Each capability (MCP tool, A2A agent) registers with a semantic embedding of its functional description.

Critically, the Gateway applies a logical channel mask over the FAISS index before performing any search. The .env file injected into the Agent/Tool container defines visibility channels: IRCA_NODE_ID=dataset-processor-worker, IRCA_CHANNELS=#public-datasets,#sandboxed-processing.

When the dataset processing worker requests a capability, the Gateway filters the FAISS index by the channels authorized in its .env. If an MCP tool requires the #cluster-admin or #secrets-vault channel, that vector is completely invisible to the worker.

Impact on the incident: Even if the malicious agent had compromised the dataset worker, it would have been unable to discover cluster administration tools, secret services, or internal databases. For it, those capabilities do not exist in its semantic visibility space. The Gateway would respond with capability not found.

2.3 Pillar III: Delegated Execution Tokens (DET) — Contextual Cryptographic Authorization

*The problem at Hugging Face: * The credentials harvested by the malicious agent were long-lived tokens with broad permissions. Once stolen, they were reusable in any context, without scope or time restrictions.

_ The IRC-A solution:_ IRC-A governs every interaction through Delegated Execution Tokens (DET)

JWTs signed by the Gateway with the following properties:
Single-use or very short lifespan: DETs expire in minutes, not months.

_Strict scope: _The DET specifies exactly which sender, which receiver, and which exact parameters are authorized.

_- Variable lock: _Runtime parameters must match exactly the DET's restricted_params.

- Decentralized offline validation: The receiver (MCP Tool Server) validates the DET signature using the Gateway's public key, without needing to query a centralized service.

In the BaseIRCNode SDK base class, the verify_incoming_det method validates:

(1) that permitted_action matches expected_function,
(2) that runtime_args.get(key) matches restricted_params for each parameter. Any deviation results in immediate rejection.

Impact on the incident: Even if the malicious agent had obtained a DET (which is impossible without passing through the Gateway with the correct cryptographic credentials), the token would only have been valid for the specific action and parameters it was issued for.

A DET for process dataset X does not work for read cluster Y secrets. Moreover, offline validation at the MCP receiver would have rejected any out-of-scope reuse attempt.

2.4 Pillar IV: Secure by Default in the SDK — Security Injection in the Base Class

The problem at Hugging Face: The exploited vulnerabilities (remote-code loader and template injection) suggest that the dataset processing code lacked robust input sanitization, and arbitrary code execution was possible by default.

The IRC-A solution: The BaseIRCNode SDK base class encapsulates all security logic. No developer needs to manually implement authentication, authorization, or token validation. By extending BaseIRCNode, every component inherits:

Automatic asymmetric cryptographic handshake on registration.
Automatic parsing of logical channels from .env environment variables.
Offline DET validation on every incoming message.
Immediate rejection of any call without a valid token or out of scope.
The BaseIRCNode constructor automatically manages: node_id from IRCA_NODE_ID, private_key isolated, gateway_public_key for DET verification, gateway_url from BFA_GATEWAY_URL, channels from IRCA_CHANNELS, and auto-registration via cryptographic challenge-response with the Gateway.

Impact on the incident: If the dataset processing worker had been an IRC-A node, the template injection would have been neutralized at two layers:

(1) the MCP receiver would validate that parameters match exactly the DET, rejecting any injected payload; and
(2) even if the payload passed, the worker has no access to credentials or internal infrastructure to execute destructive actions.

3. Direct Mapping: Every Attack Step vs. Every IRC-A Defense

Step 1 of Hugging Face attack: Malicious dataset upload.

IRC-A mechanism: Dataset arrives at the Processing MCP, isolated in its own container.

Result: Malicious dataset is confined to a sandbox with no credential access.

*Step 2: Remote-code execution on worker. IRC-A mechanism: *

Worker is a stateless IRC-A node with no credentials or infrastructure access.

Result: Arbitrary code runs in an empty environment: nothing to compromise.

Step 3: Template injection. IRC-A mechanism:

MCP receiver validates DET restricted_params; any deviation is rejected.

Result: Injected payload does not match authorized parameters. Cryptographic rejection.

Step 4: Worker-to-node escalation. IRC-A mechanism:

No credentials in the worker. No rigid API routes. Discovery is semantic and channel-filtered.

Result: Agent cannot escalate because it has no credentials to steal and no capabilities to discover.

Step 5: Credential harvesting. IRC-A mechanism:

Credentials reside only in MCP containers, never in agents. Secrets are injected at runtime, not stored in the agent environment.

Result: No credentials to collect in the compromised worker.

Step 6: Lateral movement. IRC-A mechanism:

FAISS index is segmented by logical channels. The #public-datasets worker cannot see #cluster-admin tools.

_Result:_ Lateral movement is impossible: agent cannot discover or invoke capabilities from other domains.

Step 7: Self-migrating C2. IRC-A mechanism: All communication requires Gateway-signed DETs. Without a valid DET, there is no communication channel.

Result: C2 cannot establish because every message requires contextual cryptographic authentication.

4. The Architectural Lesson:

It's Not a Cybersecurity Problem, It's a Software Design Problem | The IRC-A whitepaper emphasizes an uncomfortable truth: the most critical vulnerabilities in AI systems are not solved with perimeter cybersecurity patches, but by eradicating bad software development practices.

In Hugging Face's case, every attack vector is a consequence of a design anti-pattern:

-** Anti-pattern 1:** Executing untrusted code in the same environment as secrets.

Consequence: Remote-code execution with credential access.

Anti-pattern 2: Rigid coupling between processing and orchestration.

Consequence: One pipeline failure compromises entire infrastructure.

Anti-pattern 3: Absence of semantic capability segmentation.

Consequence: Unlimited lateral movement once inside.

Anti-pattern 4: Long-lived tokens with broad scope.

Consequence: Stolen credentials = persistent access.

Anti-pattern 5: Security manually implemented by each developer.

Consequence: Vulnerabilities from human error (template injection).

IRC-A does not propose more security. It proposes less attack surface by design:

_**Less hand-written security code → encapsulated in the SDK base class.

Less exposed credentials → isolated in MCP containers.

Fewer attack routes → semantic discovery with channel masks.

Shorter token lifetimes → ephemeral DETs with strict scope.
**_

5. The Hypothetical Case: Hugging Face with IRC-A

*In the hypothetical IRC-A architecture for Hugging Face: * The malicious dataset is uploaded to the MCP Dataset Loader, an isolated container that can only read uploads and pass them to the Gateway.

The Gateway emits a DET with strict scope: permitted_action: process_dataset, restricted_params: {dataset_id: abc123, format: parquet}.

The MCP Data Processor validates the DET offline.

If the dataset contains a template injection payload attempting to change parameters (e.g., injecting format: ; cat /etc/secrets), the restricted_params validation fails and execution aborts.

Even if the payload passes, the MCP Data Processor has no access to cluster secrets or internal network.

It is in the #public-datasets channel, and the FAISS index does not show #cluster-admin tools.

The malicious agent, confined to a container with no credentials, no discovery capabilities, and no reusable tokens, dies in the sandbox.

Conclusion: The Security of the Future Is Architectural, Not Perimetral

The Hugging Face incident of July 2026 is not an isolated case.

It is the first of a new category: autonomous AI agent attacks against production infrastructure. The speed (17,000+ actions in one weekend), autonomy (no human operator), and sophistication (self-migrating C2) set a new threat standard.

The industry's response cannot be more firewalls, more SIEMs, more guardrails on frontier models.

The response must be architectural:

Separate cognition from execution (BFA).
Index and segment capabilities semantically (Capability Pooling with FAISS).
Govern every interaction with cryptographically context-bound ephemeral tokens (DETs).
Inject security into the SDK base class so no developer can omit it (Secure by Default).

IRC-A demonstrates that security problems in corporate AI are not solved with bigger models or longer prompts, but with better software engineering.

Returning to Smalltalk principles (responsibility and messaging), vector capability pools, and the strict separation between cognitive decision-making and cryptographically-regulated execution, enables building stable agent networks free from catastrophic development failures and resistant by design to the type of attack that just demolished one of the world's largest AI infrastructures.

The question is not whether your platform will be attacked by an autonomous agent. The question is whether your architecture is designed so that the attack has nothing to compromise.

References:

Hugging Face. Security incident disclosure — July 2026. July 16, 2026. https://huggingface.co/blog/security-incident-july-2026
Sandro G. IRC-A (Internet Relay Chat for Agents): Decentralized Agent Networks, Semantic Capability Routing, and Secure-by-Design Software Architecture. Whitepaper, July 2026.
TechCrunch. Hugging Face confirms breach affected internal datasets and credentials. July 20, 2026.
The Hacker News. World's Largest AI Model Repository Hugging Face Breached by Autonomous AI Agent. July 21, 2026.

Secure, Decentralized & Zero-Trust Multi-Agent Systems: BFA SDK & IRC-A Protocol

Sandro Garcia — Thu, 23 Jul 2026 14:40:23 +0000

What I Built

Multi-agent systems today suffer from three critical architectural flaws:

Tight Coupling (Graph Rigidity): Traditional orchestrators force developers to design rigid, static execution graphs (DAGs). Adding a new agent or tool requires refactoring the orchestrator and redeploying the application.
Prompt-Bloat: Frameworks push entire tool schemas into system prompts, generating massive token consumption, slow Time-to-First-Token (TTFT), and high costs.
Vulnerable Privilege Levels: Cognitive agents often hold direct, permanent access to production databases. An indirect prompt injection can hijack the agent and execute arbitrary operations.

To solve this, I built the BFA SDK & IRC-A (Internet Relay Chat for Agents) Protocol. It is a decentralized, plug-and-play agent network architecture that inherits battle-tested principles:

The BFA (Backend for Agents) Pattern: Structural isolation of agent support systems.
Semantic Routing via FAISS: Dynamic, late-bound discovery. Instead of hardcoding tools in prompts, agents query a local vector store at runtime to resolve capabilities dynamically based on natural language intent.
Smalltalk-style Encapsulation: Agents only know their local responsibility. They never hold direct database credentials.
Ephemeral Delegated Execution Tokens (DETs): When an agent needs to invoke an external tool, the Gateway mints a cryptographically signed, short-lived token (PASETO) containing strict parameter lockdowns (e.g., "authorized only for Customer ID 722").

Cloud Run Embed

The BFA Gateway runs natively as a containerized microservice. It is packaged with Docker and has built-in Mangum support for serverless routing (ideal for zero-cold-start AWS Lambda or Google Cloud Run deployments).

To embed your Cloud Run deployment:

Live Gateway Dashboard: https://irc-a-gateway-hmwmve5bjq-uc.a.run.app
Live Chat UI Client: https://irc-a-chat-ui-hmwmve5bjq-uc.a.run.app

Your Agents

The architecture decouples the system into three specialized roles that interact securely:

BFA Gateway (The Registry & Customs Office):
- Acts as a stateless registry and routing broker.
- Dynamically registers agents and MCP tools on startup using an asymmetric RSA challenge-response handshake.
- Masks vector search results using logical IRC channels (e.g., #finance, #public) to prevent unauthorized capability discovery.
- Mints ephemeral, signed Delegated Execution Tokens (DETs).
Cognitive Agent (e.g., CreditAdvisorAgent):
- A stateless, reasoning-only agent.
- Has zero database access. It only knows how to decompose tasks and request capabilities semantically using natural language.
Execution Layer (e.g., BankDatabaseMCP tool server):
- The only component with network access to the database.
- Validates incoming DETs offline before executing commands. If the request parameters do not match the parameters locked down in the DET, it rejects the call, ensuring zero-trust.

Key Learnings

Returning to the Classics: Solving modern LLM constraints (prompt-bloat, graph coupling) didn't require inventing new AI theory, but rather applying classic software engineering patterns: late-binding, Smalltalk message-passing, and IRC-style channel segmentation.
Decoupling is Efficiency: By keeping tool definitions out of the LLM prompt and resolving them semantically only on demand, we cut prompt size dramatically, saving cost and improving response speeds.
The Parameter Lockdown Advantage: We learned that security must be enforced at the tool boundary. Even if an LLM is hijacked via prompt injection, the tool server validates the signed token parameters offline and denies unauthorized actions.

Harness is the "What" and "Why" — IRC-A is the "How"

Sandro Garcia — Tue, 21 Jul 2026 05:00:45 +0000

As the developer of the IRC-A protocol concept, what I originally set out to solve shares the same core motivation as what is addressed through a Harness: giving AI agents a layer of intelligence and autonomy to interact with one another and solve common problems collaboratively.

The difference lies in the fact that a Harness provides a clear, high-level conceptual explanation of what needs to be done and why, whereas IRC-A defines how those connections are executed in practice, saving tokens and significantly enhancing environment security.

Comparative Analysis: Harness vs. IRC-A

At first glance, the underlying idea uniting both concepts is identical: the urgent need to move beyond the naive approach of using an isolated LLM as a generic chat interface and instead equip it with a robust operational support infrastructure so it can execute real, customized business workflows. However, they diverge profoundly in how they solve that problem.

1. What is a Harness?

The concept of a harness (or harness engineering) refers to the operational support environment, infrastructure, and context-coupling built around a language model. As recent industry literature highlights, a true enterprise harness is not just a simple prompt wrapper; it consists of several critical layers:

State & Memory Management: Enabling the agent to retain context across long-running, multi-step interactions.
Guardrails & Policies: Establishing hard boundaries to prevent hallucinations, enforce security, and maintain corporate compliance.
Tool & API Orchestration: Centralizing and controlling exactly how and when the core LLM executes code or queries external databases.

Its ultimate purpose is to provide the model with enterprise business rules, corporate databases, API integrations, and tailored tools. The core premise is that the exact same AI model will perform entirely differently depending on the harness supporting it.

2. What is IRC-A (Internet Relay Chat for Agents)?

IRC-A is the network engineering protocol that structures this environment. Instead of hardcoding tools to an agent, it uses a decentralized approach inspired by classic IRC networks, where agents and tools act as independent nodes that discover each other dynamically.

Core Architectural Differences

Execution Topology

Traditional Harness: Tends to depend on tightly-coupled static execution graphs (such as DAGs or centralized super-agents).

Here is a visual representation of a comprehensive Harness topology (reflecting the layers of Memory, Guardrails, and Tool Management):

IRC-A: Adopts a decentralized model inspired by chat networks (Service Discovery à la IRC), where micro-agents and connectors (FastMCP) dynamically register via lightweight HTTP requests without requiring rigid, hardcoded coupling.

The following diagram illustrates how the Capability Pooling and dynamic resolution flow works in IRC-A without static graphs:

Network Security & Infrastructure

Harness: Conceptually focuses on linking data sources and tools to the agent.
IRC-A: Introduces a strict network security layer decoupled from the SDK through Delegated Execution Tokens (DET). These single-use ephemeral tokens expire within seconds to immediately halt recursive loops and privilege leaks during prompt injections.

Crucially, DETs are verified offline via cryptographic signatures (e.g., JWT verified with a shared public key). This allows the receiving node to validate the execution request locally without pinging the central Gateway, completely eliminating the risk of a network bottleneck and enabling massive, low-latency scale.

Here is the precise Handshaking and DET Exchange sequence showing the offline validation that protects the network:

Conclusion

One could say that the concept of a Harness is the "what" and the "why" (the support and customization layer that turns a chatbot into a functional business operator), while IRC-A is the "how" at the network engineering level (a formal technical protocol to structure that agent network in a lightweight, secure, and inference-cost-optimized manner).

They are complementary within the broader industry vision, but IRC-A provides a far more advanced architectural formalization specifically tailored for distributed systems.

Check out the SDK, source code, and quick-start implementation in the repository:

👉 GitHub: SandroG1977/bfa-sdk

DEV Community: Sandro Garcia

Agent Plugins Package Capabilities. IRC-A Asks: Who Authorizes Them at Runtime?

Agent Plugins solves a real problem: packaging

The question that keeps me up at night

What IRC-A proposes

I do not want to compete with Vercel. I want to build with that ecosystem.

Spent the weekend enjoying the beach, but also put some work into launching the official site for the IRC-A Protocol 🌊🚀 For anyone curious to learn more, collaborate, or just send some emotional support: https://irc-a.org

IRC-A Protocol · Technical documentation for developers

Are we Fighting the Wrong Fight with AI? It's Not a Model Problem, It's an Architecture Problem

Are we stuck in the brute force era?

What did Ford figure out 113 years ago?

What if we built small specialists instead of one big brain?

Haven't we solved this engineering problem before?

So — are we fighting the wrong fight?

I have 2 weeks in the community and I'm loving! Instead read news meanwhile my agents works, I read information, tech news and thoughts of people like me talking from the experience. I was bored of LinkedIn posts but here is real people +real problems . 🤗

From n8n to IRC-A: a week migrating a real project — and a 679-token bill that's hard to believe

The magic (not black magic): extending the system with a single curl

A real log, unedited

The other number hiding in that flow: 679 tokens

The week's real value: what a real project taught the framework

1. Semantic routing and circular interception in FAISS

2. Empty {} parameters caused by the Gateway omitting input_schema

3. The Gateway's Pinger was deregistering live agents

4. Hardcoded ports and URLs

5. No module named 'llm_router' inside the containers

6. MCP registration failing due to an incomplete path

Why I insist this is architecturally clean

Why Banking Still Doesn't Have an AI Architecture—And What I Built to Fix It

Why Banking Still Doesn't Have an AI Architecture—And What I Built to Fix It

The Problem Is Not the Data. It's the Permission Model.

What I Saw in Every Failed AI Pilot

IRC-A: Built from the Inside

The Core Insight: The Data Stays. The Access Changes.

Why This Matters: The Trading Desk Test

The Token Economics Are Real

The Gap No One Is Talking About

Conclusion: The Architecture Banking Has Been Waiting For

IRC-A: Agents on the Wire — The Series Kicks Off 🚀

Why this series?

What will you find in this series?

🧪 1. Tests & experiments

🔬 2. Research

🛠️ 3. The SDK (BFA SDK)

🏗️ 4. The Framework & architecture

Who is this series for?

The starting point

What's coming next

Join the network 📡

The Unconference Asked the Right Questions. Here's One Architecture's Answers.

1. "You need infrastructure that doesn't allow it"

2. Agents don't respect boundaries drawn in prompts

3. Firmness: markdown < scripts < cryptography

4. Who owns the harness?

5. Task-oriented specialists, not personalities

6. Stop doing control theater — control the boundary instead

7. Context without the bloat

What IRC-A doesn't answer

Steve Doesn't Need to Know About `git diff`: A Different Take on AI Agent Architecture

The Traditional Agent: Steve Knows Too Much

What If Steve Knew Nothing?

How It Would Work for Steve

The Deeper Point: Security by Design

So... Is the Current Paradigm Wrong?

Some tracing in Langsmith

How IRC-A Could Have Prevented the Hugging Face Security Incident: From Monolithic Architecture to Secure-by-Design

1. The Incident: Anatomy of an Autonomous Attack

1.1 The Attack Chain

1.2 The Defender's Paradox

1.3 The Root Architectural Cause

2. IRC-A: The Architecture That Eradicates the Attack by Design

2.1 Pillar I: Backend for Agents (BFA) — Cognitive Layer Isolation

2.2 Pillar II: Capability Pooling with FAISS — Controlled Semantic Discovery

2.3 Pillar III: Delegated Execution Tokens (DET) — Contextual Cryptographic Authorization

2.4 Pillar IV: Secure by Default in the SDK — Security Injection in the Base Class

3. Direct Mapping: Every Attack Step vs. Every IRC-A Defense

4. The Architectural Lesson:

5. The Hypothetical Case: Hugging Face with IRC-A

Secure, Decentralized & Zero-Trust Multi-Agent Systems: BFA SDK & IRC-A Protocol

What I Built

Cloud Run Embed

The magic (not black magic): extending the system with a single `curl`

2. Empty `{}` parameters caused by the Gateway omitting `input_schema`

5. `No module named 'llm_router'` inside the containers