Agent Harness Evolves from Loop to Semantic Task Runtime: Six Core Abstractions

Weekly Conclusion

No single model capability leap dominated agent progress this week. Instead, the most visible changes occurred in the harness layer: waiting, cancellation, persistence, permissions, tool results, session scope, progressive skill/MCP loading, sandbox profiles, memory services, and meta-harness capabilities were systematically filled in. The industry is steadily moving deterministic system behaviors—previously left to the LLM—down into the runtime.

One-Sentence Judgment

A good harness does not let the LLM manage more things; it takes away the things the LLM should not manage: waiting, scheduling, permissions, state, consistency, isolation, and recovery.

Six Technical Threads

1. Session / Lifecycle — Weekly signals: DeepSeek Harness shows wait, cancel, session-scoped cwd, persistence consistency issues. Core meaning: Session becomes a long-running execution state container, not just a message array. Importance: High.

2. Context / Progressive Disclosure — Weekly signals: MCP working group, CLI/Skill replacing full tool schemas, skill bundle optimization. Core meaning: Context shifts from a big prompt to an on-demand loaded working set. Importance: High.

3. Policy / Security — Weekly signals: Runtime policy, context privilege escalation, tool result transform. Core meaning: Prompt constraints are insufficient; permissions and trust boundaries move into runtime. Importance: High.

4. Sandbox / Execution — Weekly signals: GitHub runtime profiles: Docker, gVisor, VM. Core meaning: Sandbox upgrades from a binary switch to a schedulable security execution profile. Importance: Medium-High.

5. Memory / State — Weekly signals: ReMe, service-oriented memory, scope memory, MESA-style research. Core meaning: Memory evolves from vector retrieval to a scoped state system. Importance: Medium-High.

6. Meta-Harness — Weekly signals: Harness-of-Harness, meta-harness projects. Core meaning: Single-agent harness may become an execution kernel; a higher layer handles long-term control. Importance: Medium-High.

Key Architectural Shift

Four layers are separating: Agent Kernel (minimal agent loop), Harness (context, session, tool, policy, memory), Meta-Harness (multi-turn planning, evaluation, cross-harness orchestration), and Enterprise Runtime (identity, sandbox, quota, audit, multi-tenancy).

DeepSeek Harness: Valuable Problem Exposure

Critical Detail A: Subagent Lacks True Wait Semantics

Community discussion shows that when a parent agent serially depends on a subagent result, a runtime offering only spawn + list_agents/poll forces the parent to repeatedly ask “are you done?”—turning scheduler work into model turns and token consumption.

Correct runtime semantics:

spawn → suspend parent → wait(event/timeout) → resume parent

. wait must be a deterministic system call, not an LLM-generated “let me check again” natural language behavior.

Further needs: timeout, cancel propagation, child failure policy, join(any/all), resource release.

Architectural Implication: If we design a harness instruction set, WAIT / SUSPEND / RESUME / CANCEL should be first-class runtime primitives alongside LOAD / EXECUTE , not skills.

Critical Detail B: Cancellation Is a Lifecycle Transaction, Not abort()

Cross-platform cancellation leaves transcript/durable event inconsistencies. Stopping the execution thread does not mean state has been consistently written; once agents support checkpoint, resume, billing, audit, or parent-child relationships, this inconsistency amplifies.

Recommended lifecycle:

cancel_requested → executor_stopped → tool_cleanup → state_flushed → turn_aborted_persisted → parent_notified

.

“Stop execution” and “commit termination state” must be distinct; the latter requires a durable event.

Recovery should rebuild from durable events, not in-process boolean flags.

Critical Detail C: Session Scope Becomes the Key Multi-Tenant Abstraction

When a shared harness process serves multiple users, cwd, skill, MCP, credential, memory, quota, and sandbox cannot default to process/global. The community’s request for session-scoped cwd is just the first exposed facet.

Introduce a unified Execution Scope : tenant / user / session / agent / subagent / sandbox are scope levels or attributes.

All resource mounting resolves via resolve(resource, scope, identity, policy).

Avoid each subsystem inventing its own workspace_id / session_id / sandbox_id and then doing fragile mappings.

Critical Detail D: Multi-Agent Needs a Reasoning Scheduler, Not Per-Agent Retries

When multiple subagents call models concurrently, 429 errors, concurrency limits, model-level quota, and tenant quota become systemic. Independent retries based on retry-after cause retry storms and quota unfairness.

