Latest / Embodied AI 101 / Occamy-1.0: Teaching a 35B Agent to Finish the Job

Transcript

Occamy-1.0: Teaching a 35B Agent to Finish the Job · Embodied AI 101

• Occamy-1.0: Teaching a 35B Agent to Finish the Job. Occamy-1.0: Open Pareto-frontier 35B Intelligence for Co-work • Accio Team, including Wenhui Chen and colleagues • Accio-Lab • arXiv preprint • 2026. The hard part comes after the plan. Imagine an assistant that correctly understands a request, selects sensible tools, and produces a convincing explanation—but updates the wrong record halfway through the workflow. Or sends the right email twice. Or forgets, after compressing its context, that an irreversible action has already happened. For an interactive chatbot, those might look like peripheral implementation problems. For an agent responsible for completing work, they are the task. The Occamy project offers a concrete illustration: a showcased recruiting workflow preserves five candidate records, corrects two labeling errors, sends one Gmail message without retrying the send, and reopens five artifacts for verification. The interesting feature is not a spectacular reasoning leap. It is maintaining consistency between the request, intermediate decisions, and persisted results. That is the lens through which I would read Occamy-1.0. Its central question is not whether a relatively compact model can imitate the prose of a larger one. It is whether additional training can make an already capable model substantially better at carrying responsibility through an extended sequence of actions. For roboticists, this should sound familiar. A plausible plan is not a completed manipulation task. A successful command dispatch is not evidence that the intended physical transition occurred. Likewise, a digital agent saying that it reconciled a database is not equivalent to a database actually being reconciled. But we should establish the boundary immediately. Occamy is a digital co-work model, not a demonstrated robot policy. Its documented specialization concerns tools, files, code, structured APIs, and professional workflows; native browser or desktop visual interaction is outside its current co-work training interface. The research comes from Accio, while Hugging Face hosts the release. The embodied-AI relevance is therefore architectural and methodological: how to train an executive policy whose decisions remain grounded in persistent state, including when its own conversational memory changes. What the 35B number actually means. Occamy continues training from the post-trained Qwen3.6-35B-A3B checkpoint. This is not a new foundation model trained from scratch. Its SFT updates the language backbone while freezing the vision encoder and projector, with a maximum SFT sequence length of 131,072 tokens. The underlying Qwen architecture has approximately 35 billion total parameters but activates about 3 billion per token. It contains 40 layers, combining Gated DeltaNet and attention blocks, with a routed expert pool of 256 and eight routed experts plus a shared expert activated in its MoE layers. The published native context length is 262,144 tokens. The distinction between total and activated parameters matters. Three billion active parameters describes sparse computation, not a three-billion-parameter storage footprint. As a simple weight-only calculation, 35 billion parameters stored at two bytes each would occupy roughly 70 gigabytes before runtime state and other overhead. That calculation is not a deployment benchmark; it illustrates why “3B active” should not be translated directly into “runs like a dense 3B model.”. I would separate three engineering budgets when assessing this checkpoint: storing the model, processing an individual invocation, and completing the entire task. A favorable result on one budget does not automatically establish the others. The context figures require a similar separation. Training sequence length, supported inference context, and effective task horizon are different quantities. A large context window gives a policy more room to condition on history. It does not, by itself, establish that the policy can preserve obligations through repeated summaries, distinguish completed work from planned work, or recover correctly after partial execution. For a hypothetical inventory workflow, remembering a supplier’s name is less important than remembering whether a purchase order was merely drafted, actually submitted, or submitted without a receipt. Those are different execution states even when their textual descriptions look similar. This is why I would interpret Occamy primarily as a post-training and execution-system contribution. The architectural capacity is inherited; the research question concerns how that capacity is organized into dependable behavior. Training on work that can actually be checked. The project organizes training around executable task contracts: a request, initial world, available tools, constraints, and grader. Tasks can be constructed environment-first, starting from available interfaces, or capability-first, starting from a behavior that needs improvement. Admission checks cover feasibility, discoverability, successful reference execution, failing near-misses, provenance, and contamination. That framing changes what should count as a training example. Consider a hypothetical task that asks an agent to reconcile warehouse inventory without placing new orders. The example is not just that instruction plus an ideal answer. It needs initial inventory records, tool behavior, access permissions, relevant evidence, and a way to distinguish reconciliation from unauthorized purchasing. It also needs negative tests. An unchanged database should not pass because the final response sounds correct. A reconciliation that silently drops a troublesome record should not pass because the remaining totals agree. A workflow that completes the requested update while also placing an order should fail its authorization requirement. My proposed test of such a dataset would be simple: can the authors demonstrate both a valid solution and several convincing-looking invalid solutions? If the grader cannot distinguish those, more policy optimization may amplify the wrong behavior. The released Dressage Claw recipe provides a useful implementation example. It separates task files from grader files and injects the grader only after agent execution finishes. Tool evidence is collected at the dispatcher rather than accepted from the agent’s self-report. It also supports continuous grading and a hard failure gate for forbidden tool calls, rather than treating those violations as small deductions. The general lesson I would extract is that grader access, action evidence, and authorization boundaries belong in the environment design. Asking the model not to inspect an accessible answer key is a weaker experimental design than keeping that answer key outside its execution environment. The SFT corpus is also more substantial than its row count initially suggests. Across the two expert training sets, the deduplicated union contains 14,998 trajectories and 403.3 million tokens. Its 923 long-horizon interactive trajectories average 95.8 thousand tokens, while 7,429 tool-grounding trajectories average 9.1 thousand. For an adaptation project, I would therefore inspect both example counts and token allocation. A few unusually long task families can dominate training exposure. Conversely, many short tool-formatting examples can dominate the row count without dominating the optimization workload. I would also vary more than wording. Changing names and dates in otherwise identical workflows is not the experiment I would use to test execution generalization. I would vary which evidence is available, which action has already occurred, which service fails, and which recovery remains permitted. A new context is not a new episode. The project makes an important distinction between an episode—a complete task attempt—and a segment of model-visible history. A history rewrite starts another segment without resetting the task or its outcome. Suppose an agent has reconciled three records, written a temporary report, and delegated an investigation. Its context then becomes too large, so the harness replaces much of the conversation with a summary. The files do not disappear. The investigation does not become unrequested. Earlier side effects do not become hypothetical. Only the policy’s representation of its history has changed. For a training system, that creates a bookkeeping problem with direct statistical consequences: which tokens were actually generated by the policy, under which conditioning history, and which eventual outcome should train them?. Accio releases its agentic RL infrastructure as Dressage, built on slime. Its architecture separates agent interaction semantics from sandbox placement and from the training backend. Python-controlled tool loops and externally driven agent harnesses feed a common recording and sample-conversion path, while upstream components handle distributed training and inference. The proxy documentation is particularly worth reading. Every model call passes through a recorder that captures prompt and response token IDs, rollout log-probabilities, loss masks, and weight-version information. Token-In-Token-Out construction preserves token-level continuity instead of relying on repeatedly decoding and retokenizing a chat transcript. The training documentation then handles multiple segments explicitly. Earlier segments are retained, related segments share identifiers, and aggregation rules prevent a trajectory from receiving extra weight merely because it was split more often. Prompt and tool positions are distinguished from trainable assistant tokens. This is easy to underestimate because it sounds like data engineering. But imagine supervising a copied summary as though it were a freshly sampled action, or losing the early decisions that created the successful final state. The optimizer would receive a different learning problem from the one the agent actually experienced. Occamy’s report additionally requires environment-state replay, not just token replay. That distinction is decisive for debugging. Reconstructing the same prompt while restoring a different database is not replaying the same decision. Likewise, branching two policies from an intermediate state is informative only if both receive equivalent workspaces and service state. ReAct is a useful conceptual predecessor here: it established an influential pattern of interleaving reasoning, actions, and observations. Occamy’s more specialized concern is making extended executions usable for training despite changing histories and heterogeneous harnesses. The action-observation loop is the starting point, not the whole contribution. Specialize twice, deploy once. The post-training recipe develops two checkpoints from the same starting model. A Marathon Expert receives SFT followed by Hierarchical Decoupled Policy Optimization, or HDPO. A Sprint Expert receives SFT over broader, shorter-horizon agentic work. Their parameters are uniformly merged, and Single-Rollout Asynchronous Optimization, or SAO, refines the combined checkpoint. Here, “expert” means a specialized checkpoint—not one of the routed experts inside the MoE architecture. The motivation is understandable: sustained execution and broad supporting competence need not respond identically to the same training distribution. But the particular branching recipe should be treated as an empirical design choice, not a general law that every agent needs two training tracks. HDPO comes from Shilin Yan and colleagues’ Act Wisely. Its important idea is to separate correctness and efficiency signals rather than entangling them in a single normalized reward. In that work, tool efficiency is compared among correct solutions, preventing a fast incorrect answer from serving as the efficiency reference for a slower correct one. Occamy adapts that idea by comparing interaction counts within groups sharing the same terminal accuracy score. An illustrative example makes the objective intuitive. Suppose two trajectories successfully reconcile an account, one using six interactions and another using nine. A third trajectory stops after two interactions without completing reconciliation. The useful efficiency comparison is between the successful executions—not a competition to stop first. Even then, I would audit what “same accuracy” hides. If the grader omits a required verification step, a shorter trajectory can appear equally correct while being less trustworthy. Conditional efficiency optimization still depends on the completeness of its correctness signal. The merge follows the model-soup idea associated with Mitchell Wortsman and colleagues: average aligned weights from related fine-tuned models to obtain one deployable checkpoint without an inference-time ensemble. That relationship to a common initialization is important; the method should not be interpreted as permission to average arbitrary unrelated networks. There is a real trade-off in Occamy’s reported stages: its merged checkpoint scores 29.0 on AutomationBench, compared with 27.6 for the final model. I would read that as evidence that consolidation and subsequent RL change the capability balance, rather than monotonically improving every metric. It also motivates the ablation I would want before copying the recipe: compare branching and merging against a single mixed-data training path under matched compute, data exposure, and evaluation conditions. The practical attraction is one serving checkpoint. The scientific question is whether specialization creates a better starting point for consolidation than a carefully balanced single trajectory through training. Learning across stragglers and compressed histories. SAO addresses a different problem: long agent trajectories do not finish together. In Zhenyu Hou and colleagues’ formulation, each prompt produces one rollout, and completed rollouts can enter training without waiting for a group of alternative responses. A learned critic supplies the baseline that group-relative methods would otherwise estimate from multiple samples. The method also uses rollout-recorded probabilities and double-sided token-level filtering to control updates under policy lag. For an agent-training operator, the appeal is not difficult to imagine. One task may finish after a handful of calls; another may spend minutes waiting on tools or recovering from errors. Group completion can become a scheduling dependency unrelated to the quality of the already completed trajectories. But I would not evaluate an asynchronous system on throughput alone. I would want to know which trajectories arrive late, how stale they are when consumed, and whether filtering systematically removes difficult recoveries. A faster learner is not necessarily a more representative learner. Occamy also follows CompactionRL. Yujiang Li and colleagues’ CompactionRL treats summarization as part of the trainable policy. When context becomes constrained, the policy generates a summary and execution resumes from reconstructed context. Execution and summary tokens share the final task reward, with cross-segment advantage handling and token-level normalization preserving the relationship between earlier decisions and eventual completion. That shifts the question from “Is this a good summary?” to “Does this memory help the agent finish?”. For a hypothetical laboratory assistant, a useful memory might preserve that a sample was already heated, that a container label is ambiguous, that the last sensor reading is stale, and that a second measurement requires approval. A fluent paragraph about the overall experiment could omit every one of those operational facts. This suggests a concrete evaluation intervention: deliberately compact immediately before a consequential decision, then test whether the agent preserves the distinction between attempted, confirmed, and unresolved actions. I would also test whether it retains prohibitions. Forgetting what must not happen can be more consequential than forgetting descriptive background. There is another subtle distinction when implementing this approach. If a summary was generated by the policy, its original generation can be a learning target. If that summary later appears inside inherited context, its copied occurrence should not automatically become another target. Dressage’s separation of conditioning tokens and generated tokens provides the relevant implementation machinery. My broader interpretation is that memory management should be evaluated as part of control. Compaction chooses which evidence survives into the next decision. For the kinds of agents discussed here, that is not merely a text-compression concern. What the evaluations actually establish. The cleanest comparison is Occamy against its starting checkpoint. Selected author-reported results are below; these are not an independent reproduction. | Evaluation | Qwen3.6-35B-A3B | Occamy-1.0 | |---|---:|---:| | Claw-Eval average | 69.5 | 82.2 | | Claw-Eval Pass³ | 54.8 | 71.4 | | WildClawBench | 40.4 | 49.16 | | AutomationBench strict completion | 7.5 | 27.6 | | AutomationBench partial credit | 39.4 | 69.1 | | Terminal-Bench 2.1 | 49.5 | 59.0 |. Claw-Eval’s Pass³ emphasizes consistency across repeated attempts, rather than the best-of-several interpretation associated with pass-at-k. For a workflow agent, that distinction matters: being able to produce one successful attempt is different from reliably executing the same obligation. I would nevertheless avoid treating a repeatability score as a complete deployment reliability estimate. My evaluation would separately track failures after irreversible actions, failures after ambiguous acknowledgments, and failures that require human reconstruction. Two policies with similar aggregate completion can impose very different operational burdens. WildClawBench adds a different perspective. Its public suite contains 60 tasks, and its project explicitly distinguishes model comparisons under a fixed harness from comparisons that vary the harness while holding the model and tasks fixed. That is a useful reminder to evaluate the policy-scaffold combination, not just a model name. The frontier comparison is uneven: against GPT-5.6 Sol, Occamy scores 82.2 versus 81.8 on Claw-Eval, but 49.16 versus 67.20 on WildClawBench. That supports “competitive on selected tasks.” It does not support a blanket claim that the smaller checkpoint has matched a larger system’s general capability. At the narrow Claw-Eval margin, I would want uncertainty estimates before making much of the ordering. AutomationBench is especially informative because its scoring distinguishes partial progress from complete success. Its public benchmark spans 600 tasks across six business domains, with simulated services and assertions over final state. Strict completion requires every assertion to pass; partial credit measures the fraction satisfied. Its public task set is also distinct from the private official leaderboard set. Consequently, the 69.1 partial-credit score should not be narrated as roughly 70 percent of workflows completed. The strict completion result is much lower. My interpretation is that the improvement is substantial, while the remaining completion gap is still too large to ignore when designing supervision and fallback. Finally, the supporting terminal result suggests that this specialization has not simply exchanged general agent competence for one co-work score. But the evaluation measures the complete training package. It does not isolate how much improvement came from SFT, Marathon RL, merging, or final refinement. For adaptation, I would preserve that distinction: an effective recipe can be worth testing before its individual causal contributions are fully understood. Reading the Pareto frontier carefully. The cost claim needs its protocol attached. The paper freezes prices on September 2, 2026, using a shared 35B-A3B provider price vector for locally served models. These are monetary proxies applied to measured tokens, not Occamy API invoices. Occamy’s four-benchmark mean is $0.058224 per task, versus $0.055967 for its parent. Performance equally averages within-benchmark min–max normalized scores for Claw-Eval, WildClawBench, AutomationBench, and GDPval. Its GDPval result uses an independent 207-task cohort, not the official Artificial Analysis leaderboard. Here is how I would interpret that construction. First, common unit prices are useful experimental control. They prevent two similarly sized checkpoints from looking different simply because they were assigned different commercial providers. But a pricing proxy is not a hosting-cost measurement or a live quote. Second, the normalized performance axis depends on the comparison cohort. Changing the strongest or weakest baseline changes the scale on which a benchmark contributes. I would therefore treat the aggregate as a summary of this experiment, not a portable capability unit. Third, equal benchmark weighting need not resemble a deployment’s workload. A laboratory dominated by retrieval-heavy investigations should not assume that a macro-average over four suites represents its operational demand. Fourth, cost per attempted task is not cost per verified useful outcome. In my deployment accounting, failed attempts, review, recovery, and harmful side effects would remain visible rather than disappearing behind token charges. There is also a more direct efficiency observation: on combined Claw-Eval tasks, the authors report 19.5 percent fewer tokens and timeout rates falling from 9.88 to 2.18 percent. Those execution measurements are valuable complements to the pricing plot. For my own system, I would extend them with tail latency, intervention frequency, and recovery cost. The defensible conclusion is therefore narrower than “frontier intelligence for pennies.” It is that this post-training package improves the measured operating point under a declared workload and accounting scheme. Whether that operating point is attractive elsewhere remains an empirical question. The bridge to embodied AI—and the missing bridge. There are useful precedents for the proposed robotics connection. SayCan combines language-based task relevance with learned robotic affordances when selecting available skills. Its contribution is not merely generating a plausible sequence, but connecting language proposals to what the robot can execute. Inner Monologue emphasizes incorporating feedback—including execution outcomes and observations—into language-based planning. That provides another connection: subsequent reasoning should reflect what actually happened, not simply continue the original plan. Occamy is relevant to the executive layer above those mechanisms. But I would regard any robotics transfer as a hypothesis to test, not a result already established by the digital benchmarks. My first adaptation would expose bounded, typed capabilities: inspect an object, query inventory, request a grasp, verify placement, reserve equipment, or ask for clarification. Each operation would return an explicit status and evidence. The language model would not be permitted to convert its own assertion into a successful physical-state update. I would also preserve separate records for intention, dispatch, acknowledgment, and verification. A request to place a container is not the same event as a controller accepting the request, and neither should substitute for an observation that the container is now in the intended location. Replay would need special care. In a physical experiment, I would treat reset as a validated procedure, not assume that reconstructing a textual history reconstructs the world. A changed object pose or an already consumed material can invalidate the comparison even when the prompt is identical. The word “co-work” also should not be inflated into a claim of joint multi-agent learning. In the reported configuration, subagent trajectories are recorded but receive no direct policy loss. For a multi-robot extension, I would therefore design and evaluate additional mechanisms for shared resource ownership, communication failures, and conflicting action commitments. Delegation bookkeeping is a useful foundation, but it is not by itself an answer to coordinated control. The transferable proposition is disciplined task execution: maintain obligations, use feedback, preserve state through memory changes, and verify completion. Physical grounding, safety enforcement, and low-level control would still require their own evidence. How I would evaluate it in a lab. The public release makes a concrete starting point possible. The main checkpoint is Apache-2.0 licensed, and the release lists GGUF, FP8, and NVFP4 variants. A separate public dataset contains 1,005 rows with tools, messages, and image fields; at inspection, it has no dataset card. That subset should not be confused with the complete training corpus or a full collection of replayable environments. The serving instructions reference SGLang and vLLM, including the appropriate reasoning and tool-call parsers. They also recommend preserving the complete assistant message, including reasoning content and tool calls, across agent turns. I would pin that behavior alongside the checkpoint rather than regard the chat template as incidental formatting. I would not interpret the example’s eight-way tensor parallelism as a universal minimum hardware requirement. The NVFP4 release documents a nine-case compatibility check on a single H200 using Marlin W4A16. It explicitly distinguishes those small checks from broad quality or speed benchmarks. My first experiment would hold the harness fixed and compare the parent checkpoint with Occamy on representative internal tasks. I would match decoding, context policy, tool schemas, budgets, and quantization wherever practical. Every run would record the actual served-model identity. The initial task set would deliberately include partial completion and uncertain acknowledgments. For example: an artifact exists but its receipt is missing; a tool reports a timeout after a possible side effect; a delegated result arrives after the parent has compacted its history. These are proposed tests, not reported Occamy results. Next, I would change the harness while holding tasks fixed. That experiment asks whether useful execution behavior survives different retry policies, tool descriptions, and compaction rules—or depends strongly on one scaffold. I would score more than task completion. The evaluation record would include unauthorized actions, duplicate effects, verification coverage, time to useful completion, and how much work a human must perform after failure. A cleanly escalated uncertainty could be operationally preferable to a superficially complete but unverifiable result. Only then would I consider further training. I would begin with failures whose environment state and grading can be reconstructed, rather than collecting a large volume of attractive transcripts. I would also verify that negative examples fail for the intended reason before allowing their rewards to influence optimization. That sequence prioritizes discovering whether the model solves my problem before investing in reproducing its entire training system. The durable contribution. My strongest takeaway from Occamy is not a particular leaderboard position. It is a way to frame agent learning: the unit of work is an obligation carried through a changing world, not an isolated response. Memory compression, tool errors, delegation, and verification are therefore part of the learning problem—not merely wrappers around it. For embodied-AI researchers, the opportunity is to borrow that execution discipline without overstating the demonstrated transfer. A digital workflow result is not a robot result. But the question it raises is directly relevant:. When an agent says the job is finished, what evidence connects that statement to the world?. Occamy makes that a productive question to ask about training data, optimization, infrastructure, and evaluation together.