The interesting part of Apodex 1.1 is not that another model joined the crowded "agent" shelf. It is that the authors put a 35B model beside a coordinated team and measured the extra work the team bought. On the Mini evaluations, the matched FrontierFinance result is 40.0 versus 50.2 for ReAct and Agent Team. FrontierScience-Research reached 45.0 with ReAct and 51.7 with Agent Team. APEX-Agents reached 24.2 and 27.7, respectively. Those are useful numbers, but they do not mean "always spawn more agents." They give you a threshold question: is the task wide and checkable enough to pay for coordination?

Apodex Agent Team state contract and verification flow

Apodex 1.1 is a fresh research release dated August 24, and its open-source companion, FrontierAgent, is already a runnable terminal product. The project has two native modes. ReAct keeps one stateful worker inside a task sandbox. Agent Team adds a coordinator, a task board, parallel sub-agents, structured reports, and a synthesis pass. The same workflow engine powers the evaluation runner, which matters because the comparison is not only about a chat model's answer. It is about the execution system around the model.

The paper calls the broader target "working capability": sustained progress toward a real-world object with state, tools, recovery, and verifiable delivery. That definition is more honest than treating a benchmark answer as the whole job. If an agent has to inspect a repository, run code, create several files, notice a failed command, and deliver a consistent bundle, the final paragraph is only one part of success.

The decision rule

Use the single ReAct path when the task has one main line of attack. A bounded repository explanation, a small refactor, a document conversion, or a short research question rarely needs a manager plus several workers. One stateful loop is easier to inspect, cheaper to run, and less likely to create duplicate work.

Use Agent Team when the task has independent branches and a clear way to check the result. The paper's environments cover file work, search, and executable code. That combination is a good clue. A literature scan can split into source discovery, claim checking, and synthesis. A code investigation can split into reproduction, implementation tracing, and test design. A file-heavy analysis can assign measurement and quality control to separate workers. The gain comes from parallel attention plus a verifier, not from multiplying opinions about the same vague prompt.

Task shape Start with Why
One repository, one change, one test ReAct Fewer moving parts and a smaller failure surface
Several independent research branches Agent Team Parallel work can reduce wall-clock time
File or code task with required artifacts Agent Team with verification The output can be checked for files, formats, and consistency
Open-ended brainstorming ReAct first A team can create more text without creating better decisions
Production write access on an unfamiliar host Neither by default Establish isolation, approvals, and recovery first

The 35B parameters are small enough to make local deployment a serious question, but model size is not the same thing as a complete local experience. You still need an endpoint, enough memory for the chosen format, a runtime, and a filesystem boundary that prevents a failed sub-agent from turning a research run into a host modification.

FrontierAgent's repository gives a practical starting point. It expects Python 3.12 and uv for the normal setup, then exposes uv run frontier-agent --mode react and uv run frontier-agent --mode agent_team. The model endpoint is OpenAI-compatible, so the runtime and the model service can be separate. That is useful on a laptop: run the terminal workflow locally and point it at a hosted endpoint while you decide whether a local 35B serving stack is worth the hardware.

The project's filesystem split is the part I would copy before copying its prompts. /inputs is read-only. /workspace holds working files. /outputs contains persistent deliverables. Mutating actions can show a diff and require approval, sessions are checkpointed, traces are kept locally, and a run can resume or revert. Those are not decorations for a terminal UI. They are the control plane that makes parallel execution tolerable.

A safe first trial looks like this:

git clone https://github.com/ApodexAI/FrontierAgent.git
cd FrontierAgent
uv sync --python 3.12 --extra dev
cp .env.example .env
# Set an OpenAI-compatible endpoint in .env
uv run frontier-agent --mode react --cwd /path/to/sandbox

Run the same bounded task in Agent Team only after the ReAct version produces a known-good artifact. Keep the input read-only. Put the workspace on a disposable checkout. Ask for a report and a test result, not a production deployment. If the team cannot reproduce the single-agent result with cleaner evidence, the extra workers are overhead, not progress.

Where the team still fails

Apodex's own numbers argue against triumphalism. On the revised 17-task BioMysteryBench set, Agent Team passed 35.3% (6/17). Claude Opus 5 reported 49.4% on that set. On the internal FrontierResearchBench, Apodex 1.1 with Agent Team reached a 12.4% full-task pass rate. The paper notes that GPT-5.6-Sol with Codex and Grok-4.6 with Claude Code reached only 20.6% there, so the test is hard. It is still a useful warning: a coordinated team can improve partial capability without making long scientific workflows reliable.

That distinction changes how you should read the headline gains. Agent Team improved selected matched scores, but the evaluation is not a proof that ten workers beat one worker on every task. The paper itself warns that some reference systems use different model sizes, execution modes, or aggregation protocols. Several proprietary parameter counts are unknown. The fair comparison is the Mini's own ReAct-versus-Agent-Team ablation, plus the operational behavior you can reproduce in the open runtime.

There is also a cost that benchmark tables rarely show. Coordination creates more model calls, more intermediate files, more chances for stale state, and a synthesis step that can confidently merge incompatible reports. A task board helps, but it does not make a bad decomposition good. A verifier helps, but only if it checks the artifacts rather than praising the prose. The right safety test is adversarial and boring: remove one expected file, corrupt one numerical result, deny one shell operation, and stop the run at its budget boundary. The system should fail closed, leave a trace, and make recovery obvious.

For most developers, the practical recommendation is narrow. Use ReAct as the baseline. Use Agent Team for work with genuine parallel structure, durable intermediate artifacts, and deterministic checks. Keep permissions scoped to a disposable workspace. Require a final verifier to inspect files and numerical consistency. Set a hard token or time budget before the run starts. If the task cannot be checked, do not confuse a larger swarm with reliability.

That is why Apodex 1.1 is worth watching. The useful claim is not that a 35B model has replaced every frontier system. It is that the execution harness, environment design, and coordination policy can move the result more than another round of prompt polishing. The uncomfortable part is that the same harness makes failure more productive only when the boundaries are real. Without them, parallel agents just produce a bigger pile of plausible debris.

For background, compare this workflow with the budget and sandbox boundary for always-on agents and the local supervisor pattern.

Sources