Need a unified model scheduler: global quota + per-model + per-tenant + priority + concurrency + retry-after.

Model calls should be scheduled like shared accelerator resources, not ordinary HTTP clients.

Critical Detail E: Runtime Policy Starts Separating from Prompts

Community policy plugins enforce controls at tool gate, project policy, and behavioral observation boundaries. System prompt “do not do X” is a soft constraint; real policy must adjudicate and block before execution.

Maturity Assessment: DeepSeek Harness currently serves as an architecture testbed—advanced concepts, fast iteration, but issue density and release-candidate churn indicate it suits research, secondary development, and design validation, not yet as a stable enterprise runtime dependency.

OpenClaw 2026.9.1: From Personal Agent to Multi-User Runtime

OpenClaw 2026.9.1 focuses not on a single feature but on the gradual formation of a runtime system around skills, approvals, cwd/worktree, memory, and update/rollback.

Personal Skill Library: skills gain identity scope, not just workspace scope.

Approval persistence: Allow Always binds to session posture, showing permissions acquiring persistent state and scope.

Independent cwd + worktree root: managing many checkouts makes the file execution space a runtime resource.

Memory recall outcome returned to model: runtime not only queries memory but feeds back whether retrieval results are valid.

Update failure handled by a triage agent with rollback support: agents begin maintaining their own runtime.

Re-check Needed: OpenClaw’s “extensible runtime” and “enterprise multi-tenant runtime” are still different. It embodies the right direction for scope, approval, workspace, but enterprise deployment requires additional verification of resource isolation, credential hosting, audit, quota, and high availability.

OpenAI Codex: Tool Result Becomes a Harness Governance Object

Codex now allows MCP tool results to be transformed before entering the model context, while authorization state, sandbox policy, and MCP discovery timing continue to tighten. The trend: tool runtime security chain extends beyond “is the call allowed?” to “can the result enter context as-is?”.

Full chain:

discover → select → authorize → execute → sanitize/transform result → inject context → audit

.

Tool results may bring prompt injection, sensitive data leakage, error state propagation; they must carry source, trust, scope, lifetime.

“Tool call control” and “context injection control” should be two distinct policy hooks.

Extended Judgment: Once persistent/long-running agents mature, Codex-style harnesses must further gain long-term state, event triggers, permission leases, resource lifecycles, and recovery capabilities. Long-term agents will push harnesses toward OS-like capabilities.

MCP / Skill: Progressive Disclosure Moves from Trick to Protocol Layer

Multiple signals converge: do not stuff all tool schemas, skill details, and MCP server capabilities into the model context at once. MCP community advances progressive disclosure; GitHub Agentic Workflows shift from full MCP schema to CLI/skill progressive discovery.

Traditional: connect server → enumerate all tools → put schemas in context.

Evolved: discover capability → retrieve metadata → choose relevant capability → load detailed schema → execute.

Further: skill description → skill detail → tool description → tool schema → data, forming multi-level loading.

Key Re-check: Progressive disclosure cannot rely solely on lazy=true . Runtime must be observable: why loaded, when loaded, cache hits, tokens loaded, whether actually used. Otherwise “nominally lazy, actually eager” easily occurs.

Six Technical Threads: From Phenomena to Architecture

3.1 Context: From Prompt to Virtual Working Set

Context evolves from “full chat history + all tool specs” to “small working set + external state + on-demand addressing”, resembling traditional OS virtual memory: model context is not the storage layer but a limited workspace.

Working Context: minimal set actually used for reasoning.

External State: history, objects, knowledge, artifacts, tool schemas stored outside context.

Semantic Addressing: model uses recall/load/discover instructions to fetch on demand.

Compaction is just one strategy; better to keep full external state and shrink the working set.

3.2 Context Security: Context Itself Becomes a Permission System

Research on Context Privilege Escalation reveals an important security fact: agent security boundaries lie not only in tool permissions but in context assembly. Low-trust sources promoted to high-priority messages, long-term memory, or system notes during assembly equate to privilege escalation.

Every context object should carry: source, trust_level, scope, lifetime, owner, promotion_rule.

Writing to memory/summary/system note is a “trust promotion operation” requiring policy.

Cross-project, cross-user, cross-session propagation needs explicit authorization to avoid X-CPE class issues.

