FrontierAgent

Tue, 25 Aug 2026 00:00:00 +0000

I initiated and lead FrontierAgent, an open-source agent runtime and research workbench for long-running research and file-based tasks. It combines a terminal interface, sandbox tools, and evaluation workflows for single-agent ReAct and Agent Team execution, and shares reusable infrastructure with ApodexHarness through AgentCore.

Demo

A 1-minute 48-second walkthrough of Agent Team in FrontierAgent’s terminal interface.

The problem: keeping a long task coherent

A research task may involve several evidence sources, analysis scripts, intermediate files, and parallel investigations. Simply adding more agents does not settle who owns the plan, when work is complete, or which files constitute the final result. FrontierAgent makes those responsibilities explicit in the runtime.

Its public interface offers two workflows: ReAct for a stateful single-agent loop, and Agent Team for a coordinator that delegates independent assignments and integrates reports. The same workflow engine also supports benchmark execution, connecting interactive use with repeatable evaluation.

Conceptual Agent Team workflow. Specialist roles illustrate possible task decomposition; the coordinator organizes the team for the task rather than using a fixed roster.

Coordination, state, and delivery

The architecture below separates three responsibilities that become tightly coupled during a long run:

Coordination: the main agent maintains an external task board and uses an Agent Bus to dispatch work and collect reports. Execution status and the coordinator’s judgment that a task is resolved are distinct pieces of state.
Execution: sub-agents produce candidate artifacts in working directories. The isolation backend determines whether those directories are private worktrees or a shared mount. Read-only inputs remain separate from mutable working files.
Delivery: a single-publisher lease and an explicit output manifest govern final publication. Reconciliation against the initial output state prevents stale or empty files from being mistaken for newly completed deliverables. Shared scratch space remains outside the collected final output.

Runtime responsibilities across coordination, execution, and publication. The diagram distinguishes working state from final delivery and shows where user follow-ups enter the active run.

These mechanisms address state loss, ambiguous ownership, concurrent output writes, and premature completion claims. They do not by themselves establish that a scientific method or conclusion is correct; task-specific verification remains necessary. The runtime contract is also described in the , Section 3.3 and Table 2.

An inspectable workbench and evaluation path

The terminal product exposes the task board, tool activity, artifacts, and local traces. Checkpoints support resuming a session, and follow-up instructions can steer an active run. The evaluation runner supports artifact collection and rerunning failures, making it possible to investigate where a task broke down rather than only record its final score.

The repository also contains , which evaluates complete scientific deliverables. See the for its task design and reported completion gaps, and for model-and-system results using ReAct and Agent Team. Those benchmark gains reflect the complete evaluated configurations, not a standalone runtime speedup claim.

Explore: · .

Open Source | Zhang Handuo's Site

FrontierAgent

Demo

The problem: keeping a long task coherent

Coordination, state, and delivery

An inspectable workbench and evaluation path