Integrating External AI Runtimes Without Losing Control

External AI runtimes are useful because they do the actual execution work. They are also easy to over-trust.

That is the core runtime-boundary problem Matic is solving. The runtime should be able to act, but it should not become the source of truth. Matic keeps control by deciding what the work is, preparing the environment, recording the session, and normalizing the output back into durable state.

Delegation is not surrender

An external runtime is a worker, not the authority.

Matic delegates execution, tool use, and runtime-native behavior to the runtime. It does not delegate the work definition, lifecycle state, artifact ownership, or review flow. Those stay in Matic.

That distinction matters because execution can be outsourced without outsourcing ownership. The runtime can do the work, but Matic still decides what counts as the work and where the result lives.

Preparation creates a bounded contract

Before execution starts, Matic prepares the workspace.

In this scope, that means generating files such as AGENTS.md, TASK.md, CONTEXT.md, and MEMORY.md. Those files are not decorative. They define the runtime handoff in a form that can be read, inspected, and committed.

The point of preparation is to give the runtime enough context to act without giving up the coordination layer. The runtime gets a bounded workspace. Matic keeps the durable record of why the work exists and what happened to it.

The Adapter keeps the boundary consistent

Different runtimes expose different interfaces. Some have different context limits, different tool semantics, and different output conventions. Matic should not leak those differences into the rest of the system.

The Adapter is the normalization layer.

It makes the runtime boundary consistent enough that Matic can prepare work, invoke execution, and collect results without rewriting the org model every time the runtime changes. That also makes the boundary easier to test because the contract is explicit instead of implied.

Artifact collection is part of control

Execution is not finished when the runtime returns output.

Matic still needs to collect artifacts, normalize them, and write them back into durable state. That is what preserves legibility after the runtime session ends. Generated files remain inspectable. The runtime session remains a record. The org does not lose the work when the process exits.

This is where control really shows up. The runtime may have produced the files, but Matic owns the durable record of those files.

What Matic retains

Matic retains the work definition. Matic retains the session record. Matic retains lifecycle state. Matic retains artifact ownership. Matic retains review flow.

That list is the boundary. Everything else can vary by runtime.

If a future runtime changes its interface, Matic should still be able to prepare the workspace, capture normalized artifacts, and keep the org state coherent. A runtime switch should not force a redesign of memory, identity, or coordination.

Why this stays filesystem-first

The workspace is not an abstract concept in this model. It is a directory tree.

That means the handoff is readable in files, the result is collected as files, and the durable state is preserved in files. The filesystem stays the primary operational surface, which keeps the runtime boundary legible instead of hidden inside a service call.

The practical outcome

The goal is not to make runtime integration feel invisible. The goal is to make it controlled.

Matic prepares the workspace. The runtime executes inside the boundary. Matic collects the output. The org keeps the durable truth.

That is the difference between integration and dependence.