Suggested Abstraction: Do not treat context as a string array; treat it as a set of objects with metadata and access control. The prompt is merely one rendering of these objects.

3.3 Memory: From Vector Database to Scoped Persistent State System

ReMe, service-oriented memory, scope memory, and multi-structure memory research point to a common direction: memory ≠ embedding + top-k. A real harness memory must handle capture, structure, retrieve, update, forget, scope, lifetime, sharing.

Memory retrieval should first choose memory structure, then retrieve objects: episodic / task state / tool history / knowledge / artifact / relation.

Enterprise scenarios should move from local SQLite to server-side, multi-tenant, permissioned memory services.

Memory is a logical layer; underlying storage can combine relational DB, object storage, vector index, graph index—upper harness must not bind to a specific database.

3.4 Sandbox: From sudo/network Switch to Execution Security Profile

GitHub Agentic Workflows’ runtime profile places docker, gVisor, VM, etc., into a unified selection. This is closer to production design than a simple boolean switch: harness declares required security profile; platform chooses underlying runtime.

Profile dimensions: kernel isolation, network policy, filesystem persistence, privilege, startup latency, cost.

Tasks can dynamically choose profile: read-only analysis, normal code, network tasks, need root, handle untrusted input.

Upper agent need not know if underlying is container, E2B, function, or VM; only a unified execution contract.

3.5 Multi-Agent: Real Hardness Is Scheduling, Waiting, State—Not Just Spawning More Agents

Multi-agent engineering difficulties appeared concretely this week: waiting, cancel propagation, concurrency budgets, model quotas, parent-child state, failure recovery. “Planner + N workers” is only the surface; underneath a scheduler is needed.

First-class primitives: spawn / wait / join / cancel / suspend / resume / timeout.

Resource scheduling: model quota, sandbox slots, token budget, wall-clock budget.

State relationships: parent-child, dependency, result ownership, checkpoint.

3.6 Meta-Harness: A Control Layer Growing Above Harness

Harness-of-Harness work validates an important direction: without changing the model or the underlying harness, a higher layer of planning, testing, evaluation, and iterative control can significantly improve long-task performance.

Agent Kernel: minimal loop + tool call.

Harness: manages context / session / tool / memory / policy / sandbox.

Meta-Harness: manages long-term plans, cross-harness scheduling, independent evaluation, versioned iteration.

Enterprise Agent Runtime: adds identity / multi-tenant / audit / quota / HA / cost.

Proposed Harness Layered Model

Combining this week’s signals, a more stable architecture is not “one giant agent framework” but a clear separation of deterministic system capabilities from semantic decisions.

L5 Enterprise Agent Platform : Identity · Tenant · Audit · Quota · Cost · HA · Governance

L4 Meta-Harness / Orchestrator : Planning · Evaluation · Scheduling · Long-horizon control · Cross-harness

L3 Agent Harness Runtime : Context · Session · Skill/Tool · Memory · Policy · Lifecycle · Sandbox

L2 Agent Kernel : Agent Loop · Message/Step State · Tool invocation · Events

L1 Model / Inference : LLM · Reasoning · Embedding · Model routing

Layering Principle: LLM handles only “uncertain semantic decisions”; runtime handles “deterministic system semantics”. The more a problem involves wait, retry, quota, permission, persistence, isolation, recovery, the less it should be left to the model to coordinate via natural language.

Six First-Class Abstractions: The APIs We Should Stabilize

Scope — Problem solved: Who / in which scope executes. Typical objects: tenant, user, session, agent, subagent, workspace. Design focus: Root of all resource resolution.

Context — Problem solved: What is currently visible. Typical objects: object, source, trust, lifetime, priority. Design focus: Not string concatenation.

Capability — Problem solved: What can be invoked now. Typical objects: skill, tool, MCP, API, command. Design focus: Support discovery and progressive loading.

State — Problem solved: What is remembered now. Typical objects: session state, memory, artifact, checkpoint. Design focus: Support persistence and recovery.

Execution — Problem solved: Where and with what permissions to run. Typical objects: sandbox profile, cwd, network, FS, runtime. Design focus: Unify container/VM/function/E2B.

Policy — Problem solved: What actions are allowed. Typical objects: tool gate, data policy, context promotion, approval. Design focus: Must be hard constraints.

Critical Re-check: Confirmed Trends vs. Still Watching

