Pushing AVA to latest harness engineering frontier

I have been developing AVA for a long time. I went from a simple Re-act loop, to an OpenClaw harness.
Now I have completely rewritten AVA to include the latest harness engineering papers and push it to the frontier of AI multi-agent automation.
AVA is capable of identifying bottlenecks and better ways to operate, and proposing updates to its own code to improve itself.

The evolution arc

#

AVA did not start as a harness. It started as a tight Re-Act (Reasoning and acting) loop: user message in, model response out, maybe a tool call or two.
That was enough to handle simple requests and actions but with some issues.
Context bled across sessions, there was no durable execution, and “multi-agent” meant spawning another chat thread and hoping for the best.

The next step was OpenClaw, a real harness with skills, MCP integrations, and structured tool access. AVA became more practical: it could read mail, pull YouTube transcripts, and run recurring jobs. But orchestration was still largely implicit. The planner-coder-reviewer pattern was baked in, not chosen per task.

The current architecture is different. AVA runs on a Harness gateway + store split that I developed: the gateway handles live agent sessions, tool dispatch, and orchestration; the store persists workflows, checkpoints, eval artifacts, and improvement proposals. Orchestration is template-driven with dynamic DAG task assignment—not a fixed pipeline.

That shift matters. A research question should not spawn a coder. A one-file fix should not wait on a planning phase. Frontier harness engineering is about matching structure to intent, then measuring whether the match was right.

What a frontier harness actually means

#

A harness is not a chat wrapper. It is the runtime that decides how work gets done: which agents run, what they remember, how failures recover, and how the system learns from outcomes.

For AVA, “frontier” breaks down into four coupled layers:

1. Orchestration runtime — dynamic task graphs from templates, live visibility on /runs
2. Hybrid memory — facts, episodes, session state, and a knowledge graph
3. Operational workflows — sequential, resumable pipelines for recurring real-world tasks
4. Judge-driven eval loops — scored trajectories feeding an improvement ledger, with human review before anything ships

Multi-agent specialists sit on top: coder, researcher, planner, reviewer, domain org agents, and ad-hoc specialists via agent_create when the configured roster is not enough.

AVA current system is the first where self-improvement is a designed loop.

Orchestration: templates, not fixed roles

#

The orchestration runtime assigns work on a dynamic DAG. Tasks carry assignees (researcher, coder, reviewer, etc.) and dependencies; the runtime schedules them as prerequisites complete.

Templates constrain the shape of that graph:

• research_only — a single researcher, no coder escalation. Good for lookups, scans, and synthesis where code changes are out of scope.
• writer_editor — content production with a write/revise split.
• single_coder — one coding agent, minimal coordination overhead for bounded edits.

These are not cosmetic labels. Eval cases assert template behavior: research_only must stay single-researcher with no coder spawn; single_coder must not sprawl into a full planning phase. The template name is inferred from the trajectory and checked against rubrics.

Live task tracking lives on the /runs board. When AVA orchestrates multi-step work, you see tasks move from pending to running to done—or fail with enough context to debug. That observability is table stakes for production harnesses; without it, multi-agent systems are opaque fan-out.

I am skeptical of harnesses that synthesize a fresh graph on every request. Dynamic synthesis sounds flexible; in practice it produces inconsistent trajectories that are hard to eval and impossible to resume. AVA prefers template-based orchestration: a known skeleton, dynamically filled task specs. You get adaptability without giving up reproducibility.

Hybrid memory: four stores, one mental model

#

Agents that only remember the current chat window forget everything useful. Agents that dump the entire history into every prompt burn tokens and dilute signal. AVA uses a hybrid memory model with four retrieval paths, each tuned to a different kind of question.

• Vector facts (memory_remember / memory_recall) hold stable preferences, decisions, and domain facts—semantic retrieval for “what does Afonso prefer?”
• Episodic history (memory_episode_record / memory_episode_recall) stores summarized run outcomes—“what happened last time we tried X?”
• Short-term session memory (memory_stm_put / memory_stm_get) is scratch state within a session, TTL-backed.
• Knowledge graph (knowledge_graph_query) tracks persistent entities and relationships—projects, concepts, workflows.

The memory loop (P1) closes when terminal orchestration runs record an episodic entry exactly once. Future routing can recall that episode: recurring intents like “scan my mail” or “run the weekly evals digest” match prior successful trajectories instead of re-deriving the path from scratch.

Vector memory holds facts (“Afonso prefers speaking in French”). Episodic memory holds events (“protonmail-daily-scan completed with 3 flagged messages”). The knowledge graph holds structure (AVA OPERATES Harness, evals-weekly-throughput PROVES durable step executor). Short-term memory holds now (the message ID we are replying to, the branch name for this session).

