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.

Meerkat is easiest to understand as a composable agent runtime with a practical product layer on top. You can approach it from any surface:
  • Rust embedding
  • Python or TypeScript SDKs
  • CLI
  • REST / JSON-RPC / MCP
  • multi-agent orchestration
The core concepts fit together like this:

Read order

If you are new to Meerkat, a good concepts path is:
  1. Composability
  2. Realms
  3. Sessions
  4. Configuration
  5. Providers
  6. Tools
Then branch into the systems you need:

What each concept owns

ConceptMain question
ComposabilityWhat kind of product is Meerkat, and why do the surfaces behave like peers?
RealmsWhat defines shared vs isolated state?
SessionsHow does one conversation live, continue, and end?
ConfigurationHow are runtime settings stored and updated?
ProvidersHow are models resolved, selected, and capability-gated?
ToolsHow does the agent act on the world?
Auth & bindingsUnder what identity/credentials does the runtime talk to a provider?
Memory & compactionHow does Meerkat handle context beyond one model window?
CommsHow do long-lived agents exchange messages?
MobsHow does Meerkat coordinate multiple agents as one system?
SchedulingHow does durable automation fire over time?
RealtimeHow does low-latency interactive transport fit into the session model?

How the docs are organized

Meerkat’s docs are intentionally split by reader need, not by “beginner vs advanced developer”:
SectionWhat it should do
Getting startedGet the reader to a first successful run and into the examples hub
ConceptsExplain shared mental models first
GuidesHelp the reader accomplish a task or configure a system
ExamplesShow runnable patterns and learning progression across surfaces
ReferenceProvide exact contracts, inventories, and lookup material
ArchitectureExplain ownership, rationale, and deeper internal structure
OperationsCover release/distribution/operational workflows that are still part of real Meerkat usage
This matters because Meerkat is both a composable library and a practical product layer. In many cases the builder/operator boundary is intentionally small.

See also