Skip to main content

ARCH-23 native runtime and governed CLI tools

ARCH-23 supersedes ARCH-22 governed gateway over external harnesses as Tyrum's forward execution architecture. ARCH-22 remains available as decision history.

Quick orientation​

Decision snapshot​

Tyrum's native runtime is the only conversation-turn executor. Specialist agents are ordinary CLI child processes invoked through a future generic governed process capability, not alternate turn executors.

Decision​

  • The native Tyrum runtime is the sole executor for every conversation turn. Direct, queued, scheduled, WorkBoard, delegated, and operator-streamed work all use the same native path.
  • There is no per-conversation alternate executor, vendor adapter registry, or vendor-owned continuity mechanism. Tyrum continues to own conversation state, transcript, memory, context and compaction, tools, policy and approvals, audit evidence, scheduling, WorkBoard, and delegation.
  • Claude Code, Codex, OpenCode, and future specialist agents will run as ordinary CLI child processes through one generic process capability. They are tools used by the native runtime, not peers that replace it.
  • Vendor invocation knowledge belongs in skills and configuration: executable selection, arguments, prompts, expected artifacts, and vendor-specific operating guidance must not become core runtime branches or vendor-specific tool IDs.
  • The future governed process capability must enforce policy plus boundaries the child process cannot rewrite. Its target boundaries cover filesystem access, environment and credential exposure, network access, resource limits, cancellation, and retained evidence; see Not yet implemented for the current gaps.
  • Commit, push, pull-request, release, and deploy actions remain separate governed operations. Invoking a specialist program does not implicitly authorize any of them.

Why ARCH-22 was reversed​

The ARCH-22 implementation proved that replacing the native runtime would discard working behavior rather than merely swap a model loop. Tyrum's native path already integrates durable turns, AI SDK v7 provider behavior, memory, context and compaction, tool policy, approvals, audit, scheduling, WorkBoard, and delegation. Re-creating those guarantees around vendor callbacks added a second execution architecture and a large translation surface.

Specialist coding programs are still valuable, but the durable architectural need is narrower: invoke them when their expertise is useful while keeping Tyrum's existing runtime and governance in control. A generic governed process boundary provides that composition model without making vendor lifecycle or event protocols part of Tyrum's core.

Non-negotiable rules​

  • Every conversation turn executes through the native runtime. Do not add an alternate executor selector or a vendor-specific turn path.
  • Add one generic argv-based process capability before adding specialist integrations. Do not add vendor-specific process tools to core runtime code.
  • Keep vendor invocation knowledge in skills or configuration. Core code may define generic process policy and evidence contracts only.
  • Treat capability posture as policy configuration. Adapter code, skills, and child programs cannot grant themselves access.
  • The target process capability must enforce filesystem, environment and credentials, network, resources, and cancellation at OS, container, or node boundaries appropriate to the execution location. These guarantees are future requirements, not current claims; see Not yet implemented.
  • Capture bounded, attributable evidence from child processes without treating their local files as authoritative conversation history.
  • Keep source-control publication and operational promotion actions separate from process invocation and separately subject to policy and approval.
  • Do not describe the current shell-form bash tool as the hardened process contract.

Not yet implemented​

The specialist-CLI target is normative, but the production-grade process capability does not exist yet. Current native execution remains supported; the following capability gaps must be closed before Tyrum claims governed long-running specialist execution:

  • a hardened generic argv-based runner
  • explicit environment and credential projection
  • filesystem confinement
  • network confinement
  • descendant-process cancellation
  • CPU, memory, duration, and output resource bounds
  • streaming and background-process behavior
  • local and node execution conformance coverage

Until those pieces land, do not add Claude Code, Codex, or OpenCode skills that imply stronger isolation or governance than Tyrum actually provides.

Consequences​

  • The alternate-backend port, per-conversation override, vendor SDK adapters, vendor process state, and backend command are removed.
  • The seam audit found HarnessUiMessageStream to be vendor-adapter coupling; removing it required no native runtime primitive to move or replace.
  • Historical schema additions remain ordered migration history; a later migration retires only obsolete adapter-selection and vendor process-cache tables. Conversation and transcript data remain authoritative and are preserved.
  • Existing native AI SDK v7 behavior and all native model, memory, context, tool, approval, audit, scheduling, WorkBoard, and delegation paths remain the compatibility baseline.
  • The old runtime-extraction plan is not reactivated. Existing package-boundary rules remain enforced until deliberately reevaluated under ARCH-23; old extraction milestones are historical inputs, not an active roadmap.
  • Follow-up work should design and test the generic process capability before adding specialist skills or vendor configuration.