This is not redundant storage—it is separation of concerns. Facts age slowly. Episodes age on a TTL. The graph is curated. Session memory expires in hours. Routing gets the right retrieval mechanism per question.

Durable workflows: real ops, not toy chains

#

Not everything belongs in orchestration. Operational workflows are template-based sequential pipelines for recurring tasks: fetch a YouTube transcript, scan ProtonMail for important mail, run a weekly evals throughput report.

Each workflow is a declared list of steps—often wrapping existing skills and shell actions. The differentiator is durable step checkpoints: if step 2 of 3 completes and the process crashes, resume picks up at step 3. No duplicate side effects, no manual “start over.”

Concrete examples in AVA today:

• youtube-transcript — extract captions, cache locally, return structured text
• protonmail-daily-scan — IMAP scan with importance heuristics, flagged output
• evals-weekly-throughput — scheduled reporting over eval run history

Workflows integrate with the gateway the same way orchestration does: workflow_run kicks off execution and posts a live /workflows/runs/<id> board. Cron scheduling (workflow_schedule) turns one-shot pipelines into operation rhythm.

This is where P3 durable executor work pays off. Checkpoints survive process restarts; resume index advances deterministically. Eval cases assert those semantics explicitly. For a harness that runs on a laptop today and a VPS tomorrow, resumability is not a nice-to-have—it is the difference between “works in demo” and “works on Tuesday.”

Judge-driven evals and the improvement ledger

#

Self-improvement without measurement is self-deception. AVA’s eval layer scores orchestration trajectories against declared rubrics.

A judge criteria schema defines weighted checks—some deterministic (single_researcher_no_coder, template_is_research_only), some model-judged. Cases like orchestration_judge_research_only run a scenario, score it, and compare against pass and winner thresholds.

Winners feed the improvement ledger: a queue of proposed harness edits—prompt updates, skill additions, workflow changes. The judge outcomes API surfaces scores and proposals. Studio Evals is the human gate: you review what the system wants to change before it touches production.

Example flow:

1. Eval runs a research_only scenario with rubric research_only_quality
2. Trajectory scores 1.0—single researcher, correct template inference
3. System proposes promoting the winner pattern to orchestrator/research_only.md
4. Proposal sits in evals/pending/ until a human approves or rejects

Nothing self-applies. AVA can detect recurring failures, missing workflows, and suboptimal routing—but propose only. That constraint is intentional. The harness that rewrites its own prompts without oversight is a harness you will not trust on week two.

The loop is informed by established patterns—Reflexion-style critique, Voyager-style skill libraries—but adapted for a production harness: proposals are versioned artifacts with rationale, not silent weight updates.

Multi-agent specialists

#

Orchestration assigns roles; agents embody them. AVA ships with configurable specialists—coder, researcher, planner, reviewer—and domain org agents for scoped contexts. When the roster is insufficient, agent_create spins up an ad-hoc specialist with a focused system prompt and optional model override.

The point is not agent proliferation. It is right agent, right task. A researcher should not inherit a coder’s edit-heavy prompt. A reviewer should not be asked to plan. Specialists keep context clean and make trajectories easier to judge.

Honest gaps

#

Frontier is a direction, not a destination. AVA has known gaps:

• Orchestration blackboard — no shared mutable state across parallel tasks yet. Agents coordinate through task outputs, not a live scratch pad. Complex multi-agent edits still serialize more than I would like.
• Short-term memory enhancements — session STM exists, but richer compaction, summarization, and cross-session handoff rules are still maturing (handoff_save / handoff_load help; they are not the full story).
• Workflow coverage — wrappers for memory recall and knowledge-graph query exist, but the catalog is still thin compared to the full harness tool surface. Most capabilities remain agent-invoked, not cron-schedulable pipelines.

I would rather ship with explicit gaps than paper over them. The eval suite encodes what “done” means; the ledger encodes what “better” looks like.

What I would tell another builder

#

If you are building a harness in 2026, prioritize in this order:

1. Observability — /runs and workflow run boards before more agents
2. Memory with types — facts ≠ episodes ≠ graph ≠ session scratch
3. Templates over freeform graphs — reproducible trajectories you can score
4. Evals before self-edit — proposals with human approval, not automation
5. Durable execution — checkpoints for anything that touches the outside world

AVA is my attempt to practice what the recent harness engineering literature preaches: dynamic orchestration where it helps, structure where it hurts to improvise, and closed loops that turn run history into tomorrow’s defaults.