Skip to main content
Composability is the core idea that explains almost everything else in Meerkat. Meerkat is:
  • a library-first runtime
  • with a practical product layer
  • exposed through multiple peer surfaces
That means the same underlying system can be used as:
  • a Rust crate embedded in your app
  • a Python or TypeScript SDK backend
  • a CLI for hands-on work
  • a REST / JSON-RPC / MCP integration surface
  • a multi-agent runtime

​
Why this matters

Because Meerkat is composable:
  • the surfaces are not separate products with separate semantics
  • examples should usually treat the major surfaces as peers
  • concepts such as realms, sessions, tools, and mobs should make sense across surfaces
  • advanced builder/developer docs can still be part of the public docs set, because the “developer” and “operator” roles often overlap

​
The Practical Consequence

Composability means the same decisions show up across surfaces:
  • model and provider choice is resolved through one model registry
  • tools, skills, hooks, and memory are composed into one agent build path
  • persistent state is scoped by realm rather than by one CLI invocation
  • mobs coordinate multiple sessions without inventing a second agent runtime
  • release and deployment choices affect real users because SDKs and binaries share the same runtime surfaces

​
One construction path

Public surfaces compose agents through the facade AgentFactory. The factory resolves model identity, realm-owned credentials, stores, tools, hooks, skills, memory, compaction, and runtime handles before it crosses the sealed core builder seam. The lower-level core AgentBuilder is an implementation detail, not a second public assembly path with weaker policy. This matters because an override replaces one typed dependency without discarding the surrounding contract. Examples include an AgentLlmClient, tool dispatcher, session store, blob store, detached-job store, or compaction curator. Model/provider identity and runtime authority are still validated at the factory boundary.

​
Two runtime modes

RuntimeBuildMode makes the ownership boundary explicit: Queue-only ephemeral services are useful substrates, but they are not a durable control plane. Features that require session-owned authority fail closed instead of manufacturing a local substitute.

​
Independent capability composition

Capabilities are not one monolithic “tools enabled” switch. General builtins, shell, semantic memory, schedules, WorkGraph, comms, mob tools, image generation, and web search are resolved independently, then flattened into one model-facing catalog. Compile-time feature gates decide which implementations exist; factory defaults and per-build overrides decide which are visible for a specific session. The same rule applies beyond tools. Skills use typed source identities, hooks observe typed runtime projections, memory is scoped to an owner, and providers lower one canonical request model. Composability means substitutable implementations behind stable contracts, not duplicated semantics per surface.

​
See also