The useful boundary is not one universal agent stack. It is a division of authority that lets intelligence, sessions, processes, and providers change without forcing another layer to invent what happened.
- Model output alone did not commit repository or process state.
- Host and Runtime experiments required different durable identities and recovery rules.
- Separating cognition, task continuity, and physical execution.
- Treating completed work as admitted evidence rather than final model text.
- One mandatory implementation for every provider or workload.
- The private internal architecture of OpenAI, Anthropic, Google, or Microsoft systems.
A model does not act
A language model receives an encoded Context and produces another representation: tokens, structured fields, or a Tool request. Even when the output says run_tests, no process has started. Even when it says deployment complete, no deployment has been verified. Intelligence has proposed a continuation; another system must decide what the proposal means and whether anything should happen.
The distance from a token to completed work is not one API call. It is a stack of distinct loops, authorities, and evidence boundaries.
Modern products often package that stack under one name. Codex, Claude Code, an IDE Agent, or a managed Agent platform may combine a user Surface, Session hosting, an Agent Loop, Tool adapters, sandboxing, memory, evaluation, and deployment. The package is useful. The logical separation still matters whenever work must survive restart, model replacement, ambiguous execution, or a false claim of completion.
Four loops run at different timescales
Model serving encodes Context, computes a distribution, decodes output, and stops.
A Harness invokes the model, interprets Tool requests, returns observations, and decides whether the Run continues.
Host assigns ready work, retains evidence, rejects stale execution, and decides whether the Task continues or completes.
Participants, applications, and authoritative Worlds determine whether actual outcomes still serve the Goal.
Confusing these loops produces predictable errors. A Provider Session becomes the Task database. A successful process becomes proof of completion. A final assistant message becomes an Artifact. A retry after a lost response duplicates an external Effect. Or a workflow engine is rebuilt because a transcript did not preserve application state.
The complete call chain
The full path begins before a prompt and ends after a verified change in the world.
- Participant and world: a real preference, repository, service, deadline, budget, person, or institution creates the need for work.
- Surface: chat, CLI, IDE, Web, mobile, voice, or API captures input and renders progress, approvals, Artifacts, and outcomes.
- Interaction hosting: identity, authentication, conversation transport, uploads, streaming, and notifications are maintained.
- Goal interpretation: intent becomes an objective, constraints, risks, preferences, and success conditions.
- Workload Contract: source revision, allowed operations, required Artifacts, acceptance criteria, Effect boundaries, budget, and dependencies become explicit.
- Task graph: Host represents ready, blocked, branching, waiting, replacement, and verification work.
- Task Attempt and Assignment: one current Harness receives versioned authority, exact Context, Tool catalog, source binding, prior Artifacts, and budget.
- Semantic Context compilation: Host selects the smallest current set of durable facts that the Run needs.
- Harness input compilation: the selected Harness turns those facts into model-specific messages, Tool schemas, and Provider options.
- Model Adapter and serving: a raw API or local inference service performs one model call and returns content, Tool requests, usage, stop reason, or error.
- Protocol interpretation: Harness distinguishes a message, Tool request, need for input, refusal, truncation, or candidate final result.
- Capability and authorization: requested Tools are checked against Assignment scope, arguments, authority, budget, consequence, and approval requirements.
- Tool Bridge: a semantic Tool request becomes an Ordivon Runtime request or an explicitly external provider call.
- Runtime and world: Workspace, Job, process, file, network, service, or other real state changes—or fails to change.
- Observation and Artifact capture: stdout, stderr, exit code, diff, receipt, content digest, external Effect, and terminal evidence are retained.
- Run-local Context update: Harness returns a bounded observation to the model and continues the Agent Loop.
- Run stop: the Harness ends as candidate-completed, waiting, interrupted, exhausted, invalid, or failed.
- Run evidence: Assignment, Harness, model, Session evidence, Context, Tools, Runtime Jobs, Artifacts, usage, and stop reason become a receipt.
- CompletionProposal: Harness may claim that acceptance appears satisfied, but cannot commit the Task outcome.
- Verification: deterministic tests, static checks, simulation, an independent evaluator, or a human inspects authoritative state.
- CompletionDecision: Host checks current Assignment generation, required Artifacts, unresolved Effects, and acceptance evidence.
- TaskOutcome and graph advancement: accepted work closes or revises graph nodes and changes the Ready Frontier.
- Participant feedback: the result returns to the user or institution, becoming input to the next Goal loop.
Five kinds of memory are not one memory
Anthropic's long-running Agent work makes this distinction concrete. Later contexts do better when earlier work leaves explicit files, progress state, tests, and structured handoffs. Compaction can help a Session continue, but it does not replace an authoritative project state. OpenAI's Codex architecture likewise separates the model from the Harness that coordinates user input and Tools, while App Server lets multiple Surfaces consume the same Agent system.
Where Ordivon draws the boundary
Goal, Task, Attempt, Assignment generation, semantic Context, replacement, acceptance, completion, and recovery.
Raw model calls, Run-local Context, Tool Loop, budgets, interruption, stop classification, and Run evidence.
Codex, Hermes, Claude, or another mature Harness keeps its native Session and lifecycle.
Workspace, Job, Attempt, process tree, output, Artifact, cancellation, and reconciliation.
The two Harness paths are peers. Host may assign work to Ordivon Harness when only a model API exists, or to a mature external Harness when its provider-specific Loop is already stronger. They share durable input and evidence output; they do not need the same internal event model.
What top labs are actually building
OpenAI builds a Provider Harness optimized jointly with Codex models and reused across CLI, IDE, Web, and App. Anthropic builds Claude Code and Agent SDK capabilities while also publishing workload-specific structures for long-running development. Microsoft separates model clients, Agents, a batteries-included Harness, explicit Workflows, and Hosting. Google exposes an Agent framework plus managed Runtime, Sessions, memory, evaluation, observability, and graph workflows.
These systems do not prove one universal decomposition. They prove that the responsibilities exist. Each company packages them according to its product, platform, model, and customer goals. Ordivon uses failure ownership to keep the permanent core smaller.
Product boundaries can vary. Authority boundaries cannot remain ambiguous when work must survive replacement.
The result is a graph, not a chat
A real trajectory links Goal, Task, Attempt, Assignment, Harness Run, model call, Tool Call, Runtime Job, Artifact or Effect, CompletionProposal, Decision, and Outcome. The model/Tool interaction contains a loop, but the durable provenance becomes an append-only evidence graph.
Goal → Task → Attempt → Assignment → Harness Run
↘ model call → Tool Call → Runtime Job → Artifact
↖ observation ─────────────┘
Harness Run → CompletionProposal → CompletionDecision → TaskOutcome → next Task
This graph is why Ordivon is not merely a prompt wrapper. It preserves enough identity to answer which intelligence acted, under which authority, against which source, through which process, with which evidence, and why the Task advanced.
What remains open
The broad stack is now understood. The next question is empirical and deliberately smaller: how little code can implement Ordivon Harness for a bare model API while reusing Host and Runtime?
Version zero will not begin with compaction, persistent Sessions, parallel Tools, subagents, model routing, Skills, Plugins, or another database. It must first show one bounded multi-turn Tool Loop, one independently verified Artifact, explicit interruption and budget stops, and a measurable advantage over a one-shot call.
The model is the source of intelligence. It is not the owner of work, execution history, or truth.
Sources
Primary architecture and Ordivon evidence
- OpenAI. Unrolling the Codex agent loop and Unlocking the Codex harness.
- Anthropic. Effective harnesses for long-running agents and Harness design for long-running application development.
- Microsoft. Agent Framework overview and Agent Harnesses.
- Google Cloud. Vertex AI Agent Engine overview.
- Ordivon Computing. From Model Tokens to Durable Work.