A ticket-triage agent written in three lines of Pydantic AI can go from local script to governed, organization-wide resource in about five minutes inside the LiteLLM Agent Gateway. The gateway discovers the agent over the A2A protocol, pulls its description and version from the agent card, and routes calls through a virtual key you control.
What Is the LiteLLM Agent Gateway?
The LiteLLM Agent Gateway is a feature of the LiteLLM AI gateway that registers and manages agents from any platform speaking the A2A protocol. A video from the LiteLLM AI Gateway channel published on 2026-09-18 demonstrates the workflow end to end in five minutes. The channel shows a Pydantic AI agent and a config-declared Trip Planner agent both reachable through the same gateway URL.
The core idea is consolidation. Instead of managing credentials, budgets, and logs separately for agents built with Pydantic AI or deployed on LangGraph, Azure AI Foundry, Bedrock AgentCore, or Vertex AI, you bring them into one gateway and treat them as first-class resources with skills, costs, and access controls.
The LiteLLM project on GitHub is the canonical home for the gateway code, and the Agent Gateway documentation is the primary reference for current configuration syntax.
How Do You Add an Agent Using the A2A Protocol?
You add an agent by pointing the gateway at its URL and letting the A2A discovery mechanism pull the agent card. A2A (Agent-to-Agent) is a protocol standard that lets agents expose their capabilities in a machine-readable card. The video shows the presenter typing in a URL and watching the description, version, and protocol version fields autofill.
The registration form accepts a name and display name, both optional if the agent card provides them. If discovery does not populate automatically, the presenter demonstrates hitting the Discover button, which pulls the agent card information into the form directly from the running agent.
The gateway supports agents from any A2A-compliant source, so the same flow works whether the underlying agent is a local Pydantic AI script or a managed cloud deployment.
What Is the A2A Protocol Version and Why Does It Matter?
The protocol version field tells the gateway which A2A protocol revision to use when formatting responses from the upstream agent. LiteLLM converts the upstream response to this version before returning it to the caller. The video demonstrates selecting version 0.3 for the Pydantic AI agent.
This matters because agents built at different times target different protocol revisions. Setting the version explicitly ensures the gateway normalizes output regardless of how the upstream agent was built, so your downstream tooling sees a consistent format.
The presenter notes that both the LiteLLM and A2A protocol documentation cover this in more detail, which is worth consulting if your agent targets an older or newer revision than 0.3.
How Do Skills, Costs, and Public Visibility Work?
Skills describe what the agent can do and become part of its capability metadata inside the gateway. The registration form lets you assign skills to the agent so other systems or humans browsing the gateway can find it by function.
Cost assignment supports two modes: a flat cost per query, or input and output cost per token. This mirrors how LiteLLM already handles model costs and means an organization can track agent spending with the same precision it applies to LLM calls.
A public agent flag makes the agent available organization-wide once registered. Without this flag, the agent remains visible only to whoever registered it or to teams explicitly granted access.
How Do Allowed Models, Sub-Agents, and MCP Servers Restrict an Agent?
The gateway lets you scope which resources an agent can reach at registration time. Allowed models restrict the agent to specific entries from your config file. The video shows two pre-configured models offered as candidates.
Sub-agents work the same way: selecting specific sub-agents restricts this agent to only those downstream agents. If you skip the step, the agent has no sub-agent restriction.
MCP (Model Context Protocol) servers get the same treatment. If you have MCP servers configured, you pick which ones this agent can call. The presenter keeps all defaults and moves on, which is a valid choice when you want permissive access initially and tighten later.
What Governance Controls Does the Gateway Apply to Agents?
Session budgets cap how much an agent can spend across a conversation. Agent rate limits cap how fast it can make calls. Session rate limits add a second throttle keyed to the session rather than the agent.
Guardrails apply content or safety policies to the agent's calls, the same guardrail system LiteLLM uses for model traffic. The presenter leaves all governance at defaults in the demo but confirms each field is available at registration time.
You can also assign the agent to a team and create a new virtual key scoped to that team during the same flow, though the video skips this and creates the agent without a key first.
Why Does a New Agent Show Needs Setup and How Do You Activate It?
A newly created agent shows the status Needs Setup because no virtual key has been assigned to it. The gateway treats the virtual key as the activation mechanism; without one, the agent is registered but not callable.
To activate it, go to the Virtual Key section and create a new key. The key creation form includes an agent option where you select the agent you just registered, along with organization, team, and other settings. The video shows the presenter adding key details, creating the key, and returning to the agent section to find the status now Active.
This applies to config-declared agents too. The Trip Planner agent added via config.yaml also shows Needs Setup until a key is assigned.
How Do You Declare Agents in config.yaml?
Agents can be declared in the same config.yaml that defines your model list, which is useful when you want agents to deploy with the gateway itself rather than being registered through the UI.
The agent section takes a name, which the video calls Trip Planner, plus agent card info: name, URL, and protocol version. Additional configuration fields follow the same structure as the UI form. The presenter notes the LiteLLM documentation covers the full schema.
Once the gateway restarts with this config, the agent appears in the UI automatically. It still shows Needs Setup and still needs a virtual key assignment before it becomes active, matching the behavior of UI-registered agents.
How Do You Test Agents and Read the Logs?
Terminal commands give you a quick sanity check. The video demonstrates a short, repeatable verification sequence:
- List the agents registered on the gateway to confirm the set you expect.
- Request an agent card and inspect its detail. The card URL shown is the gateway URL, not the original Pydantic AI agent URL, confirming the gateway is proxying correctly.
- Send a message to the agent through the gateway. The presenter gets a reply back from the ticket triage agent, which is the real end-to-end test.
| Step | Command target | What it confirms |
|---|---|---|
| 1 | List agents | Agents are registered on the gateway |
| 2 | Agent card | Gateway URL replaces the original agent URL |
| 3 | Send message | End-to-end reply from the ticket triage agent |
The logs section in the UI shows agent calls alongside model calls, with usage broken out per agent. This is where cost tracking and governance enforcement become visible in practice, since each logged call carries the agent identity, the tokens consumed, and the virtual key used.
Gustavo dev doido notes that the value of this pattern compounds when you have more than two agents, because the marginal cost of registering another one is a URL and a key assignment rather than a new observability and billing pipeline.
Frequently Asked Questions
- Which platforms can I import agents from? Any agent speaking the A2A protocol works through the standard flow. The video specifically names LangGraph, Azure AI Foundry, Bedrock AgentCore, and Vertex AI as supported platform options in the registration UI, alongside local agents built with Pydantic AI.
- What happens if I do not assign a virtual key? The agent stays in Needs Setup status and cannot be called through the gateway. Assigning a key through the Virtual Key section, selecting the agent and any organization or team scope, flips it to Active.
- Can I control how much an agent spends? Yes. The gateway supports session budgets, agent rate limits, and session rate limits, each configurable at registration. Cost can be assigned per query or per token for input and output.
- Does the agent URL in the logs match my original agent? No. Once registered, calls go through the gateway URL, and agent cards returned to clients point at the gateway rather than the upstream agent. The upstream agent remains your infrastructure; the gateway fronts it.
Turn Your Own Agent Walkthroughs Into Written Guides
Registering an agent takes minutes; explaining the A2A protocol version, virtual key activation, and governance options in writing takes longer. If you have recorded a demo like this one, the knowledge is already on screen and in your narration, waiting to be put into a form people can search and link to.
Skala Blog turns a YouTube video into a structured article: paste the URL, and it transcribes the content and drafts a piece you can edit and publish. A five-minute walkthrough becomes a reference your team and your users can find without scrubbing a timeline.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits