From Prompt to Harness: The Complete Evolution of Enterprise‑Grade AI Agents

Prompt Engineering Phase

The initial system relied on a massive system prompt that bundled role definitions, business rules, and formatting requirements. Simple tasks (3‑5 steps) succeeded, but longer chains suffered from attention dilution, context overflow, and the "data搬运" problem where 70% of the context became noise.

Context Management Phase

A four‑layer defense was introduced to keep the context usable: L1 – Tool result compression (store large JSON in MySQL, replace with __refId). L2 – Semantic compression using a secondary LLM (temperature 0.3) to produce a __summary of up to 2000 characters. L3 – Conversation compaction that replaces the full transcript with a structured hand‑off document, targeting a 30% token budget. L4 – DataBus for on‑demand retrieval of compressed data, with explicit get_stored_data, outline, and context APIs.

Additional safeguards include a single‑representation rule (each upstream datum appears in only one form), a hard prompt‑budget pre‑check ( PROMPT_BUDGET_EXCEEDED), and a progressive degradation strategy that discards preview data before core content.

Harness Engineering Phase

The system moved from a single‑threaded ReAct loop to a PERO (Plan‑Execute‑Reflect‑Optimize) engine with checkpointed state, enabling fault‑tolerant execution and seamless resume after crashes. Parallel execution of independent steps is achieved via a parallel field and Promise.allSettled with a semaphore limiting concurrent LLM calls.

Key runtime components: parameterBindings – declarative data flow that eliminates the need for the model to copy data between steps. step_control – explicit step status (complete, need_info, skip) so the model can signal unfinished work. working_memory – a short‑term store where the model records insights that survive transcript compression.

Agent OS Architecture

The architecture is expressed as five layers:

L1 OpenClaw Execution Cluster – stateless slots managed by a control plane, with a Bridge Runtime on each node and a Gateway for authentication.

L2 Agent Runtime – PERO step engine, event‑sourced execution ledger, SSE event stream, and checkpoint‑based resume.

L3 Memory & Semantic Layer – three‑tier memory (State, Working Memory, Transcript) and a DataProductStore that provides semantic retrieval of artifacts.

L4 Cognitive Layer – sensor skills that ingest metric alerts, reasoner skills that combine statistical analysis with LLM interpretation, and an advisor that produces a small set of actionable options for human approval.

L5 Self‑Feedback & Governance – a closed‑loop that collects execution traces, evaluates outcomes, generates structured patches (policy, strategy, action‑chain), and promotes them through a state machine (draft → shadow → active → expired) with human review for policy changes.

This layered design turns the LLM from a fragile script runner into a reliable operating system component, providing deterministic data flow, fault‑tolerant execution, and continuous self‑improvement.

Key Insights

LLM performance degrades due to context noise, not model size; reducing noise yields larger gains than scaling up.

Context management must be multi‑layered; no single compression algorithm can handle both single‑call bursts and long‑running dialogues.

Action space should be curated and introduced gradually (progressive disclosure) to keep the model’s decision space tractable.

Defensive repair pipelines become technical debt; observable metrics enable timely retirement of obsolete guards.

Trust requires explicit human checkpoints (shadow, probation, active) rather than blind automation.

The roadmap continues toward a fully cognitive Agent OS where perception, reasoning, decision‑making, and self‑evolution are orchestrated across a cloud‑native execution fabric.