Mission Statement

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.

This page is the philosophical anchor - what we believe about distributed systems, why we built Microbus the way we did, and what we are deliberately rejecting in the conventional alternative. The home page covers what Microbus does; the microservice substrate page covers how it’s built. This page covers why.

Why Microservices

Microservices are the architecture best suited to deal with the technical and organizational challenges of a growing business. That belief is the foundation Microbus is built on.

• Scale the engineering organization. Independent microservices let independent teams move at independent speed.
• Elevate engineering experience. A small, focused unit of code is dramatically easier to reason about than a sprawling monolith.
• Contain the complexity of the codebase. Each microservice carries the complexity of one bounded concern, not the system as a whole.
• Scale horizontally to handle more load. Capacity grows by adding instances, not by upgrading hardware.
• Stay agile and adaptable to change. A microservice can be rewritten or replaced without rewriting the system.
• Harden your solution to better deal with failures. Failures stay local, and the rest of the system keeps running.

This is also what makes Microbus a natural fit for coding agents: each microservice fits entirely in an agent’s context window, the build-test-debug loop is tight, and multiple agents can work on different microservices in parallel without merge conflicts.

Holistic

Holistic adj /hō-ˈli-stik/ : characterized by the belief that the parts of something are interconnected and can be explained only by reference to the whole.

Microbus is holistic by design. The transport, the observability, the security model, the agent skills, the workflow engine - they are not independent libraries you assemble. They are parts of one whole, designed to fit together. That is also why every agentic claim Microbus makes is true: actor identity propagates through every tool call because the framework owns the whole call chain, not because a workflow engine bolted authentication onto its top layer.

The corollary: when something does not fit the whole, it stays out of scope. See Design Notes for the explicit boundaries.

Engineering Velocity

Engineering velocity is one of the primary incentives for Microbus. The framework is built on the belief that the speed at which a team can iterate is not a nice-to-have - it is a competitive property - and that the conventional microservice stack actively destroys it.

Velocity is bounded by the slowest part of the dev/test/debug loop. Microbus collapses that loop:

• Run the whole solution on a laptop. A bundled application of dozens of microservices builds and starts in seconds, in one OS process, debuggable from one IDE. See Local development.
• Integration tests in-process. The test harness spins up a microservice along with its real downstream dependencies inside one Go test - no containers, no docker-compose, no waiting on K8s.
• One conventions surface. Each engineer learns the Connector API and the agent rules, not the union of fifteen separate systems’ conventions and config formats.
• Coding agents are productive immediately. Each microservice fits in an agent’s context window. The agent’s feedback loop is tight - typically seconds per iteration - so code lands faster and with fewer bugs. See Agentic RAD.

The compounding effect: each individual speedup is modest, but they compose. A team using Microbus iterates not 10% faster than a team on a conventional stack - they iterate at a fundamentally different cadence.

The Conventional Practice We Replace

The conventional practice of developing microservices is a jumble of sophisticated systems that no one truly fully understands. The high level of complexity introduces friction to the software development lifecycle, significant operational costs, and failure points that cause unexplained outages. It takes a small army of engineers to keep the system afloat.

A non-exhaustive list of what we replace with one fabric:

• Web server for each microservice
• Service discovery (DNS, Eureka, Consul, ZooKeeper)
• Load balancer
• Port mapping
• Connection pooling
• Health and liveness checks
• Client-side load balancing
• gRPC
• Kubernetes
• Service mesh (Istio, Envoy, Consul)
• eBPF networking (Cilium, Calico)
• Separate system for pub/sub (Redis, RabbitMQ)
• Separate system for caching (Redis, memcached)
• K3s for local development

Each entry is one moving part fewer for an operator to learn, configure, monitor, and troubleshoot - and one fewer source of failure. Reliability does not just add across systems; it compounds. A stack where each component has 99.9% availability runs at less than that overall, and the more components there are, the worse the math gets. Replacing fifteen moving parts with one fabric is not just a simpler diagram - it is a meaningfully different reliability profile.

Complexity also creates friction in development. Every additional system is something each engineer has to spin up locally, debug across, mock in tests, and wait on in CI. That friction shows up as slower iteration, longer onboarding, and an ever-thicker layer of integration glue maintained between teams. Consolidating onto one fabric collapses that surface area - a single binary on a developer’s laptop runs the whole solution, integration tests execute in-process in seconds, and there is one set of conventions to learn rather than a stack of them.

The cost of that consolidation is that Microbus is opinionated about how the substrate works. The benefit is that the result is reasonable to understand, deploy, audit, and develop against end-to-end.