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
- Read this if: you are changing turn execution, process capabilities, specialist-agent integration, policy, or execution boundaries.
- Skip this if: you only need the conversation and turn vocabulary; use ARCH-20 conversation and turn clean-break decision.
- Go deeper: use ARCH-24 governed process capability, ARCH-25 process-family governance and truthful posture, Tools, Approvals, Work board and delegated execution, and Target-state package graph.
Decision snapshot
Tyrum's native runtime is the only conversation-turn executor. External programs are ordinary CLI child processes invoked through the generic governed process.run 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 governed process capability enforces tool exposure, policy and approvals, environment minimization, bounded output evidence, timeout, and best-effort process-group termination. ARCH-24 records the exact implementation and its non-confinement boundary.
- 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.
- Do not infer filesystem, network, CPU, memory, syscall, or daemon-escape confinement from
process.run; stronger guarantees require separate OS, container, or node boundaries. - 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
bashtool as the hardened process contract.
Implemented boundary and follow-up work
ARCH-24 delivers the local, direct-argv runner with exact exposure opt-in, policy and approval integration, minimal environment inheritance, bounded JSON evidence, secret redaction, runtime timeout, and hard settlement. ARCH-26 adds the durable background lifecycle, and ARCH-27 adds governed specialist CLI guidance as bundled skills without adding a vendor runtime branch. Strong filesystem, network, resource, daemon-escape, credential-projection, and node boundaries remain separate work.
Consequences
- The alternate-backend port, per-conversation override, vendor SDK adapters, vendor process state, and backend command are removed.
- The seam audit found
HarnessUiMessageStreamto 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 may build skills or configuration on the generic capability without adding vendor branches to the native runtime.
Related docs
- Architecture overview
- ARCH-20 conversation and turn clean-break decision
- ARCH-21 public tool taxonomy and exposure model
- ARCH-22 governed gateway over external harnesses
- ARCH-24 governed process capability
- ARCH-25 process-family governance and truthful posture
- ARCH-27 governed specialist CLI skills
- Tools
- Approvals
- Work board and delegated execution
- Target-state package graph