Shannon: a Go and Rust orchestration stack for multi-agent tasks
A production-oriented multi-agent orchestration framework.
At a glance
- What is it?
- Shannon is an MIT-licensed, production-oriented multi-agent orchestration framework written primarily in Go, with a Rust agent core and a Python LLM service. Its selling point is operational control: Temporal-backed workflows, hard token budgets, strategy routing, and a WASI sandbox, all wired together through a Gateway on port 8080.
- Who is it for?
- Shannon fits teams that already run Docker Compose and want an orchestration layer with Temporal workflows, per-task token budgets, and a sandboxed agent core rather than a single-process library. It is the wrong choice if you want a minimal embedded agent loop, if you cannot operate PostgreSQL, Temporal and Redis alongside the app, or if you need the Skills System documented end to end before committing, since the README truncates that section.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 11 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Shannon targets: agents that fail without a trace
Most agent frameworks give you a loop and a tool list. Shannon's README frames the problem differently, in a table of operational failures: agents failing silently, costs spiraling, no visibility, security concerns, vendor lock-in. The framework's answer to each is a named mechanism rather than a promise. Silent failure is addressed with Temporal workflows and what the README calls time-travel debugging, meaning any execution step can be replayed. Cost control is a hard token budget per task and per agent, with automatic model fallback when a budget is exhausted. Visibility is real-time event streaming plus Prometheus metrics and OpenTelemetry tracing. Security is a WASI sandbox for code execution, OPA policies, and multi-tenant isolation. Provider lock-in is handled by supporting OpenAI, Anthropic, Google, DeepSeek, xAI, and local models through Ollama. The intended user is a team that already ships services and wants agent execution to behave like the rest of its infrastructure: durable, observable, and bounded. That is a narrower audience than the one a general-purpose agent library addresses, and the architecture reflects it.
Four services, four languages, and where each one sits
The README's architecture diagram shows a linear path: Client, then Gateway in Go on port 8080, then Orchestrator in Go on port 50052, then Agent Core in Rust on port 50051, then LLM Service in Python on port 8000, then providers. A fifth service, Playwright in Python on port 8002, handles browser automation. Each hop has a defined job. The Gateway terminates REST, does JWT or API key auth, and applies rate limiting. The Orchestrator owns Temporal workflows, task decomposition, and budget management. The Agent Core is described as an enforcement gateway with the WASI sandbox, token counting, and a circuit breaker. The LLM Service holds provider abstraction, MCP tools, the agent loop, and context management. Underneath, PostgreSQL backs the Gateway, Temporal backs the Orchestrator, and Redis backs the Agent Core. The split means token enforcement lives in Rust, separate from the Python code that actually calls providers, so a runaway loop has a checkpoint outside the process that generated it. The cost is that a single task traverses four network hops and three runtimes before reaching a model, and every one of those services has to be healthy for a request to complete.
Strategy routing decides how much machinery a query gets
Shannon does not run every query through the same path. The README lists eight execution strategies selected by complexity. Simple covers anything scoring below 0.3 and produces a single-agent direct response. DAG is the default for multi-step tasks and does fan-out with fan-in and dependency tracking. ReAct handles iterative reasoning with tool use. Research uses tiered models, which the README claims cuts cost by 50 to 70 percent, though the material does not show the measurement behind that figure. Exploratory maps to tree-of-thoughts and runs parallel hypothesis exploration. Browser Use drives the Playwright service. Domain Analysis is described as specialized deep research. Swarm runs lead-orchestrated teams with convergence detection. Two of these can be forced rather than inferred: passing force_research with research_strategy set to deep, or force_swarm, in the task context. That forcing matters because automatic complexity routing is the kind of thing that is hard to predict from the outside. If a task lands on DAG when you expected Swarm, the request shape is the only lever the README documents for overriding it.
Getting it running: the install script and the first task
The prerequisites are Docker, Docker Compose, and an API key for at least one provider. The documented one-command install is curl -fsSL https://raw.githubusercontent.com/Kocoro-lab/Shannon/main/scripts/install.sh | bash, which the README says downloads config, prompts for API keys, pulls images, and starts services. Required keys are OPENAI_API_KEY or ANTHROPIC_API_KEY, or any OpenAI-compatible endpoint. SERPAPI_API_KEY and FIRECRAWL_API_KEY are optional and tied to web search and web fetch. Once running, a task is a POST to http://localhost:8080/api/v1/tasks with a JSON body containing query and session_id, and events stream from /api/v1/stream/sse with a workflow_id parameter. There is also a Python SDK installed with pip install shannon-sdk, exposing ShannonClient with submit_task and wait, and an OpenAI-compatible surface at http://localhost:8080/v1 that the README presents as a drop-in replacement. Skills are listed at GET /api/v1/skills and invoked by adding a skill field such as code-review to the task body, with custom skills placed in config/skills/user/. Note the README's own warning that this directory is gitignored and may need creating. Piping a remote script into bash is the documented path, so reading scripts/install.sh before running it is a reasonable precaution, not a criticism.
Where the design creates friction
The heaviest constraint is the dependency set. PostgreSQL, Temporal, and Redis all sit under the application, and the README's quick start assumes Docker Compose manages them. A team that wants an agent loop inside an existing binary is not the audience here; Shannon is closer to deploying a small platform than adding a library. The language split has a second-order cost. Debugging a failed task may mean reading Go orchestration code, Rust enforcement code, and Python agent-loop code, and the README does not describe a single trace that spans all three beyond noting OpenTelemetry tracing exists. The Skills System section is truncated in the supplied material right at the human-in-the-loop approval paragraph, so the OPA policy configuration for approval gates cannot be confirmed from what is available. The 50 to 70 percent research cost reduction is stated without a described methodology. The README also does not state what happens to an in-flight Temporal workflow when the Agent Core circuit breaker trips, or whether budget exhaustion mid-task produces a partial result or a hard failure. Those are the questions to answer before trusting it with a long-running job.
How this differs from LangGraph and similar graph libraries
The closest comparison is a Python graph library such as LangGraph, where you define nodes and edges in process and the runtime is your own application. Shannon inverts that. The graph is a Temporal workflow owned by a separate Go service, so execution state survives a process restart and can be replayed, which is the mechanism behind the README's time-travel debugging claim. Budget enforcement sits in a Rust service rather than in the Python code that calls the model, so it cannot be bypassed by a bug in the agent loop. The trade is operational weight: LangGraph needs a Python environment, Shannon needs a Compose stack with three backing stores and four services. A second comparison is a hosted agent platform, where the orchestration is someone else's and provider lock-in is the cost; Shannon's answer is running local models through Ollama while keeping the same Gateway API. If your work is a single agent with a handful of tools, none of this buys you anything, and the graph library will be faster to iterate on.
Maintenance, releases, and what MIT means here
The release history in the supplied material shows v0.5.1 and v0.5.0 both tagged on 2026-06-02, preceded by v0.4.1 on 2026-04-04, with the last push to main on 2026-09-05. Two releases on the same day suggests a fast correction after a tag, which is worth noting if you pin versions; v0.5.1 is the one to pin. The project is not archived. The licence is MIT, which permits commercial use and modification provided the copyright notice and permission notice are retained; that is the general shape of the licence, not legal advice, and any redistribution question should go to your own counsel. The upgrade surface is broad because the stack spans four services and three backing stores. A change to the token-counting contract between the Rust Agent Core and the Python LLM Service is a coordinated upgrade, not a pip install. Practical maintenance means tracking the Docker images published under waylandzhang on Docker Hub and reading release notes for interface changes between services. The README does not describe a migration or compatibility policy across minor versions, so treat each release as potentially requiring a full stack restart and a re-read of the notes.
Editorial conclusion
Shannon fits teams that already run Docker Compose and want an orchestration layer with Temporal workflows, per-task token budgets, and a sandboxed agent core rather than a single-process library. It is the wrong choice if you want a minimal embedded agent loop, if you cannot operate PostgreSQL, Temporal and Redis alongside the app, or if you need the Skills System documented end to end before committing, since the README truncates that section. Verify first that the install script and the Docker Hub images under waylandzhang resolve, that your chosen provider key works against the LLM Service on port 8000, and that your task actually routes to the strategy you expect rather than the default DAG path.
Community notes