IRC-A in production: I plugged an agent I didn't build — and in 5 minutes it was booking real reservations

Every agent in my network was written by me. Yesterday I registered two pieces built by a third party that had never heard of my protocol — one curl, zero lines of code on my side — and minutes later my guest-service agent had discovered them on its own, negotiated room availability, and delegated a reservation that ended as RES-2026-00061, status "Confirmed", attributed to "AI Agent" in the hotel's PMS.

If you're new here: this series documents IRC-A (Internet Relay Chat for Agents), my protocol for decentralized multi-agent networks, built and battle-tested in the open. Earlier articles covered the migration from n8n and the 679-token bill, building your first network in minutes, semantic routing with FAISS, the secure registration handshake, and the night the protocol defended itself from AI-written code. This time, no lab test and no controlled experiment: a real use case, in a real app, with real guests — the milestone the whole architecture was designed for, reached in production.

Before the technical part, some thanks. Two week ago I presented IRC-A itself at Sertão Tech, at UFDPar — my first time taking this architecture to a live audience. A special thanks to @sylwia-lask, whose nudge was exactly what I needed to step out of my comfort zone and get on stage. And to the DEV.TO community: every comment on this series sharpened something in this design. This milestone is partly yours.

Thirty seconds of context (I promise)

IRC-A is an architecture for decentralized agent networks where a BFA gateway acts as a semantic customs office: it registers agents and tool servers (MCP), keeps a FAISS vector index of their capabilities, and governs who may ask whom for help via logical channels. But here's the core paradigm:

Discovery is infrastructure, not intelligence. An agent should never know the ecosystem it runs in — only its own responsibility.

When an agent needs something, it asks the gateway "who can solve this?". The gateway answers with the capability, its input_schema/output_schema, and the endpoint — then mints an ephemeral Delegated Execution Token (DET) with the parameters already locked. Everything after that — agent-to-agent and agent-to-tool — is direct P2P. The gateway never touches payloads.

The use case: a real app, not a lab

Until now, every node in the network was mine. But this isn't running in a sandbox — it's running in a real hospitality operation. And the next node the network needed was one I had never touched.

The candidates were already sitting there. The hotel PMS I work with in production — UnitHOS — ships with an A2A agent and its MCP server built in, factory-side. The vendor wrote them for their own product. They don't know what IRC-A is, they don't import my SDK, they speak standard A2A and MCP and that's it.

Integration cost, measured honestly:

• One curl registering the PMS agent + its MCP server in the gateway (the same registration from parts 1 and 2).
• Zero lines of code written by me.

Time from that curl to productive integration: minutes.

What happened next, nobody coded

My guest-service agent received a reservation request. Here's the chain, reconstructed from the logs — note that no orchestrator planned any of this:

1. DISCOVERY — The agent asked the gateway, in natural language, who could handle a reservation. Semantic search over the FAISS index matched the newly registered PMS capability (with its schemas and endpoint).
2. NEGOTIATION — The agent called the PMS agent directly (P2P), presented its DET, and asked for available room types.
3. PRESENTATION — The room type list was shown to the user.
4. SELECTION → AUTHORIZATION — The user picked a valid room. The agent requested a new DET from the gateway for the specific booking parameters — parameters that would be cryptographically locked into the token.
5. EXECUTION — The PMS agent invoked its own MCP tools against the transactional system and completed the reservation.

📷 [Log capture: the DISCOVERY → AUTHORIZATION sequence, with the DET minting]

The result in the PMS:

📷 [PMS row: RES-2026-00061 — status "Confirmed", attribution "Agente de IA"]

A real reservation, in the real transactional system. RES-2026-00061, "Confirmed", attributed to an AI agent.

These two screenshots tell the whole story: the gateway discovered and authorized a capability it had never seen before, and a system of record accepted a write originated by a negotiation between two agents — one of which was built by a third party.

The technical details that actually made the difference

Three design decisions were load-bearing in this use case. Without any of them, this post wouldn't exist:

Semantic discovery with bidirectional schemas. My agent didn't hardcode anything about the PMS — no URLs, no tool names, no parameter formats. The gateway returned the capability with its input and output schemas, and the agent reasoned about a domain (hospitality operations) it had never been configured for. This is what kills prompt-bloat: the schemas travel with the discovery response instead of living permanently in a system prompt.

Ephemeral DETs with parameter lockdown. The booking DET was minted for those specific parameters — room type, dates, guest data — and the receiving side verifies the gateway's signature offline. The PMS agent didn't take my agent's word for anything; it verified a PASETO token from the gateway and enforced that the runtime arguments matched the authorized ones. No token, no write. Wrong parameters, no write.

Honest failure contracts. This is the part I'm proudest of, because I tested it on purpose.

The deliberate failure test

A system that books a room when everything goes right proves very little. So I fed it room types that don't exist.

Every attempt was rejected with structured errors. Nothing invalid was persisted. No simulated fallbacks, no phantom reservations, no "best effort" writes. The transactional layer only executed when the data matched the actual domain reality.

Why does this matter more than the happy path? Because in agentic systems, the failure mode is the product. Anyone can demo a happy path; a hallucinated room type that silently becomes a corrupted booking is what separates a demo from infrastructure. The happy path and the failure path both behaved exactly as the design promises — and in this architecture, the failure contract isn't a try/catch in the agent. It's enforced at the execution door, by the token and by the MCP server's exclusive ownership of the transactional connection.

What this actually means

Strip away the hotel domain and the conclusion is the thesis of the whitepaper, now with evidence:

Expanding the ecosystem is registration, not integration.

Any agent or MCP server that speaks the market standards (A2A/MCP) becomes immediately employable by the existing agents — which discover its capabilities by themselves, negotiate its schemas, and delegate to it under cryptographically scoped authorization. My guest-service agent didn't get an update. It didn't know the PMS existed five minutes before it used it.

Enterprise silos stop being silos the moment they expose standard agents. A PMS doesn't need to integrate with my AI stack — it just needs to expose an A2A agent and an MCP server, and my network treats it as a first-class citizen.

The honesty section (what's still on the roadmap)

Because this audience deserves the full picture, here's the hygiene debt I noticed while running this in production — all roadmap items, none blockers:

• Channel normalization — the logical channel naming convention needs stricter normalization so third-party registrations don't drift from the channel masking rules.
• Log narration format — the P2P logs still mix Spanish and English; the structured log formatting needs to be consistent before this network grows past me.
• Funnel analytics — I want native telemetry for the /discover → /authorize → execution funnel, so I can measure semantic routing precision and DET rejection rates without external tooling.

The pattern from the whole series holds: every item traces back to something real I watched happen.