Blog

For two years the story of enterprise AI has been an agent calling a model, and — more recently — an agent calling a tool. There's a third call now, and most teams can't see it: an agent calling another agent. That hop has a name — agent-to-agent (A2A) — and it is the least-governed surface in the entire AI stack.

This post is a practical definition of A2A: what the protocol actually is, why the delegation hop between two agents is a blind spot your existing controls don't cover, and what it takes to govern it.

DVARA 1.3.0 is available today. This release adds a third governance plane: agent-to-agent. Alongside the LLM gateway and the MCP Proxy, DVARA now sits in front of A2A traffic and governs every hop one agent makes to another — authenticating the caller, checking policy, scanning for PII, and writing a tamper-evident audit record — behind its own dedicated proxy.

Everything below ships in every install. There is no feature paywall — the same governance core across all three planes. 1.3.0 is a drop-in upgrade from 1.2.x.

"Which LLM gateway should we use?" doesn't have a universal answer, because teams optimize for different things — fastest to adopt, cheapest to run, most observable, or most governable. What is universal is the set of questions worth asking, and the order to ask them in.

This is a framework, not a leaderboard. And it's deliberately governance-first, because that's the axis where products differ most and demo videos reveal least. Routing and provider coverage are easy to compare and roughly commoditized; whether a platform can enforce a policy, prove what it did, and keep sensitive data in your perimeter is where the real divergence — and the real buying decision — lives. DVARA is one option in the field; the point of this post is to help you score the field, including us, on criteria that matter.

Ask a team running AI in production a few basic questions — what's our p95 latency to Anthropic? how many tokens did the support team burn last week? what's our error rate on gpt-4o? — and watch how long the answer takes. If it's a research project rather than a dashboard glance, you don't have LLM observability.

Observability isn't a nice-to-have next to governance; it's the layer underneath it. Policy enforcement, cost attribution, and audit are only as trustworthy as the telemetry that proves they ran. "We block disallowed models" needs a metric that shows the blocks; "we attribute every dollar" needs token counts per tenant; "we can prove what happened" needs traces and logs. In DVARA, the DVARA LLM Gateway emits that evidence on every request, which is what turns governance claims into governance you can audit.

Traditional caching keys on an exact match: same input, same cached output. That works for HTTP and falls apart for language, because two prompts can be worded completely differently and mean exactly the same thing. "What's your refund policy?" and "How do I get my money back?" would miss an exact-match cache every time — and you'd pay to generate the same answer twice.

Semantic caching keys on meaning instead of bytes. But a cache that stores prompts and responses is also a governance surface: it can quietly hold raw PII, and it can quietly keep charging you for calls that never happened. Both are failure modes a governance platform has to close by default — which is why, in DVARA, the semantic cache lives inside the same governed path as Policy-as-Code and PII redaction, not off to the side.

For a lot of teams, the deciding question about an AI governance platform isn't what it does — it's where it runs. If your prompts contain patient records, financial data, source code, or anything a regulator cares about, routing them through a third party's servers is a compliance conversation you may not be allowed to have.

Self-hosting turns that from a data-egress problem into a governance guarantee. When the DVARA LLM Gateway runs inside your own infrastructure, the governance that matters most — Policy-as-Code evaluation, PII redaction, and the tamper-evident audit trail — happens before a request ever leaves your perimeter. A policy-denied or PII-blocked request never egresses at all. Self-hosting isn't just a deployment preference; it's what makes the governance enforceable on sovereign data.

The first LLM invoice that makes someone's stomach drop is a rite of passage. Spend is driven by token counts nobody was watching, spread across teams nobody was attributing, on models nobody chose deliberately. By the time it shows up on a bill, the money is gone and the cause is a forensic exercise.

Most tools answer this with a dashboard — visibility after the fact. That's the difference between observation and governance: a dashboard tells you what you spent; a governed control point can stop you from spending it. Real cost governance moves control upstream, to the moment each call is made — attributing it, and enforcing a budget on it, before the request leaves your perimeter. That enforcement lives in the DVARA LLM Gateway, the data plane of the AI governance platform.

DVARA 1.1.0 is generally available today. This release takes three capabilities that were technically possible in 1.0.x and makes them first-class: native MCP protocol support, drop-in SSO with verified Keycloak and Auth0 presets, and turnkey Kubernetes deployment validated end-to-end on GKE and DOKS.

Everything below ships in every install. There is no feature paywall — the same governance core, the same MCP Proxy, the same agentic controls. 1.1.0 is a drop-in upgrade from 1.0.x.

Model providers are remarkably good and occasionally unavailable. They rate-limit you at the worst moment, degrade under load, and have real outages. If your application talks to a provider directly, every one of those events is a user-facing failure — and every team ends up writing its own retry loop, usually badly.

Resilience belongs in the same layer as governance, and for the same reason: it can't be trusted if it's scattered and invisible. When failover runs at a single governed control point — the DVARA LLM Gateway, the data plane of the AI governance platform — every retry and provider switch is policy-checked and written to the audit trail, so "we failed over to a different provider" is a recorded, reviewable event, not a silent mystery. LLM fallback and failover move resilience out of application code and onto the governed path.

Once you're past a single model, a question shows up on every request: who should serve this one? Maybe cheap prompts go to a small model and hard ones to a frontier model. Maybe EU tenants must stay on EU providers. Maybe you're splitting load across two vendors for redundancy. Encode that in every application and you've spread the same brittle if/else — and the same ungoverned decision — across your whole codebase.

The reason to centralize routing isn't convenience; it's governance. The moment every model call flows through one control point, routing stops being scattered plumbing and becomes the place where policy is evaluated, cost is attributed, PII is scanned, and the decision is audited — before the request leaves your perimeter. Multi-provider routing is the mechanism; a single governed control plane is the point.