Paper walkthrough: Apodex 1.1 — scaling agents around completed work

Not a bigger model and not more thinking time — Apodex 1.1 scales two other surfaces: the environments an agent learns in, and the way work is organised across agents. A walkthrough from the task contract to the AgentOS delivery gate, the numbers, and the limits.

Apodex 1.1: Scaling Agentic Intelligence for Complex Work

Answering a question and finishing a job are not the same skill

Someone who can answer a hard quiz instantly is not necessarily someone who can carry a three-day engagement to delivery. The second job needs a different muscle: staying with requirements that shift, redoing what failed, and assembling artifacts that another person can actually inspect.

The Apodex 1.1 technical report (arXiv:2608.23283) starts from exactly that gap. General-purpose models have improved fast on knowledge and reasoning, yet many valuable tasks stay hard even when the model can state the right answer, because the work unfolds over a long horizon: find and interpret evidence, operate on heterogeneous files, execute and debug code, recover from failed actions without discarding valid progress, and deliver artifacts someone else can continue from (§1). The report names this working capability — "sustained, verifiable progress toward a real-world objective" — and declares that the unit of the capability is completed work rather than an isolated response (§2.1). It is developed along two axes: Environment Scaling and Agentic Coordination Scaling.

Writing the job down as a contract

One task contract runs through the whole report (§2.1).

In order: the space of workspace states, the initial workspace, the objective, the actions available, the state-transition operator, the observation interface, the resource-budget vector (turns, tool calls, tokens, wall-clock, concurrent executions), the delivery contract $D$, and the verifier $V_{D}$ attached to it. Which says, in words: a spec sheet listing the state of the desk, what you are trying to achieve, what you are allowed to do, what happens and what you get to see when you do it, what resources you may spend, what counts as delivered, and who decides.

The outcome is $S_{D}=V_{D}(W_{0},W_{H},\tau_{H})$ — decided by initial state, final state, and the execution trace together (Eq. 5). The report is explicit that a natural-language answer may be one artifact in the final workspace, but does not by itself define success. The yardstick is whether the state and the path satisfied the delivery contract, not whether the prose reads well.

Axis one: Environment Scaling

This is defined as widening the distribution itself over the components of Eq. (1) — $(W_0,q)$, $\mathcal{A}$, $(\mathcal{T},\Omega)$, $\mathbf{B}$, $(D,V_D)$ — rather than attaching more tools to a model or generating more prompts (§2.2). Three families are built. File worlds centre authority and transformation: the facts you need are scattered across nested directories, historical versions and mismatched formats, and coverage is widened along occupations — the maintained registry is reported to span 33 domains, 318 occupations and 1,208 deliverable clusters (§3.1.1). The important claim is that difficulty is independent of file count; what moves it is the length of the business-logic chain to reconstruct and how much of the delivery contract must be inferred from context rather than copied from the prompt. Search worlds centre discovery and evidence alignment, and the gold object is richer than a final answer: the relevant source set, the claim-to-evidence alignment, and explicit uncertainty where sources conflict. Code worlds centre executable transformation and verification. Worlds harvested from real pull requests are checked with fail-to-pass and pass-to-pass tests, but synthesised worlds have no external oracle — so the pipeline additionally attacks its own graders, testing whether a solver can collect reward without completing the task, and treats only attacks that succeed in the sandbox as verifier failures. Scoring is isolated from the solver so the solver cannot edit the grader.

The design philosophy is compressed into one sentence in §2.2: "Diversity without fidelity teaches behavior that fails in real tools; fidelity without sufficient coverage overfits a small number of workflows; and interaction without verification rewards plausible activity rather than completed work."

A dial for difficulty: acquisition pressure

For worlds where acquisition dominates, the report defines a difficulty coordinate (§3.1.2).

$N_{\mathrm{cand}}$ is the number of plausible candidates that need expensive inspection, $N_{\mathrm{hop}}$ the number of load-bearing evidence transitions, and $B_{\mathrm{tool}}$ the tool-call budget. Put in words: the numerator is how much you must look at, the denominator is how much you are allowed to look at, so the ratio is how tight the investigation is against the budget. The flip side is that piling on more files or pages does not make a task harder while the authoritative path stays obvious. The report itself flags this as a first-order coordinate, not a universal measure of difficulty.

Axis two: scaling coordination itself

A long job is a division-of-labour problem as much as a computation problem (§2.3). The report frames this as policy behaviour representable in training trajectories, not a property of an inference-time wrapper, and argues that the scaling variable is neither the number of agents nor the number of samples but "the amount of useful work that can be coordinated as an objective evolves". At runtime that job belongs to Agent Team, which in 1.1 is externalised onto a persistent task board and gains four capabilities (§3.2).