---
title: "Composability"
description: "Why Meerkat is both a composable library and a practical product layer."
icon: "cubes"
---

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

- [Concepts overview](/concepts/overview)
- [Tools](/concepts/tools)
- [Mobs](/concepts/mobs)
- [Architecture](/reference/architecture)