Confirmed Trend: Progressive Disclosure — Why: Driven by multiple implementations, protocol discussions, and context cost issues; not a single project’s偶然 choice. Action: Enter base design.

Confirmed Trend: Session / Lifecycle Runtime-ization — Why: Wait, cancel, resume, cwd scope issues inevitably appear in long tasks and multi-tenant scenarios. Action: Make first-class abstractions.

Confirmed Trend: Policy Moving from Prompt to Runtime — Why: Security, approval, tool result, context promotion all demand hard boundaries. Action: Indispensable for enterprise scenarios.

High-Probability Trend: Memory Service-ization, Scope-ization — Why: Personal agents can localize, but enterprise shared runtimes force multi-tenancy and permissions. Action: Abstract interfaces first; storage implementations can evolve.

High-Probability Trend: Sandbox Profile — Why: Different risk tasks need different isolation costs; unified profile is more stable than exposing underlying tech directly. Action: Design at platform layer.

Watching: Meta-Harness — Why: Research and open-source signals clear, but product form not converged; whether it becomes a standard layer needs observation. Action: Keep composable, avoid over-binding.

Watching: Agent Package Standard — Why: Skill/Plugin/Agent bundles forming, but cross-harness standard not yet mature. Action: Monitor, avoid inventing complex standards prematurely.

Direct Implications for Building Agent Harness

7.1 Prioritize: Solidify System Primitives, Not Pile Agent Features

Define a stable scope model: tenant / user / session / agent / sandbox unified resolution.

Make WAIT / EVENT / CANCEL / CHECKPOINT / RESUME / TIMEOUT runtime primitives.

Context objectification: every context segment carries source / trust / scope / lifetime / owner.

Capability progressive disclosure: discover first, then load skill/tool schema, provide load tracing.

Policy engine: unified hooks at tool call, tool result, memory write, context promotion, sandbox request boundaries.

Execution profile: upper layer picks security/performance tier; lower layer maps to container, VM, function, E2B, etc.

Unified model scheduling layer: concurrency, quota, priority, retry-after, budget managed by runtime.

7.2 Avoid Prematurely: Don’t Over-Engineer for Conceptual Completeness

Don’t start by inventing a complex agent package standard; first ensure skill/tool/memory composability.

Don’t implement every memory type as a separate database; stabilize logical interfaces and scope first.

Don’t equate multi-agent with “spawning multiple model threads”; get waiting, state, scheduling, failure semantics right first.

Don’t use prompts to replace permission and security control; don’t let policy leak into every business tool implementation.

Don’t force a single grand meta-harness; first make lower harness observable, controllable, interruptible.

7.3 Correspondence with “Semantic Computer” Thinking

Industry signals show that the previously discussed “semantic heap / semantic stack / SkillList / semantic addressing” are not detached metaphors but are being implemented by various harnesses in their own ways. More accurate mapping:

Semantic Heap → External session state / memory / artifact / context object — Solves limited context vs. long-term state.

Semantic Stack → Parent-child agent / step / call stack / lifecycle — Solves intermediate calls, dependencies, recovery.

SkillList → Capability registry / skill / tool / MCP — Corresponds to discoverable, on-demand loadable capability set.

Semantic Addressing → recall / discover / load / inspect runtime — Fetch needed objects from external state by scope.

Instruction Set → load / execute / wait / cancel / write / link / checkpoint — Extract deterministic actions from natural language.

Further Correction: The “semantic computer” must avoid mechanically mapping every traditional computer concept. Real engineering value lies in grasping four fundamental constraints—limited context capacity, dynamic capability discovery, long-term state, non-deterministic execution—and introducing only the system abstractions that solve these constraints.

Final Conclusion

If you only read headlines, this week seemed to lack a “revolutionary new agent”. But from an engineering perspective, it was pivotal: multiple independent project lines are pulling waiting, state, permissions, context, memory, isolation, and recovery out of the agent loop and solidifying them into runtime.

This means the next phase of competition will not be “whose agent calls more tools”, but who can organize limited context, dynamic capabilities, long-term state, and controlled execution into a stable system.

Final Judgment: Agent harness is evolving from “a loop around the LLM” into a “semantic task runtime”. The real investment is not expanding prompts further, but building six stable abstractions—Scope, Context, Capability, State, Execution, Policy—and orchestrating them with lifecycle and scheduler primitives.