Skip to content

Instantly share code, notes, and snippets.

@ccamacho

ccamacho/blog_demo.md

Created March 11, 2026 15:13
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save ccamacho/24e6fac6ca44c127a3858aa2c668aeca to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save ccamacho/24e6fac6ca44c127a3858aa2c668aeca to your computer and use it in GitHub Desktop.
Download ZIP
blog_demo.md
Raw
blog_demo.md

Partner Support Agents with A2A Cross-Communication: A New AI Quickstart for Multi-Agent Collaboration

When a customer opens a support case that spans two organizations — say, a telco running Red Hat OpenShift with a partner-managed application layer — resolution today means emails, escalations, and context lost at every handoff. What if AI agents from both organizations could collaborate directly, in real time, using an open standard?

That's exactly what the Partner Support Agents quickstart demonstrates: an enterprise-grade, Agent-to-Agent (A2A) multi-agent system where a Red Hat Support Agent and a Partner Agent work together — orchestrated automatically — to resolve customer issues on OpenShift.

What It Does

This quickstart deploys a complete AI-powered support routing system built on four pillars:

  • AAA (Authentication, Authorization, Accounting) — Users authenticate via JWT, agent access is controlled per-user, and every request is fully audited.
  • RAG (Retrieval-Augmented Generation) — Specialist agents query a knowledge base of historical support tickets so responses are grounded in real data, not hallucinated.
  • A2A (Agent-to-Agent) Communication — All inter-agent communication happens over direct HTTP calls using a clean, synchronous protocol. No message brokers, no event buses — just agents talking to agents.
  • PatternFly Chat UI — A production-ready web interface with login, role-based agent filtering, and a full audit log.

A user describes their issue in the chat UI. The system's Orchestrator (routing agent) classifies the intent and delegates to the right specialist — a Software Support Agent or a Network Support Agent — based on the user's permissions. The specialist queries the RAG knowledge base and returns a grounded, actionable response. Every step is logged with full accounting.

How It Works

The architecture consists of six services, all containerized and ready to run with a single make setup:

Service Role
Request Manager AAA enforcement, A2A orchestration, chat API
Agent Service LLM-based routing agent and specialist agents
RAG API Semantic search over embedded support tickets (ChromaDB + Gemini embeddings)
PostgreSQL + pgvector User data, sessions, full accounting logs
ChromaDB Vector database for RAG
Web UI (nginx) PatternFly 6 chat interface with reverse proxy

The A2A Protocol in Action

The Request Manager acts as the orchestrator. When a message arrives:

  1. It invokes the routing agent via POST /api/v1/agents/routing-agent/invoke, passing the user's permissions and conversation history in a transfer_context.
  2. The routing agent classifies the intent and returns a routing decision (e.g., ROUTE:software-support).
  3. The Request Manager checks authorization, then makes a second A2A call to the specialist agent.
  4. The specialist queries the RAG API, builds a prompt with the retrieved context, and returns a grounded response.
  5. Full accounting is written at every hop — agent identity, response content, and processing time.

This two-hop pattern is intentionally simple. There's no service mesh, no async message queue — just HTTP requests with structured context passed between agents. That simplicity is the point: teams new to A2A can read the code and understand exactly how agents discover each other, exchange tasks, and return results.

Three-Layer Authorization

Authorization isn't just a prompt instruction — it's enforced at three independent layers:

  1. LLM prompt — The routing agent's system prompt only lists the user's permitted agents.
  2. Hard gate — The Request Manager checks allowed_agents before every specialist call, regardless of what the LLM says.
  3. UI filtering — The frontend only shows agents the user is allowed to access.

Even if the LLM hallucinates a routing decision to an unauthorized agent, the hard gate blocks it. This defense-in-depth approach reflects how enterprise AI systems should handle authorization.

Get Started

Prerequisites

  • Docker
  • A Google API Key (for Gemini LLM and embeddings)

Run It

git clone https://github.com/ccamacho/agentic-partners-integration.git
cd agentic-partners-integration
export GOOGLE_API_KEY=your-key-here
make setup

That's it. The setup builds all containers, starts services, runs database migrations, creates test users, ingests the RAG knowledge base, and launches the web UI. When it finishes:

Sign in as sharon@example.com / sharon123 (admin access to all agents) and try: "My app crashes with error 500" — watch it route to the software support agent with RAG-grounded context.

The quickstart also supports pluggable LLM backends — switch between Gemini, OpenAI, and Ollama (local) by changing a single environment variable.

What's Next

This quickstart is the first in a planned series. Future additions include:

  • Observability — Agent traces and metrics with Langfuse (see issue #40)
  • Multimodal interactions — Voice-based support scenarios
  • Cross-industry adaptation — The telco support scenario is intentionally representative; the same architecture applies to finance, manufacturing, and managed services

Try It Today

The Partner Support Agents quickstart shows that multi-agent collaboration doesn't have to be complex. With A2A over HTTP, RAG-grounded responses, and enterprise-grade AAA, you can build agent systems that work across organizational boundaries — and understand exactly how they work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment