Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SKILL.state MCP Runtime Initialize a state for my multi-step analysis task"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Traditional LLM agent workflows rely on append-only conversation history [m_1, r_1, o_1, m_2, r_2, ...]. Over long horizons, this design exhibits three fundamental failure modes:
Context Bloat: Token consumption scales monotonically as $\mathcal{O}(T)$, exhausting context windows and elevating per-turn latency.
Reasoning Poisoning: Stale thoughts ($R_t$) and abandoned hypotheses persist in context, biassing subsequent turns.
State Hallucination: Agents lose track of variables, counters, and completed subtasks buried across thousands of tokens of prose.
SKILL.state (arXiv:2608.26263) replaces conversational history with an explicit, formal state tuple $(P, \Sigma_t, O_t)$:
$P$: Immutable skill specification (frozen task instructions).
$\Sigma_t$: Explicit, typed execution state (JSON object).
$O_t$: Latest environment observation.
$R_t$: Chain-of-thought reasoning, discarded at the tool boundary each turn to prevent reasoning loops and context leakage.
Conventional Agent (Append-Only History)
[msg1][R1][O1][msg2][R2][O2][msg3]... ──▶ Context grows monotonically ──▶ Poisoning & Rot
SKILL.state (Formal State Runtime)
Turn t input: (P, Σ_t, O_t)
LLM response: R_t (discarded) + ΔΣ_t (sparse patch) + a_t (action)
Server transition: Σ_{t+1} = Σ_t ⊕ ΔΣ_t ──▶ Execute a_t ──▶ O_{t+1}
Turn t+1 input: (P, Σ_{t+1}, O_{t+1}) [Context size remains O(1) bounded]Related MCP server: Stratum MCP Server
In accordance with standard Model Context Protocol deployment patterns, the server can be run dynamically via npx (recommended for all MCP clients) or installed globally via npm.
Add the server to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"skill-state": {
"command": "npx",
"args": ["-y", "@bub0lehich/skill-state-mcp-server"]
}
}
}Register the server using Anthropic's Claude Code CLI:
claude mcp add skill-state -- npx -y @bub0lehich/skill-state-mcp-serverAdd to .cursor/mcp.json in your project root or open Settings -> Features -> MCP -> Add New MCP Server:
{
"mcpServers": {
"skill-state": {
"command": "npx",
"args": ["-y", "@bub0lehich/skill-state-mcp-server"]
}
}
}Add to cline_mcp_settings.json or your MCP extension configuration:
{
"mcpServers": {
"skill-state": {
"command": "npx",
"args": ["-y", "@bub0lehich/skill-state-mcp-server"]
}
}
}If you prefer installing the binary once onto your system rather than downloading via npx:
npm install -g @bub0lehich/skill-state-mcp-serverOnce installed, reference the binary directly:
{
"mcpServers": {
"skill-state": {
"command": "skill-state-mcp-server"
}
}
}Install as a dependency in your application:
npm install @bub0lehich/skill-state-mcp-serverimport { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { registerSkillStateTools } from "@bub0lehich/skill-state-mcp-server";Used by Claude Desktop, Cursor, and IDEs via stdin/stdout:
npx -y @bub0lehich/skill-state-mcp-serverFor microservice architectures and remote agents:
npx -y @bub0lehich/skill-state-mcp-server --http --port 3211MCP Endpoint: POST http://localhost:3211/mcp
Liveness Probe: GET http://localhost:3211/health
At each step $t$, the agent emits a sparse state patch $\Delta\Sigma_t$. The runtime applies the formal merge operator:
$$\Sigma_{t+1} = \Sigma_t \oplus \Delta\Sigma_t$$
Null serves as an explicit first-class deletion instruction, distinguishing field removal from field omission:
Patch Value in $\Delta\Sigma_t$ | Semantics on Target State $\Sigma$ |
| Deletes the key from $\Sigma$ |
| Inserts or overwrites scalar value |
| Recursively merges nested objects ( |
| Replaces array wholesale (deterministic, avoids positional diffing) |
(omitted) | Preserved (sparse delta) |
// Current State Σ_t
{
"order_id": "ORD-402",
"phase": "inventory_lookup",
"scratchpad": "checking shelf availability...",
"attempts": 1
}
// Patch ΔΣ_t // New State Σ_{t+1}
{ {
"phase": "packing", "order_id": "ORD-402",
"scratchpad": null, ⊕ = "phase": "packing",
"shelf": "shelf_42", "shelf": "shelf_42",
"attempts": 2 "attempts": 2
} }Tool | Parameters | Description |
|
| Boots a new state session and returns the $(P, \Sigma_0, O_0)$ tuple. |
|
| Executes a turn: drops $R_t$, merges $\Delta\Sigma_t$, executes $a_t$, and returns $(P, \Sigma_{t+1}, O_{t+1})$. Rolls back $\Sigma$ on validation error or action rejection. |
|
| Injects external observations or asynchronous environment updates (§5.4 State Recovery). |
|
| Utility to extract $R_t$, $\Delta\Sigma_t$, and $a_t$ from raw fenced ```json blocks (Appendix A.4). |
|
| Finalizes a session and returns the terminal state snapshot. |
Inspection endpoints operate with zero LLM-context cost:
skill-state://{session_id}: Inspect specification $P$, current state $\Sigma_t$, step counter, and metadata.
skill-state://sessions: List active sessions and lifecycle metrics.
skill_state_turn: Standard prompt rendering $(P, \Sigma_t, O_t)$ for tool-calling agents.
skill_state_paper_turn: Canonical single-line JSON format specified in arXiv:2608.26263 Appendix A.4.
SkillExecBench Environment 1)A reference implementation of the benchmark environment from §4.1:
500 independent shelves (shelf_0 through shelf_499).
Domain commands: Store <item> <shelf>, Ship <item> <shelf>, Move <item> <from> <to>, Wait, Complete.
Collision rejection: Storing onto an occupied shelf triggers an environment rejection and transactionally rolls back state mutations (Appendix B.1).
Background telemetry noise: Periodic sensor, battery, and robot telemetry injection to evaluate agent resilience against observation drift (Experiment 2).
Deterministic echo, no-op, synthetic failure, and custom completion actions for testing and integration.
Transactional Rollback: If candidate state $\Sigma_{cand} = \Sigma_t \oplus \Delta\Sigma_t$ fails schema validation or if the executor rejects $a_t$, the runtime rolls back to $\Sigma_t$ without advancing the turn counter (§3.1, §7).
Zero Leakage: Reasoning traces $R_t$ are consumed and dropped in memory; they are never logged, hashed, or returned in subsequent MCP turn payloads.
Concurrency Isolation: Per-session asynchronous mutexes guarantee that concurrent steps within a session are serialized while independent sessions execute concurrently.
Specification Immutability: $P$ is deep-frozen on initialization to prevent drift across long execution horizons.
# Clone repository
git clone https://github.com/Derzkiyboomchik/skill-state-mcp-server.git
cd skill-state-mcp-server
# Install dependencies
npm install
# Run 18 unit and integration tests
npm test
# Run end-to-end demo client (stdio & HTTP)
npm run demo
# Build TypeScript to dist/
npm run build@article{skillstate2026,
title = {SKILL.state: Formal State-Based Execution for Long-Horizon AI Agents},
journal = {arXiv preprint arXiv:2608.26263},
year = {2026}
}MIT © Derzkiyboomchik & bub0lehich
Housekeeping: permanently remove a skill session and its execution state from the runtime. Returns the final Σ snapshot for auditability before deletion.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Identifier of the session to remove from the runtime. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well: it states that removal is permanent, that execution state is deleted, and that a final snapshot is returned for auditability. This gives the agent the key safety and side-effect information before invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and consequence before mentioning the return value. Every phrase earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool with no annotations or output schema, the description covers the essential context: what is removed, that it is permanent, and what the caller receives. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the session_id parameter already documents itself as the identifier of the session to remove. The description adds no additional parameter-level semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair, 'permanently remove a skill session and its execution state,' and labels itself as housekeeping, making the teardown purpose unmistakable. It also distinguishes itself from siblings like initialize_skill and execute_step by focusing on session termination rather than setup or execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Housekeeping' framing clearly signals that this tool is for cleanup and session removal, which gives an agent the context to choose it when a session is no longer needed. It does not explicitly name exclusions or alternatives, but the lifecycle role is clear enough given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advance a skill session by exactly one step t → t+1. INPUT: reasoning_trace R_t (Chain-of-Thought — discarded by the runtime and never stored), state_update ΔΣ_t (sparse JSON patch; null deletes a key), action a_t, and the environment_observation O_t you consumed this turn. LOGIC: validate ΔΣ_t → apply Σ_{t+1} = Σ_t ⊕ ΔΣ_t (null-deletion semantics) → execute a_t → obtain observation O_{t+1}. OUTPUT: the strict next-turn tuple {skill_spec: P, current_state: Σ_{t+1}, latest_observation: O_{t+1}}. Nothing else is retained — no history, no reasoning, no old observations.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | a_t — the action to execute. A free-text command or a structured JSON action, e.g. {'type':'echo','message':'...'}, {'type':'fail','reason':'...'}, {'type':'complete','summary':'...'}. The mock executor produces O_{t+1}. | |
| session_id | Yes | Identifier of the active skill session to advance by one step. | |
| state_update | Yes | ΔΣ_t — sparse JSON patch to apply as Σ_{t+1} = Σ_t ⊕ ΔΣ_t. NULL-DELETION SEMANTICS: {'key': null} deletes 'key' from Σ; a value inserts/updates the key; nested objects merge recursively; arrays replace wholesale. Keys absent from ΔΣ_t are left untouched. | |
| reasoning_trace | Yes | R_t — your free-form Chain-of-Thought for this step. WARNING: the runtime DISCARDS this field entirely. It is never stored, logged, hashed or replayed. Write reasoning here instead of polluting Σ. | |
| environment_observation | Yes | O_t — the latest observation you (the model) consumed this turn, i.e. the 'latest_observation' from the previous tool response. The runtime uses it for context-drift detection, then discards it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it delivers: it discloses that reasoning_trace is discarded and never stored, logged, hashed, or replayed, that old observations are not retained, and that state updates use null-deletion merge semantics. These are precisely the non-obvious runtime behaviors an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is densely informative yet well structured with INPUT, LOGIC, and OUTPUT sections, and the first sentence states the core purpose immediately. Every sentence contributes either behavioral disclosure, parameter semantics, or execution order, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 5-parameter tool with no output schema, but the description fully specifies the input contract, the execution pipeline, and the exact next-turn return tuple. It also covers retention and discard behavior. Minor failure-mode details are absent, but nothing needed for correct selection and invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value beyond the schema. It explains that state_update is a sparse patch with null-deletion semantics, that reasoning_trace is a scratchpad that is discarded, and that environment_observation is the previous response's latest_observation used for context-drift detection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb-resource pair: 'Advance a skill session by exactly one step t → t+1.' It clearly defines this as the per-step execution tool and distinguishes it from the sibling session lifecycle tools by describing the strict next-turn output tuple.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context: it explicitly says this advances a session by exactly one step and consumes the current observation to produce the next one. It does not explicitly name sibling tools or state when not to use it, but the t → t+1 contract makes the intended usage unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new SKILL.state execution session. Stores the immutable skill specification P and the initial execution state Σ_0, then returns the initial prompt payload (P, Σ_0, boot observation). From this point on, the LLM must treat that payload as its ENTIRE context — there is no message history. Advances happen exclusively through execute_step.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Unique identifier for this skill session, e.g. 'triage-ticket-1042'. Must not collide with an existing active session. | |
| environment | No | Execution environment: 'mock' (default generic mock) or 'warehouse' (SkillExecBench Environment 1). | mock |
| state_schema | No | Optional domain schema for execution state Σ (arXiv:2608.26263 §3.1, §7). Can specify required keys (with expected primitive types like 'string', 'number', 'boolean', 'object', 'array') and disallowed unexpected keys. If Σ violates this schema, the step is rolled back. | |
| initial_state | No | Σ_0 — the starting structured execution state as a JSON object. Defaults to an empty object. This is the ONLY state the LLM will ever see. | |
| skill_specification | Yes | P — the IMMUTABLE procedural skill specification. A markdown instruction document or a structured JSON object. It is deep-frozen by the runtime and returned verbatim in every subsequent turn payload. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses the stateful side effect of creating a session, storage of immutable P and initial state Σ_0, the returned initial payload, and the lack of message history. This goes beyond the schema and materially changes how an agent should treat the tool's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence establishes the action and result, and the second provides the critical behavioral constraint that the agent must follow. Every sentence earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description covers the essential operational facts: what is created, what is stored, what is returned, and how the session should be advanced. The rich input schema handles parameter-level details, while the description supplies the workflow context an agent needs to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantic context by linking skill_specification to 'immutable skill specification P' and initial_state to Σ_0. It also emphasizes that this payload becomes the entire conversational context, which clarifies the significance of those parameters beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a new SKILL.state execution session.' It clearly explains the tool's role as the session initializer, distinct from subsequent advancement. It also names what the tool returns and what it stores, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating that after initialization the payload is the LLM's ENTIRE context and 'Advances happen exclusively through execute_step.' This explicitly routes subsequent behavior to a sibling tool. It does not discuss inject_observation, parse_turn_response, or close_session, but for initialization the key alternative is covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deliver an asynchronous environment observation / event alert into an active session (e.g. background alerts, customer orders, or external world drift per arXiv:2608.26263 §5.4). Does not advance the step count.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Identifier of the active skill session. | |
| observation | Yes | External environment observation / event alert to inject as the latest observation O_t (e.g. 'Customer ordered item_12', background alert, or external state drift per arXiv:2608.26263 §5.4). | |
| state_patch | No | Optional external state mutation to merge into Σ via ⊕ (e.g. when an external actor modified the world state). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the async nature and that the step count is not advanced, which is useful. However, it does not mention the potentially state-mutating state_patch behavior or any side effects beyond delivering the observation, leaving part of the behavioral profile to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: the primary purpose is front-loaded, followed by a high-value behavioral caveat. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately simple injection tool, the combination of description and schema covers the required parameters, the optional state_patch semantics, and the key behavioral distinction (no step count advance). Missing details like return values and error behavior are not critical for invoking the tool correctly, and no output schema exists to contradict this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters and their meanings. The tool description adds little beyond examples already present in the observation parameter's schema description, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Deliver an asynchronous environment observation / event alert'), a target ('active session'), and concrete examples. The caveat 'Does not advance the step count' distinguishes it from the step-advancing sibling execute_step, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool: asynchronous environment notifications, background alerts, customer orders, and external world drift. It implies a contrast with step-advancing tools via the 'does not advance the step count' statement, though it does not explicitly name alternative tools or list when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parses a raw LLM response string containing free-form reasoning and a fenced ```json block { 'state_patch': {...}, 'action': '...' } per arXiv:2608.26263 Appendix A.4. Separates the reasoning trace R_t (for discarding) from the structured payload, mitigating JSON syntax slips (arXiv:2608.26263 §5.7).
| Name | Required | Description | Default |
|---|---|---|---|
| response_text | Yes | Raw text response from the LLM containing free-form reasoning and a fenced ```json block conforming to Appendix A.4: { 'state_patch': {...}, 'action': '...' }. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and discloses key traits: the reasoning trace R_t is discarded, the structured payload is extracted, and JSON syntax slips are mitigated. It stops short of specifying failure behavior when a fenced JSON block is absent, but for a pure parse operation this is meaningful disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler: one states the input format and payload contract, the other states the output behavior and tolerance for JSON slips. The main verb and resource are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter pure function with no annotations and no output schema, the description provides the expected input format, the extraction logic, and the structured payload. Error-handling details and an explicit return shape are the only notable omissions, but the given specification is sufficient for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline applies; the schema already describes response_text as the raw LLM response. The description reinforces the expected fenced-JSON format and the state_patch/action shape in prose, but does not add parameter-level detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (parses), a specific resource (raw LLM response string with a fenced JSON block), and the expected payload shape ({'state_patch': {...}, 'action': '...'}). It also clarifies that reasoning is separated for discarding, which makes the tool's role distinct from the execution-oriented sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this tool when you have a raw LLM response containing free-form reasoning and a fenced JSON block. However, it does not explicitly state when not to use it or mention alternative tools, so the trigger condition is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1close_sessionexecute_stepinitialize_skillinject_observationparse_turn_responseScored across 5 tools
Each tool addresses a distinct lifecycle operation—create, step, async inject, parse, and close—so boundaries are mostly clear. The only mild ambiguity is between execute_step and parse_turn_response since both involve state patches and actions, though their roles are explicitly separated as advancing versus preprocessing.
All tool names follow a consistent verb_noun snake_case pattern: execute_step, inject_observation, parse_turn_response, close_session, and initialize_skill. This makes the tool set predictable and easy to navigate.
Five tools cover the core session lifecycle without redundancy: initialization, step execution, async observation injection, response parsing, and cleanup. This is a well-scoped count for a focused runtime server.
The lifecycle tools cover create, advance, inject, parse, and close, with no dead ends in normal operation. A minor gap is the lack of a lightweight session introspection or listing tool, forcing agents to infer current state solely from the last execute_step output.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Event-sourced world model for multi-LLM agents: propose, validate, and read a shared state.
Durable agent-to-agent handoffs and shared scratchpad for multi-agent workflows.
Verified memory for AI agents. Signed assertions, billing attestation, session continuity.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.