Filesystem-First Pivot: Codex Executes Filesystem State

This is the point where markdown state becomes live work.

The pivot stops being about storage alone and becomes about execution. Routines now compile markdown context into a Codex prompt, invoke Codex through an explicit boundary, move task folders through visible statuses, and publish results through channels without collapsing Matic into the Agent Runtime itself.

That boundary matters. Matic stays the coordination layer. Codex stays the executor. The filesystem stays the record.

Prompt compilation turns files into traceable context

The execution path should not start from hidden memory. It should start from files.

Prompt compilation gathers the relevant markdown context into a Codex prompt, including:

• agent files
• routine files
• workflow files
• stage files
• task files
• the task's Work Contract section

That assembled context is what makes the execution traceable. The runtime gets the files it needs, but the files remain readable after the run. This is the legibility rule applied to execution itself.

In this MVP slice, the task folder is the execution surrogate. The long-term ontology separates conceptual Tasks from executable Work Items, so this bridge should be treated as a bridge, not as the final model.

The Codex boundary should be explicit

The wrapper around Codex belongs behind a testable subprocess boundary.

That is not just an implementation preference. It is the way to keep execution honest. Matic should define what needs to run, assemble the context, and hand the work to Codex through a clear interface. It should not bury execution in ad hoc runtime code or hide model invocation inside state transitions.

An explicit boundary makes the system easier to reason about:

• inputs are visible
• execution is isolated
• outputs can be inspected
• failures can be handled deterministically

That is the right shape for a durable system.

Task movement must stay legible

Once execution starts, the task folder moves through visible states:

• pending
• running
• completed
• failed

Those state transitions should stay on disk. They are part of the operational record, not incidental UI state. If a task can be executed, it can also be inspected after the fact. That only works if the state machine remains visible.

The task folder should carry a clear Work Contract section so the execution boundary knows what it is responsible for. The contract is what keeps the system from treating "run the task" as a vague prompt instead of a bounded obligation.

result.md and history.md matter more than hidden logs

A durable execution system needs more than a console stream.

result.md records what was produced. history.md records how the work moved. Together they create a readable story of the execution without requiring someone to dig through runtime internals.

That is especially important once work becomes repeatable. A hidden log can explain a failure to a developer. A file-based result and history record can explain the work to the org.

Channels extend the filesystem contract

This work also pushes the filesystem-first model beyond routine execution.

Channels become first-class filesystem primitives, which means delivery is not just a side effect of execution. It is part of the system's inspectable surface. The first default outbound surface is Telegram, but the important point is architectural: delivery should not become a new system of record.

A channel can carry output. It should not become the durable primary database for that output.

That keeps Matic consistent:

• human-readable state stays in markdown
• machine-oriented structure stays justified, not default
• channels remain outbound primitives
• the filesystem remains the durable record

What this unlocks

This creates the foundation for the operational loop that comes later.

Once the system can compile files into a runtime prompt, execute the task through an explicit boundary, write back results and history, and publish through channels, it can support:

• future operational loops
• review flows
• additional outbound channels
• more explicit handoff behavior

The important thing is that none of that requires Matic to stop being filesystem-first.

Codex can execute the work. Matic can coordinate it. The files still own the truth.