Task‑Adaptive Harness: Turning Agent Traces into Collaborative Coding Memory

Background: From Agent Trace to Collaborative History

During the final month at Thoughtworks (now Inspire), the author built an end‑to‑end AI coding solution using Claude Code, a web UI, a proxy, Agent Trace, and Skills. Although the solution never reached a client project, the core design – an ACP‑based Agent Trace – records every agent’s key actions (tool calls, file reads, context accesses) as structured JSONL sessions.

These traces become more than logs; they can be aggregated, analyzed, and attributed to features or files, then reused before the next task starts.

Agent Trace’s value lies in turning collaboration history into analyzable, reusable data.

First Experiment: Trace Learning → Feature Explorer

With Trace Learning, the author visualized relationships among traces, requirements, features, and files. By aggregating multiple sessions, patterns emerged: which features frequently access which files, which tools are repeatedly invoked, and which files appear before failures.

The earlier Feature Explorer (see the linked article) linked traces to features, turning raw session order into meaningful engineering signals.

session trace
→ file / tool / context signals
→ feature attribution
→ repeated patterns
→ reusable context

The next question was whether these historical patterns could help an agent start a new Kanban task more effectively.

Kanban Harness Quality Issue: Can History Improve Agent Startup?

In the Routa project – a Kanban‑driven multi‑agent system – each specialist often repeats work when a card changes hands (e.g., developers search for entry files, reviewers re‑understand change boundaries, planners guess feature scope). Even with stored sessions, traces, and artifacts, the next agent usually starts from a raw state, causing cold‑start waste.

The Task‑Adaptive Harness addresses this by assembling a pre‑task context based on the card’s current stage (planning, implementation, review) and selecting only the most relevant sessions, files, modules, and constraints for the upcoming role.

Different roles need different historical cues: planners need intent and decomposition, developers need entry points and module dependencies, reviewers need change boundaries and risk points.

Task‑Adaptive Harness Principles

Context should be determined by the task, not by accumulated history. The system starts from the task, identifies required functions, files, and sessions, then contracts the context to what is truly needed.

Judgment must be evidence‑based, not summary‑based. Instead of generating a plausible summary, the system surfaces verifiable evidence: hit files, relevant sessions, failure records, and matching reasons. If evidence is insufficient, the system degrades gracefully.

Constraints must take effect before execution, not after. Historical rules influence tool selection, permission scopes, and behavior boundaries at task start, reducing downstream deviations.

Second Experiment: From Historical Sessions to Multi‑Agent Collaborative Memory

Before a session begins, the system bundles the task goal, current role, and relevant history into a launch entry, giving the agent a direction‑aware starting point.

At launch, the bundled history is refined into execution boundaries: which feature clues are most relevant, which files to prioritize, which failures to avoid, and which tool paths to prefer.

After a delegation finishes, the system retains not only a replayable trace but also a hand‑off state describing tried paths, dead‑ends, and open questions, enabling the next agent to continue without re‑reading the entire transcript.

With repeated runs, successful paths, common failures, stable tool sequences, and verification methods crystallize into task‑level experience that informs future starts.

These layers answer fundamental questions: how a task starts, how boundaries are formed, how work is handed over, and how experience is preserved.

Summary: From Local Harness to Full‑Process Harness

The core issue reduces to whether the system truly retains useful artifacts after a task ends. Although traces, sessions, file changes, and failure records exist, the next agent often still must locate entry points, redefine boundaries, and re‑establish context, making the stored data feel like a static archive rather than actionable knowledge.

How can the work done by earlier agents be reliably handed off to later ones?

If solved, the harness evolves from a set of prompts, scripts, and rules into a persistent mechanism that spans task initiation, hand‑off, and continued execution, preventing each new start from beginning from scratch.