True. Microagents. Dynamic Discovery. Decentralized.
A Go framework that takes the microservices pattern and applies it to multi-agent systems. Specialized agents and tools register their capabilities with a shared registry, find each other by logical name at runtime, and coordinate without a central conductor. Built to blend into the Kubernetes platform.
Pick whichever fits your workflow. First-time setup takes 5–10 minutes.
Works with Claude Code, Codex, Cursor, Aider, or any coding agent that can read files in your workspace.
git clone https://github.com/truvaagents/truva-g3.git
cd truva-g3Paste into the agent — for the travel demo:
I want to run the example travel agent in my local. Follow GETTING_STARTED.md and start the setup.After that, to also add the devops agent:
Now install the devops-chat-agent and its associated tools.
macOS or Linux. From a fresh clone to a chat UI
you can talk to.
Prereqs: Go 1.27+, Docker, Kind, kubectl.
1. Clone and enter the example
git clone https://github.com/truvaagents/truva-g3.git
cd truva-g3/examples/travel-chat-agent2. Set one AI provider key
cp .env.example .env # then edit .env: set provider api key3. Deploy cluster + infra + agent + chat UI
./setup.sh full-deploy4. Open http://chat.localhost
Either path lands you at a working travel-chat-agent you can run — or pick the devops-chat-agent if you'd rather start with the absolute minimum (one AI key, no external APIs).
Most agent frameworks bind tools and agents at construction time. TruvaG3 inverts that — components advertise capabilities to a shared registry and find each other at runtime. The framework built around that core makes six commitments.
Tools and agents advertise what they do; agents resolve to whichever endpoint serves that capability at runtime. Add, scale, or replace without rewiring callers.
No central conductor. Each agent reads the shared registry, resolves capabilities, and calls peers directly over HTTP/REST.
Ordinary Deployments and Services. No proprietary CRDs, no required sidecars, no control plane. Built on HTTP/REST. Distributed tracing via OpenTelemetry.
Implements LLM-as-a-Service pattern. Switch between OpenAI, Anthropic, Gemini, or any OpenAI-compatible endpoint (Groq, Mistral, Ollama) without changing agent code.
Auto-instrumented end-to-end. Every plan, step, and LLM call is captured — inspect them in the bundled Registry Viewer. Distributed traces span agents and tools, with logs auto-correlated by trace ID — all flowing via OpenTelemetry to any compatible backend.
Open by design. Every backend — discovery, memory, telemetry, LLM provider — sits behind a swappable interface. Default local stack is based on fully open source software.
The full introduction lives at TruvaG3 — A Guided Tour — why it exists, how it works, and when it fits.
The orchestrator discovers available tools from the shared registry, asks the LLM to plan a sequence of calls, executes the plan — a directed acyclic graph (DAG) — with parallelism where dependencies allow, and synthesizes the results. No tools are named in the agent's source.
// Create orchestrator — no explicit tool/agent wiring needed
orchestrator := orchestration.CreateOrchestrator(config, deps)
// Process a natural-language request
response, _ := orchestrator.ProcessRequest(ctx,
"Perform a full Kubernetes cluster health check", nil)ProcessRequest call
above into a multi-phase plan — parallel where dependencies
allowed, re-planned between phases, then synthesized.
(click to expand)
The runnable example lives at
examples/travel-chat-agent/;
the Getting Started guide
walks through it step by step — top to bottom on a laptop.
Every participant — tool or agent — publishes the capabilities it offers into a shared registry. When a request arrives, the agent reads the registry's current contents and hands that to the LLM as its planning catalog. The LLM picks capabilities by name; the framework resolves each name to a live endpoint and dispatches directly over HTTP. No participant is named in any caller's source code — the tool list is runtime data, not configuration. And at the dispatch site, a tool and an agent are indistinguishable: the registry is what tells the framework where to send the call.
One consequence of this design becomes visible in real execution: an agent calling another agent is the same dispatch as an agent calling a tool — same registry lookup, same HTTP call, same structured response. The query below crosses three unrelated domains: "Can you analyze the status of the local Kubernetes cluster? Also, let me know the current weather at NYC, and the stock price of Tesla."
travel-chat-agent's plan put
devops-chat-agent on the same row as the three tool
capabilities — the planner picked by capability, not by participant
type. On the right, that single step expanded into a full
plan-act-observe run inside devops-chat-agent. The
caller never saw it: it got back JSON matching the published
capability schema, the same as for any tool.
(click either to expand)
One AIOrchestrator drives plan → execute → synthesize, returning to plan when fresh data unlocks the next phase. Plans are DAGs of capability invocations executed with parallelism where dependencies allow.
No process in the middle. Each agent reads the shared registry, resolves capabilities to endpoints, and calls peers directly over HTTP/REST — whether those peers are tools or other agents.
The full architecture write-up lives at A Microagents Reference Architecture — concept-first, citation-grounded, with execution traces from a running cluster.
Built the way you'd want it built. The things you'd look for in a fellow developer's framework, baked in.
Only core is required. AI, orchestration, memory,
telemetry, and resilience are independent, optional modules —
import only what your component needs.
Every external dependency (LLM provider, registry, memory backend, telemetry) sits behind an interface. Swap implementations without touching call sites.
Zero-config to start; every default is overridable. Swap LLM
providers, memory backends, or any framework interface via
WithXXX() options. Drop to direct constructors
for full control — no cliffs between layers.
Operational knobs (TTLs, token budgets, limits, endpoints) live in environment variables, not code. Change behaviour from outside the binary.
OpenTelemetry traces, metrics, and logs across agents and tools — auto-correlated by trace ID. Pipe to any OTel-compatible backend.
A full agent-dev stack runs on your laptop via Kind — registry, distributed tracing, metrics, logs, dashboards, vector store. Explore the whole system end-to-end.
The full design principles live in
FRAMEWORK_DESIGN_PRINCIPLES.md
— a contract, not a brochure.
Built to blend into the Kubernetes platform you already operate — no new control plane, no proprietary primitives, no playbook to rewrite.
Agents and tools are ordinary Deployments behind Services, communicating over plain HTTP/REST. Service mesh, ingress, mTLS, and tcpdump/curl all apply unchanged. No CRDs, no required operators, no proprietary control plane.
Traces, metrics, and logs flow through the standard OTel Collector. Route them to whatever backend your team already runs — Datadog, Honeycomb, Tempo, Jaeger, or anything else that speaks OTLP.
A heavily-used tool is a Deployment behind a Service. Same HPA, same rolling updates, same PDBs as every other workload.
Readiness probes, restart policies, TTL eviction. A misbehaving participant is recovered the same way any pod is. No global state to repair, no cross-component lock to release.
Components ship as plain Docker images and standard Kubernetes manifests — the operational surface is language-agnostic. Your existing build, scan, sign, and deploy chain (GitHub Actions, Argo CD, Flux, Helm — whatever you run) handles them like any other containerized workload.
The whole stack — agents, tools, Redis registry, OpenTelemetry pipeline, pre-built Grafana dashboards, vector store — fits in a single Kubernetes namespace. Pair with a local LLM in the same namespace for a fully self-contained, air-gapped setup.
Reference manifests, dashboards, and setup scripts live at
examples/k8-deployment/
— kubectl apply, audit, keep what fits.
Long-form pieces about the architecture and the broader research that informs it.