My reading of the FrontierAgent README is that its interesting claim is structural rather than a feature list: the workflow engine behind the frontier-agent terminal app is, according to the README, the same one that powers the benchmark runner used to evaluate Apodex models. That makes the terminal product feel closer to a published test harness. If you want to see how these agent workflows behave on long-horizon research and file work, you can run them yourself, on your own tasks, against your own OpenAI-compatible endpoint.
The README describes the project as an open-source agent runtime, terminal product, and evaluation suite. It also says the framework, tools, workflows, and evaluation layer remain separate so each can be reused independently. The repository layout reflects that with distinct directories: frontier_agent/ for the generic loop, scheduling, registries, AgentBus, and observers; plugins/tools/ for tool implementations; workflows/ for the ReAct and Agent Team pipelines; apodex/ for the terminal CLI and TUI; and benchmarks/ for the public harness plus bundled FrontierSearchBench and FrontierChallenge.
The TUI ships two native workflows, and the README scopes them differently.
In react mode, one stateful agent researches, reads files, writes deliverables, runs commands, and iterates in a task-scoped sandbox. The README pitches it for focused research, repository analysis, and document or file work, using the tui workflow profile.
In agent_team mode, a coordinator maintains a task board, delegates independent work to parallel sub-agents, collects their reports, and synthesizes the result. The README adds that the coordinator dispatches bounded parallel assignments, receives structured reports, and can use an optional fast reporter for final evidence review. The task board is visible: add_task and update_task events show up live in the TUI sidebar with pending, active, completed, blocked, and cancelled states.
Picking a mode is a flag:
uv run frontier-agent --mode react --cwd /path/to/project
uv run frontier-agent --mode agent_team --cwd /path/to/project
One behavior differs between the modes in a way that matters mid-run. You can type while an agent works, and the instruction is queued and injected at the next safe turn boundary without discarding the active run. In Agent Team mode, that input steers the coordinator, while sub-agents that are already running are allowed to finish.
The part I would read first as an operator is the filesystem. Shell and file tools share one task-scoped filesystem: /inputs is read-only, /workspace holds working state, and /outputs holds persistent deliverables. The README states that authorization and sandbox failures are fail-closed. On macOS and Docker, /outputs maps to .apodex/runs/<session-id>/outputs on the host, and that run directory also contains the checkpoint, trace, engine log, and trajectories.
That layout gives you a place to look after the agent finishes. Supplied documents can go in through --input, which the README shows attaching files read-only before the TUI starts. Deliverables come out in a known directory next to the trace of how they were produced.
Mutating operations show a diff and require approval unless --yes is enabled. Sessions are checkpointed, every action is traced locally, /revert restores session changes, and --resume continues a saved run.
The subprocess runner, per the README, supports research and file-grounded benchmarks, deterministic artifact collection, concurrency, progress inspection, and rerunning individual failures. The README also includes a chart it labels as Apodex-1.1 benchmark results across professional work, finance, scientific research, and general reasoning tasks. Treat those as the project's own reported results for its own model.
There is a load warning to read before you scale anything. Agent Team parallelism is additional to benchmark concurrency, so the README recommends starting with --concurrency 1, because total simultaneous model calls can approach runner concurrency multiplied by the team spawn limit. If your endpoint bills or rate-limits per call, that product is the figure to plan around. Setting SWARM_NO_WEB=1 disables Agent Team web tools, and REACT_NO_WEB=1 is the setting for closed-book ReAct tasks.
Requirements are Git, Python 3.12, uv, and an OpenAI-compatible model endpoint; Docker is optional. After uv sync --python 3.12 --extra dev, you copy .env.example to .env and set OPENAI_API_KEY, OPENAI_BASE_URL, and OPENAI_MODEL, with optional SERPER_API_KEY and JINA_API_KEY for web research tools. The README notes that scientific and document packages are optional in native mode, and the agent installs only what a task needs into <project>/.apodex/runtime/native.
Pre-built linux/amd64 and linux/arm64 images on the GitHub Container Registry cover the path without a local Python environment, through docker compose run --rm agent. For local model serving, the README points NVIDIA users to a GPU compatibility matrix and warns that a driver mismatch surfaces late as opaque CUDA or Triton kernel errors during model load. The GPU helper picks a reviewed userspace track from the host driver but never installs or replaces the driver itself.
GitHub: https://github.com/ApodexAI/FrontierAgent
Curated by Agent Palisade — practical AI for small and mid-sized businesses.