Skip to main content
Meerkat can be a command-line tool, an agent inside your application, or the runtime for an ongoing agent system. Composability lets you choose the capabilities and integration path that fit your use case.

Choose Your Integration Path

Each path uses the same session, provider and tool contracts. A session can be created through one surface and resumed through another when both use the same realm and persistence location.

Choose Your Capabilities

Composition happens at two levels:
  • Build configuration selects optional providers and subsystems through Cargo features. Use a small embedded configuration or a full native harness; the capability matrix describes the profiles.
  • Host and agent configuration selects models, tools, stores, skills, hooks, memory and runtime services. Different agents in one application can have different capabilities and permissions.
You can supply your own implementations through typed interfaces, use the provided implementations, or combine them. Shared contracts carry session lifecycle and provider behavior across these choices.

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