plano
worthwhileRust-built Envoy proxy that centralizes agent routing, observability, and guardrails — real production plumbing, not a wrapper.
What it is
A Rust-based proxy server (built on Envoy) that sits between your agentic apps and the world, providing YAML-configured agent routing, LLM model/alias routing, OpenTelemetry auto-tracing, and filter chain guardrails. Agents register via a config file; Plano intercepts their chat completions endpoint and handles orchestration, observability, and safety in a sidecar process.
How it differs from vanilla Claude
Vanilla Claude can orchestrate multi-agent flows via prompt-based routing and write manual tracing/logging, but it cannot: (1) hot-reload agent registrations without code change, (2) apply jailbreak/memory filters transparently, (3) route between models by semantic alias with automatic fallback, (4) provide Envoy-grade latency and reliability at scale, or (5) capture rich agentic signals (e.g., tool usage, intents) without you writing any instrumentation code.
Skill, plugin, or workflow shift?
Standalone-app integration — you run a daemon (planoai) that listens on port 8001 (or configurable) and proxies to your agent servers. Requires changing your agent code only to accept OpenAI-compatible format, which is common. Not a plugin or library; it operates out-of-process.
Devil's advocate — is this just complexity?
A vanilla Claude agent (or GPT-4) can already function as a router if you structure your system prompt to classify intent and hand off to sub-agents via function calling. The tracing and guardrails can be done with a dozen lines of middleware in FastAPI or a simple Langfuse wrapper. Plano adds a complex Envoy dependency, a custom YAML schema, a separate Rust binary, and a hosted 4B routing model — for what? You could achieve 90% of the multi-agent flow with a single well-prompted LLM and a lightweight Python daemon. The only clear win is performance at scale: Envoy-tier concurrency and the dedicated routing model. For most dev teams shipping their first multi-agent app, this is heavy infrastructure before the shape of the app is even stable.
What would make it better
(1) Plano-as-a-library: a Rust crate or Python package that embeds the proxy logic so small projects don't need a separate daemon. (2) A 'bring-your-own-routing-model' path: currently tied to plano_orchestrator_v1; expose a plugin interface for any router model. (3) Lower the entry bar with a `planoai dev` mode that auto-discovers agents in the current directory without a YAML file. (4) Self-contained docker-compose one-liner that includes a local ollama for routing to avoid the hosted dependency.
The honest case for it
When your agent system has 5+ agents, multiple model providers, and a production requirement for low-latency routing, observability, and guardrails — Plano replaces the need to build an ad-hoc orchestration layer in each microservice. The Envoy foundation means it can handle real traffic spikes. The dedicated routing model (4B params) is cheaper and faster than using GPT-4 for routing. The zero-code OTEL traces and signals give you evaluation data you otherwise wouldn't collect until after an incident. It's a genuine 'buy vs build' win for teams already struggling with the hidden middleware mess.
Who it's for
Audience fit
Depth and leverage for a technical engineer who wants to understand it and level up their workflow — not just offload work.
Value for someone who wants a more capable tool without the technical depth — accessible, does-it-for-you.
Engineers get real leverage: Rust-based Envoy proxy that offloads routing, tracing, and moderation without framework lock-in. Vibe coders will hit the YAML learning curve and need to run a separate daemon.