Roadmap

[jfallows]

Zilla governs AI traffic the same way it governs API traffic: declaratively, in one
configuration, on one runtime. Three protocol families are covered — MCP for agent-to-tool
access, LLM for model API access, and A2A for agent-to-agent communication. Each has
its own bindings, which compose with Zilla's existing protocol bindings and reuse the same
guards, vaults, stores, catalogs, and telemetry.

Items marked Plus are Zilla Plus features. Everything else is open source.

---

MCP — agent-to-tool access

Available

• MCP server, proxy, and client over HTTP and SSE
• Federate many tool sources behind a single MCP endpoint, with per-source namespacing and automatic tool-title disambiguation
• Warm catalog caching — agents get a complete tools/list with no upstream round-trip
• Notification-driven catalog refresh — when an upstream signals a change, the cache refreshes and agents are notified once the new content is ready, and only when it actually differs
• Per-user tool, resource, and prompt visibility based on the caller's token
• Per-route allow-sets to constrain which primitives a given route exposes
• Tool-call argument validation against the published input schema
• Full MCP primitive surface — tools, resources, prompts, resource subscriptions, and resource templates
• Elicitation, including URL mode for interactive consent flows
• Agent-callable tool search — search_tools, describe_tool, and execute_tool keep large tool sets out of the context window
• Metrics and structured events for every MCP method, session lifecycle, and auth rejection
• Kafka — topics as tools: produce and consume, topic and cluster administration, broker and topic configuration, consumer groups with lag, and ACLs
• Kafka Connect — connector management as tools
• Schema Registry — subject and schema operations as tools
• OpenAPI — tools generated directly from a spec, with bulk, tag, and pattern-based selection
• HTTP — tools defined inline against any HTTP backend, as a proxy or a client

Planned

• Multi-cluster Kafka — route tools across clusters from a single binding
• Dynamic prompts for HTTP tool sources
• MQTT as a tool source
• AsyncAPI as a tool source — event-driven operations as tools
• gRPC as a tool source — tools generated from service definitions
• Semantic tool search — ranking by meaning rather than keyword (Plus)
• Adaptive tool-set caching — by size, by usage, or automatic (Plus)
• MCP tunnel — expose an internal MCP endpoint through a managed outbound tunnel with automatic certificate lifecycle (Plus)
• Per-user credential brokering — Zilla acquires and injects each caller's own upstream token, so a tool call reaches the backend as the user rather than as the gateway. Supports on-behalf-of exchange, service accounts, and signed assertions (Plus)
• Output schema projection — declare the response shape an agent should see; anything outside it is dropped before it reaches the model
• Cross-node affinity routing for multi-replica session state (Plus)

---

LLM — model API access

Planned

• A single governed endpoint in front of OpenAI, Anthropic, and Ollama APIs, with automatic dialect detection
• Model-based routing with fallback routes, failover, and load balancing
• Token quotas at tenant and user level, in three modes: track usage, reject over-quota requests, or transparently cap the request
• Impersonation — inject verified caller identity into the system prompt, so downstream models receive the context without the application having to pass it
• Credential injection from vaults, so provider keys never reach client applications
• Response stream pass-through with usage capture — token accounting without re-serializing the stream
• Token metrics and quota events exported over OpenTelemetry
• Amazon Bedrock and Google Vertex backends (Plus)
• Azure OpenAI with Microsoft Entra ID (Plus)

---

A2A — agent-to-agent communication

Planned

• Expose any Kafka-backed agent as a fully compliant A2A remote agent, with no HTTP or A2A awareness required in the agent itself — the agent reads and writes Kafka topics
• Complete protocol surface: message/send in blocking, non-blocking, and streaming modes, plus tasks/get and tasks/cancel
• Agent Card served from the schema registry at /.well-known/agent.json, versioned independently of the gateway configuration, with the card's own URL driving routing
• Multiple agents per binding
• Multi-turn tasks with guaranteed ordering, and durable task state — a client that disconnects mid-stream can reconnect and resume rather than losing partial output
• Horizontal agent scaling and natural back-pressure through Kafka

---

Roadmap items and sequencing are subject to change.