When the Agent Has to Finish
OpenHuman’s execution problem begins where a good answer stops being enough. The question is not simply how a model generates text, but how an agent uses memory, calls tools, delegates work, pauses, and returns a trustworthy result when the path is long or interrupted. This chapter distinguishes a single model call from an OpenHuman agent run, then follows the run through its limits, checkpoints, specialist workers, failure handback, and operational records.
A turn is a lifecycle, not a request
A model call has a relatively narrow contract: provide messages and tool definitions, receive text or structured tool calls, and account for the response. An agent turn has to own what happens before and after that call. OpenHuman’s live turn path resumes the conversation history, builds the prompt and tool surface, injects relevant memory, enters a bounded tool loop, manages context, checks stop policy, and emits progress before it finally produces an answer.
That distinction matters because the model does not own all of the state. The session owns the history. The memory loader supplies selected context. The tool registry defines what the model may attempt. Policy middleware can reject or pause a call before execution. The harness decides whether a tool result returns the run to another model iteration, whether the context must be compacted, or whether the run must stop. The model remains central, but it is one participant in a stateful control loop.
The normal lifecycle is easy to describe and difficult to make reliable. OpenHuman first needs a coherent prompt and a stable set of tools. It then sends a provider request. If the response contains no tool call, the turn can complete. If it contains one or more calls, the harness dispatches them, appends their results, and asks the model what to do next. Each iteration can consume more tokens, add more context, trigger a side effect, or encounter a failure. The turn therefore needs limits at every transition.
The memory chapter’s distinction between summary and evidence reappears here. A turn may begin with compact recalled context and then fetch a more precise item through a tool. The harness must preserve enough history for the model to reason about what it has already learned without allowing tool output to grow without bound. Context management is not a cosmetic optimization. It determines which parts of the run remain visible when the task becomes long.
The prompt itself is also state. OpenHuman’s harness documentation emphasizes a stable system prompt and tool surface across turns because changing that prefix can invalidate provider-side caching and force the system to rebuild context. At the same time, capabilities can genuinely change when an integration is connected or revoked, so the tool catalogue must be reconciled when the model’s available actions change. This is a useful example of the engineering balance: preserve stable state when stability saves cost, but do not preserve a false description of what the agent can do.
OpenHuman’s documentation describes context guards and compaction for this reason. Oversized results can be summarized or constrained before they enter the next model call; older history can be compacted while the system protects the prompt and recent turns. The exact strategy may change with the underlying harness, but the ownership principle is stable: the execution layer, not the model alone, decides how a finite context window is spent.
The inner loop has explicit stopping points
A useful agent cannot be allowed to continue merely because the model keeps producing another call. OpenHuman’s harness combines iteration limits, cost budgets, context controls, tool policies, and stop hooks. A stop hook can end a run between iterations when a budget or external policy says that continuing is no longer acceptable. A user-driven interruption and a policy-driven stop are different events, but both should leave a legible state instead of an unexplained disappearance.
The same logic applies to tools. A read operation, a network request, a file edit, and a delegated worker do not have the same risk or cost. The harness and surrounding policy layers classify and constrain them before or during dispatch. If a tool result is too large, the system can compress it or route it through a summarization path. If a call is blocked, the model should receive a meaningful policy result rather than a silent absence. If a run reaches its model-call cap, OpenHuman’s chat path is designed to pause gracefully and preserve a resumable checkpoint rather than treating the cap as an ordinary successful answer.
This creates a more honest definition of completion. “The model returned text” is not always the same as “the task finished.” A task may have produced a final response after a read-only investigation, or it may have stopped after a tool failure, an approval wait, or a budget boundary. The harness needs to preserve those distinctions so the user can tell whether they received an answer, a partial result, a request for clarification, or a blocker.
The important state is not only Completed. A paused run can be healthy if it is waiting for a decision. An incomplete run can be more trustworthy than a polished but fabricated success if it names the root cause and preserves what was done. The state transitions make those differences visible to both the interface and the next turn.
Delegation adds structure, not just parallelism
OpenHuman extends the same execution model when the main agent delegates. The documented live architecture uses graph primitives for multi-stage delegation, phase-based work, and parallel fan-out. A delegation can follow a plan, execute it, review the result, revise when necessary, and finalize a response. Each stage is still an agent task, but the outer graph preserves the relationship between the stages and the accumulated state.
That structure solves several problems at once. A researcher can work with a narrower tool surface than the main orchestrator. A coding worker does not need every integration action. A fast worker can handle a low-context task while a stronger model is reserved for planning or review. Separating histories also keeps the parent from inheriting every intermediate thought and tool payload. The parent receives a result or an artifact path rather than an uncontrolled transcript. That handoff is an information boundary. A worker may inspect many files or call several tools, but the parent should receive the conclusion, the relevant evidence, and a way to recover the full artifact when necessary. Otherwise delegation would merely multiply the context problem: the main agent would inherit every child’s intermediate output and lose the very focus that delegation was meant to create.
Parallelism is therefore a systems decision, not an instruction to “spawn more agents.” OpenHuman’s design bounds the hierarchy and limits who may delegate further. It can reuse compatible workers instead of creating a new one for every follow-up, and it can fan work out only where the parent can still combine the results. These constraints protect context and cost as much as they improve latency.
A worker’s relationship to the shared workspace matters too. Two specialists editing the same artifact can conflict even if their prompts are independent. The orchestration layer therefore needs to reason about isolation, worktrees, shared claims, and the point at which results are merged. The reader does not need the repository’s implementation vocabulary to see the principle: parallel work is safe only when ownership of state and the merge point are explicit.
Failure becomes a result the user can act on
Long-running agents fail in recognizable ways. A tool can return the same error repeatedly. A provider can time out. A child can ask a question the parent cannot answer. A task can exceed its iteration, context, or cost budget. Treating all of these as generic “agent error” messages hides the difference between a transient problem, a user decision, and a permanently blocked action.
OpenHuman documents a no-progress circuit breaker for repeated tool failures. Identical calls can trigger a corrective nudge, then a halt if the run is still not advancing. A policy block is not handled like a temporary network problem, because retrying an action that the current policy forbids cannot produce progress. Conversely, recoverable transport failures may receive different headroom before the system stops. The mechanism matters because the model’s ability to repeat a call is not evidence that repeating it is useful.
Sub-agent handback makes the same distinction at a larger scale. A child can complete, pause while awaiting user clarification, or return an incomplete result with a reason. The parent should not silently convert the third state into a finished answer, nor should it restart the same failed delegation without learning anything. An explicit blocker preserves the boundary between what the system accomplished and what still requires a human decision or a different strategy.
This is a different philosophy from hiding failure to preserve a smooth conversational surface. In an ordinary chat, an assistant may be rewarded for always saying something. In a durable agent system, a clear incomplete state can be more useful: it tells the user where the run stopped, prevents duplicate side effects, and creates a place to resume or change the plan.
Observability is part of the execution contract
The final answer is only one output of a long run. OpenHuman’s harness emits progress events so the interface can show streaming text, tool activity, sub-agent work, and iteration status. Durable journals and run records provide a later account of what happened, including background work that no user was watching live. Cost and token telemetry add another dimension: a user can understand not only whether a run completed, but what kind of resource commitment it required. This matters for background work in particular. A run launched by a channel, schedule, or delegated worker may finish when the user is not looking at the screen. If its only trace is a final message, the user cannot easily distinguish a deliberate action from a retry, a partial completion, or a policy stop. A journal and progress timeline turn the run into an inspectable event sequence.
Model routing and tool-output compression support this contract economically. Workload hints can send deep reasoning, fast classification, coding, vision, or summarization to different routes. TokenJuice can detect whether a tool result is JSON, code, a diff, a log, search output, HTML, or plain text and apply a specialized reduction. When a reduction is lossy, the documented CCR mechanism can retain the original behind a recovery marker. That makes the compact context a working view rather than a claim that discarded material never mattered.
The qualification is important. Compression acts on tool results, not automatically on the background memory-ingest pipeline. Savings depend on content and configuration, and the recovery cache is bounded. Likewise, internal resource profiles can show how a particular build behaves under a particular environment, but they do not prove universal scaling or reliability. Observability makes the system easier to evaluate; it does not manufacture evidence that the repository does not contain.
OpenHuman’s execution layer is therefore best understood as a controlled lifecycle. Memory supplies context, the harness decides how that context is used, tools and workers change the world or produce evidence, and policies determine when the loop must pause or stop. A run that finishes is valuable, but a run that stops honestly, preserves its state, and explains its blocker is also a successful outcome of the control system.
The next step is to extend this recoverable turn beyond a person’s immediate prompt. OpenHuman can receive external events and assemble repeated work into workflows, but it must first decide which events deserve attention and which actions require approval. That is where durable execution becomes visible automation.