MobKitConfig
Top-level configuration for the module runtime.ModuleConfig
RestartPolicy
DiscoverySpec
PreSpawnData
SDK/Gateway runtime options
The stock SDK gateway consumes theruntime_options object sent by Python and TypeScript builders during mobkit/init.
Unsupported nested fields fail initialization with
-32602 instead of being silently ignored.
Identity bootstrap
- Rust
- Python
identity_bootstrap_mode setter is an explicit
identity-first configuration and therefore requires a roster provider for all
three modes. Leave the setter unused to retain a classic non-identity gateway;
a configured roster with no mode continues to use eager materialization.
mobkit/status_identity_bootstrap returns a non-blocking typed snapshot.
mobkit/wait_identity_bootstrap accepts target = "materialized" or
"startup_ready"; terminal broken identities return with ready = false
rather than leaving the barrier pending indefinitely. Provider or restore
failures that apply to the whole pass are reported in the snapshot’s optional
error field.
The stock persistent gateway also advertises a private shutdown handshake and
its bounded stdio_shutdown_horizon_ms in the mobkit/init result. SDK hosts
keep stdin and provider callbacks open until that handshake completes, then
close the process. The current 335-second horizon covers an already-admitted
provider callback, runtime event and mob drains, the final lease-release
callback, and bounded response-delivery/reaping margin. Provider operations
must resolve or reject within their public 120-second contract. The Python host
allows 125 seconds for event-loop completion before cancelling that callback;
the TypeScript host exposes the same cancellation as an optional
ProviderCallbackContext and suppresses late callback responses; the gateway
enforces a final 130-second hard wire deadline. Provider rejection,
timeout, or cancellation is pre-commit: an implementation must not commit a
replacement grant or other external authority after cancellation is observed.
Older and custom gateways that do not advertise the handshake retain the EOF
shutdown protocol.
If the gateway exhausts its runtime deadline, it reports incomplete cleanup;
the SDK still reaps the bounded child process and then surfaces the failure.
Rust hosts that dispatch JSON-RPC from an Arc<UnifiedRuntime> should call
handle_unified_rpc_json_arc (or the corresponding with_live_arc entrypoint).
That transfers runtime ownership to supervised identity mutations, so a
disconnected request cannot cancel a cross-mob operation between its commit
and rollback points. The borrowed dispatcher fails identity-owned cross-mob
mutations closed because it cannot provide that ownership guarantee.
ConsoleUiConfig
View-level configuration for the stock console.mobkit_gateway discovers config/console.toml in the conventional workspace layout; rpc_gateway accepts the same file via runtime_options.console_config_path, and the TypeScript builder exposes .consoleConfig("config/console.toml").
The config is normalized and projected through GET /console/experience as console_config.
Agent grouping selectors and badge fields support
labels.<key>, label:<key>, raw label keys, and direct fields such as group, subgroup, role, kind, identity, member_id, and agent_id.
ConsoleUiConfig is intentionally view-level. It controls presentation, ordering, labels, default pins, and links; it does not decide runtime authorization, routing, or whether an agent exists.AuthPolicy
AuthProvider
ConsolePolicy
For standalone
mobkit_gateway launches, pass console_read_only: true in the
mobkit/init params or set MOBKIT_CONSOLE_READ_ONLY=true. This setting is
part of the gateway resume fingerprint, so toggling it creates or resumes the
matching runtime instead of reusing a runtime launched with the opposite policy.
RuntimeOpsPolicy
LocalJsonMemoryBackendConfig
For SDK builds that boot through
rpc_gateway, state_path is derived from .persistent_state(path) as <path>/memory-ledger-state.json; callers provide only backend: "local_json" (and optionally health_check_endpoint). The legacy ElephantMemoryBackendConfig / backend: "elephant" shape is deprecated: it was always local JSON persistence plus a health check — no data ever reached Elephant — and it converts to this config on load. Real Elephant integration is the wire-boundary provider described in docs/design/memory-hub-roadmap.md.
Agent memory injection
agent_memory is separate from mobkit/memory/*. It is hot identity-scoped memory plus prompt injection: during create/resume/materialize (and, when explicitly enabled, ordinary identity-first turns), MobKit asks an AgentMemoryProvider for memories keyed by AgentIdentity and injects a bounded, quoted observation summary. The bundled gateway provider defaults to one SQLite database per realm under <persistent_state>/agent-memory (store: "sqlite"); store: "markdown" keeps the earlier inspectable per-identity markdown files, and any existing markdown files are imported into SQLite on first open (originals renamed <file>.imported, never deleted). The path is server-owned and cannot be overridden from SDK init input. Elephant remains an optional deeper knowledge backend for graph/document/truth/provenance use cases and is not required for this hot path.
With the SQLite store, build-time injection also composes a metadata index (record ids, kinds, titles, descriptions, human-phrased age) over the identity’s readable scopes, budgeted at ~8 KiB, ahead of the selected record bodies; markdown deployments keep the bodies-only build injection. Every injected record is logged to an injection ledger inside the realm database and counted in per-record usage statistics; explicit mobkit/agent_memory/recall reads are counted separately from ambient injection.
Inbound anti-spoofing is on by default (defang_inbound: true): every non-steer identity-first send is scanned for reserved memory-envelope markers (the injection header pattern, <mobkit_memory_observation> tags, [mem-token: prefixes) and matches are visibly neutralized before delivery, so a peer message or echoed web content cannot impersonate remembered context. A warning with a hit count is logged whenever defanging fires. Steer sends bypass injection and defanging entirely.
Rust builders can use .persistent_agent_memory(AgentMemoryConfig::default()) with .persistent_state(path) and .roster_provider(...) to use the bundled markdown store. Callers that need a different authority can use .agent_memory(provider, config) instead.
Gateway callers can write records with mobkit/agent_memory/remember, read them with mobkit/agent_memory/recall, and delete individual records with mobkit/agent_memory/forget. TypeScript callers can use handle.rememberAgentMemory(identity, { title, body, tags, realm }), handle.recallAgentMemory(identity, { realm, selection, queryText, queryTerms, maxEntries }), and handle.forgetAgentMemory(identity, memoryId, { realm }); Python callers can use handle.remember_agent_memory(identity, title=..., body=..., tags=..., realm=...), handle.recall_agent_memory(identity, realm=..., selection=..., query_text=..., query_terms=..., max_entries=...), and handle.forget_agent_memory(identity, memory_id, realm=...). Writes and deletes are identity-scoped, require the identity to be registered in the identity runtime, and writes become turn context on the next identity-first send, plus build context on materialization/resume/respawn/reset for that identity. A successful write means the configured hot provider accepted the record; it does not mean optional Elephant extraction/enrichment has completed. Bundled markdown writes cap titles at 200 bytes, bodies at 64 KiB, and tags at 32 entries of 64 bytes each; each identity file is retained to at most 512 records and 8 MiB of rendered markdown, keeping the newest records when compacting.
When selection = "always", the latest memories for the identity are injected. When selection = "contextual" (the default), build-time injection sends synthesized identity/profile/label query text and deterministic terms; per-turn injection sends the raw current identity-first message plus normalized terms. Common stopwords are ignored by the bundled markdown provider and records below the relevance threshold are not injected. MobKit does not send app context or customizer-added instructions to the memory provider. Semantic/vector retrieval remains a provider concern rather than a MobKit runtime authority.
Per-turn injection is governed by per_turn_injection (default "off"). The default is deliberate: per-turn injection prepends the memory block into the delivered user message, which persists in the session transcript and is re-indexed into Meerkat’s session semantic memory at compaction — so ambient push stays off until an indexing-excluded delivery class exists, and memory reaches the model through build-time instructions and explicit recall instead (both echo-safe surfaces). Setting per_turn_injection = "budgeted" opts back into ambient per-turn push, bounded by an injection budget ladder: at most ~4 KiB rendered per record, 20 KiB per assembly, and 60 KiB cumulative per delivered session, with records injected at most once per session (cross-turn dedup). Build-time injection always applies the per-record and per-assembly caps.
Automatic build/turn injection uses recall_timeout_ms (default 500, max 30000) and recall_failure_policy (default "skip", or "fail"). With the default skip policy, provider errors and timeouts omit the memory block and allow delivery to continue. Explicit mobkit/agent_memory/recall requests still return provider errors.
Agent memory is identity-scoped and is not automatically cleared by session respawn or identity reset. Apps that require privacy reset semantics can call mobkit/agent_memory/forget for specific records or use an AgentMemoryProvider whose lifecycle policy clears memory alongside the app’s identity lifecycle. forget removes records from future recall and injection; it does not erase text already delivered into an active model context, so reset or respawn the identity after deletion when immediate context revocation matters.
BigQueryNaming
ScheduleDefinition
ReleaseMetadata
Trust manifest (mobkit.toml)
Constants
See also
- Modules — module configuration in context
- Authentication — auth policy usage
- Sessions — session store configuration
