JIXU DOCUMENTATION
Coming next
Near-term capability areas, their intended boundaries, and what is not available yet.
Jixu is expanding around the same durable single-Agent model. The next capability areas are known, but they are not part of the current public API until their ordinary installation and execution paths ship.
Planned, not published
Everything on this page is directional. Do not import, configure, or depend on a capability marked Planned. No release number or delivery date is promised here.
Near-term capability areas
| Area | Status | Intended boundary |
|---|---|---|
| More model adapters | Planned | Additional providers and protocols behind the existing ModelDriver port. |
| MCP Tools | Planned | MCP capabilities adapted into ordinary Tool descriptors and Driver execution. |
| OS sandbox backends | Planned | Real process containment beyond the current dispatch permission layer. |
| Richer observation | Planned | More useful live inspection without turning traces or UI state into authority. |
| Deployment coordinators | Planned | Deployment integration around durable Threads, outside the core State machine. |
More model adapters
New first-party adapters will extend the provider-neutral model boundary. They must preserve explicit capability resolution, typed failures, redacted secrets, and visible durable requests. A provider conversation ID or native retry mechanism will not become a second Thread history.
Today, jixu-llm supports OpenAI-compatible Chat Completions and Anthropic Messages. See jixu-llm for the shipped protocol list.
MCP Tools
MCP capabilities will enter Jixu through the existing Tool and Driver contracts. Tool requests must still become durable before dispatch, pass the same permission boundary, and record typed outcomes through the Event log.
MCP will not add an independent runtime, conversation, or approval authority inside a Harness.
OS sandbox backends
The current permission layer can allow, ask, or deny dispatch. It does not contain a process after dispatch, and Bash currently runs with the permissions of the Jixu process.
Planned sandbox backends are intended to provide a real isolation boundary. Until one ships, treat the guidance in Tools and safety as the current contract.
Richer observation
Jixu will make active work, durable outcomes, and intervention boundaries easier to inspect. Observation remains non-authoritative: Signals are transient, traces are diagnostic, and State continues to derive only from ordered Events.
The interface will not invent hidden reasoning, completion percentages, or certainty that the runtime cannot prove.
Deployment coordinators
Deployment-oriented coordination can build around the public Harness and durable Thread path. It must remain an integration boundary rather than a second scheduler or source of truth inside Jixu core.
The exact package and API surface are not published yet.
What will not change
New capabilities must preserve the architecture that makes continuation explainable:
- one immutable Agent per Harness;
- one ordered Event log as the sole Thread authority;
- external work through
Event → Reducer → Effect → Driver → Event; - Replay without live Effects;
- explicit waiting at uncertain boundaries; and
- no Multi-Agent routing, supervisors, swarms, or Agent handoff inside one Harness.
For code you can use now, stay with the Packages catalogue and the Guarantees and boundaries page.