Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.rkat.ai/llms.txt

Use this file to discover all available pages before exploring further.

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

​
See also