Microbus is the Fabric for Agentic Workflows#

Microbus is the only fabric where every agentic workflow runs on a true microservice substrate. That single design choice gives your workflows security, scale, observability and prompt-driven authoring that bolt-on workflow engines cannot match.

Get started in minutes. Microbus is free and open source under the Apache 2.0 license.

Two Paths, One Fabric#

Pick the path that fits your domain — or use both, since they share the same plumbing.

Agentic Workflows — Multi-step processes with branching, parallel fan-out/fan-in, human-in-the-loop interrupts, and durable state. Lead with this if your problem is orchestrating a flow that takes minutes to hours and may need a human in the middle.
Microservices — Production-grade microservices with the substrate handling transport, observability, security, configuration and operational concerns. Lead with this if your problem is exposing a service that other services can call, or building out the toolset your agentic workflows invoke.

Why a Microservice Substrate Matters#

Every agentic claim Microbus makes — actor identity that follows a request through every tool call, security ACLs that match exactly what your code uses, distributed tracing across the entire workflow, OpenAPI documents that double as LLM tool descriptions — is a property of the microservice substrate, not of the workflow engine. Bolt-on workflow engines cannot deliver these because they do not own the runtime that processes the work.

Performant — Persistent multiplexed connections deliver up to 10x the throughput of HTTP/1.1, benchmarked at over 100,000 req/sec on a single machine.

Observable — Distributed tracing, structured logging and metrics are built in from the start, not bolted on after the fact.

Secure — A layered security model that pushes authentication and authorization down to the broker, where it is verified once and trusted everywhere.

Testable — Spin up a full integration test of multiple microservices in a single Go test function, with no containers or external dependencies.

Build an Agentic Workflow#

Microbus includes a built-in workflow engine — the Foreman — that orchestrates agentic workflows. Define the process as a directed graph of tasks. The Foreman handles execution, parallel fan-out and fan-in, state merging, human-in-the-loop interrupts, and automatic recovery from failures. State is persisted to a SQL database; the whole system is testable in-memory with go test.

Add a task VerifyCredit that receives a creditScore int and returns creditVerified bool

Add a task VerifyIdentity that receives ssn string and returns identityVerified bool

Add a workflow CreditApproval that fans out to VerifyCredit and VerifyIdentity in parallel, then fans in to a Decision task

Three prompts. One workflow. Tasks become independently testable, the graph is explicit and reviewable, and the Foreman handles the orchestration. See Build a Workflow for the full walkthrough.

Build a Microservice#

Microbus is designed to work hand-in-hand with coding agents like Claude Code. Each microservice is small, well-defined, and fits entirely in an agent’s context window. Tighter build-test-debug loops mean fewer mistakes and faster delivery. Multiple agents can work on different microservices in parallel without merge conflicts.

Create a new microservice “helloworld”

Create a web handler that prints “Hello, World!”

Create a config for the Greeting, with a default of “Hello”. The greeting must start with a capital letter and not be empty

Create a functional endpoint Add that sums up two integers x and y and returns the sum

Fire an event OnDouble when x==y in Add

Create a metric that totals the positive sums in Add, and another that totals the negative sums

Six prompts. Under 10 minutes. 819 lines of code at 87% test coverage. See Build a Microservice for the full walkthrough that exercises all six features of a microservice.

Security in Depth#

Microbus’s security model is built into the framework itself, not bolted on as middleware. Several independent layers stack to close different attack vectors:

Per-microservice identity. Each microservice opens its own NATS connection with its own signed credentials. The broker verifies the source of every message.
Precise true-to-code interservice ACL. Allow-lists are derived directly from each microservice’s source code at deploy time. A compromised microservice can do only what its code already does.
JWKS pinning. Actor JWTs are pinned to two framework-controlled issuers. Forged tokens fail verification immediately.
Actor-based authorization. Every request carries a short-lived actor JWT identifying the user it is being made on behalf of. Endpoints declare requiredClaims boolean expressions that the framework enforces uniformly.
Trust-root tier. Endpoints that mint tokens or perform privileged operations sit on a dedicated port that external traffic never reaches.

Operating Securely walks through the production deployment.

Scale and Performance#

Microbus scales horizontally without bottlenecks and performs well per instance. The transport, the microservices, the workflow engine, the cache, and even the trust-root services all add capacity by adding instances rather than upgrading hardware. See Scale and Performance for the full breakdown.

Architecture#

A Microbus solution is built on top of 5 layers:

OSS — A curated selection of proven technologies — NATS for messaging, OpenTelemetry for observability, Grafana for visualization — abstracted away by the layers above.
Connector — The base construct from which all microservices are derived. Provides a consistent API for transport, observability, configuration and lifecycle management.
Coding Agents — Generate boilerplate, business logic, tests and documentation using embedded skills that guide each feature end to end.
Microservices — Core microservices ship with the framework. Solution microservices implement your business logic. Both are built the same way using the same tools.
Applications — Microservices are bundled into applications according to the desired topology — a single binary, a handful of containers, or across availability zones.