Research

Once a task is split across agents, who owns the current state stops being a detail. Who may write, who is accountable afterwards, whose version wins when two changes conflict — the assumptions that hold by default in a single agent all have to be answered again. We care about runtime answers to these questions, not conventions left to the user.

• Ownership: how runtime state is owned and handed between agents over a long-horizon task.
• Conflict: how concurrent writes to the same state converge without a global lock.
• Tools and scheduling: how shared tools and sandboxes are isolated, reused, and reclaimed.

The harness is the layer outside the model that decides how an agent performs. We treat the harness itself as the object of study: how it organizes context, how it decides an execution has gone off track, how it recovers afterwards — and whether it can do these things itself rather than through someone rewriting the prompt.

• Context: what stays in context on a long-horizon task, what gets written out, and when it comes back.
• Failure detection: judging that an execution has drifted, with no human labels.
• Self-evolution: validating that a strategy change actually helped, rather than reading noise as signal.

We do not believe a general harness exists. A domain’s constraints — the shape of its data, the boundaries of its tools, the cost of a mistake — decide what the harness has to look like. Moving a harness built for one domain into another usually fails; what is needed is a redesign, not parameter tuning.

• How domain constraints enter the design of a harness instead of living in user conventions.
• What transfers across domains: the runtime primitives, or only the engineering practice.
• How to tell that a harness has actually been fitted to a domain.