Skip to content

Agent 0 Toolchain IO

Lucas YourLastName edited this page Oct 31, 2026 · 3 revisions

Agent 0 and toolchain direct I/O

The selected .SYSTEMX or .SYSTEMXP scope has two local read-only routes for an operator, IDE, or harness: selected read-only project CLI commands and a bounded JSON-lines stdio session. Agent 0 still owns canonical task selection and acceptance. These routes expose saved pointers and advisory status; they do not create a worker, authenticate a provider, grant access, run a coding CLI, or sync a cloud Bot.

The tagged toolchain I/O protocol and service implementation define this beta.2 route.

Direct CLI and structured output

From the containing project directory, use the project-local launcher:

bash .SYSTEMX/SYSTEMX.sh root roster
bash .SYSTEMX/SYSTEMX.sh session-settings --compact
bash .SYSTEMX/SYSTEMX.sh onboard status --format json
bash .SYSTEMX/SYSTEMX.sh service status

The installed systemx package command routes these project commands through run --target PATH --offline -- COMMAND, or an explicit registered child through projects --target PATH -- COMMAND --project NAME. It does not accept direct systemx root roster or systemx onboard invocations. On Windows, the local command prefix is pwsh -File .SYSTEMX/SYSTEMX.ps1; the source's portable command availability does not certify native host integration.

root roster derives bounded role, BOT, AUTOBOT, CLI-channel, and access-decision references. session-settings --compact returns selected role status, a Rules file count/absent IDs, and an aggregate revision digest without individual file hashes or rule-file contents. onboard status --format json reports local Agent1 and roster state plus provider navigation. None checks the user's effective provider login or host ACLs. Select a child explicitly; outer records never become its task state. For an existing task, root packet --task REAL_TASK_ID reads a bounded selected-task context packet. root delta compares saved task mappings with recorded external observations; it does not contact a harness or BOT.

Bounded JSON-lines session

An IDE or CLI harness may start the selected Python runner with service start --stdio, own both standard pipes, and close input or send stop to end it. service status only reports available capability. No OS service, listener, daemon, scheduler, shell command, credential store, MCP server, or ACP endpoint is installed. The process inherits its caller's effective OS permissions and does not need elevation; start it as a normal user. Capability fields requiresElevation:false and hostPrivileges:"inherited-from-launcher" describe this boundary; the process does not measure or drop its effective OS privileges.

Each request is one UTF-8 JSON line containing exactly id and method:

{"id":"roster-1","method":"roster"}

For a valid framed request, each response has the matching ID, ok, and either result or a generic error. An invalid request can produce a generic error with id:null. The fixed method set is:

Method Local result
ping, capabilities, stop Process health, available methods/limits, or session end.
assess Agent1 warning-only All-In-One local assessment; no caller path or credential.
roster Selected-scope Agent 0 role/instance navigation; no worker start or external permission probe.
settings Compact session settings with Rules count, absent IDs, and aggregate revision digest; no individual hashes or raw Rules text.
onboard Default read-only Agent1/roster/provider navigation; no provider, dotenv path, or credential can be selected in the packet.

The protocol limits each request line to 16 KiB, each response to 512 KiB, and each session to 64 requests. EOF and stop end the process. The selected root or child is fixed when it starts. The protocol accepts no arbitrary method arguments, command, path, account, or secret field. Standard output is reserved for JSON lines; a client should treat any other output as a transport failure. A successful response is a local readback, not product, account, or device acceptance. Results can contain the selected local path, project names, and task metadata; review them before forwarding a packet to an external model or another account.

The versioned service protocol and versioned toolchain guide are the release authorities for invocation and limits. The Agent 0 roster and provider onboarding explain the values and external access boundary.

Host integration targets

The generic CLI/JSON-lines route can be wrapped by a host that deliberately starts the selected process and verifies its output. The public beta ships no native integration registration for the following hosts:

Host target Current .SYSTEMX boundary
VS Code An integrated terminal or extension-owned process may use the CLI/stdio contract; no VS Code extension or MCP server is installed by .SYSTEMX.
Codex app, CLI, or IDE A reviewed project-root AGENTS.md pointer is optional; Codex worker/tool access and any MCP or SDK bridge remain host-managed.
Cursor Its IDE or generic agent CLI needs manual identity and permission checks; no Cursor ACP/MCP bridge is registered.
Kiro CLI, desktop IDE, and web cloud sessions are distinct host surfaces; an offline Agent Beta reference cannot connect Kiro Web, and no Kiro ACP/MCP bridge is registered.
JetBrains AI Assistant A future host-owned process adapter could call the CLI/stdio protocol; no JetBrains ACP/MCP plugin is shipped or verified.

This JSON-lines protocol is not MCP or ACP. A future MCP/ACP adapter would need its own host registration, method translation, permissions, lifecycle, platform tests, and observed round-trip before any integration claim. Inspect the selected host's real account, project scope, data sharing, and process permissions before using it for a task. The task ledger and Access Matrix remain review records, not a substitute for those controls.

DOT SYSTEMX · User manual

1. Start here

2. Work and continuity

3. Setup and maintenance

4. Advanced reference

5. Project information

Repository · Use this template · MIT license

Clone this wiki locally