Coding agents now make a large share of an engineering team's model calls. Most of those calls go straight from a laptop to a provider, outside your keys, policies, budgets and audit trail.
DVARA 1.9.0 brings them back onto the governed path. It also serves the newest MCP and A2A protocol versions, and it signs agent-to-agent delegation so each hop can prove whose authority it carries.
Agent A asks Agent B to do a task. Agent B needs something from Agent A, so it asks. Agent A, to answer, asks Agent B again. How do you stop that recursion?
Carry a signed delegation chain with the call: a record of which agents it has already passed through. Check it before calling the next agent. With strict agent matching and enforcement turned on, a return to an agent already in the chain stops there. In the DVARA AI governance platform, you can also allow a return for a different skill. The choice matters, as does requiring agents to pass the chain along: a signature prevents edits, but it cannot stop an agent from leaving the chain out.
AI applications rarely stop at one model call. They call different providers, use tools through MCP, and increasingly hand work to other agents. Each hop is a place where policy, data, spend, or evidence can fall apart.
DVARA 1.8.0 puts those calls on one governed path. It introduces a clean Open Source foundation for LLM traffic and strengthens the Enterprise controls used across models, tools, and agents.
How many LLM calls did your company make yesterday?
Most platform leads can't answer. Not roughly, not which providers, not which teams. That gap has a name — shadow AI — and it is a visibility problem long before it is a policy problem.
DVARA 1.6.0 made the free Community Edition a separate image that anyone could pull and evaluate. This post records how that distribution worked when 1.6 shipped; the update below explains what replaced it in 1.8.
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 adds a third governance plane: agent-to-agent. It puts identity, policy, PII checks, and tamper-evident audit on the hop from one agent to another, alongside the existing LLM and MCP planes.
Everything below ships in every Enterprise install — 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 workspace; "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.