Anthropic reported this week that an early version of Claude Fable 5.2 coordinated more than 1,000 subagents for eight days and produced a prototype operating system from an empty folder. That is a deliberately wide assignment. The model had to plan, delegate, write, test, and keep going. [1]
Three Google releases moved in the other direction. One model scores a defined set of choices instead of writing an answer. One protocol lets an agent arrange registered interface components instead of inventing an application. One engineering experiment sends a model's translation to a constraint solver, then runs the result against real code. [2] [3] [4]
These developments point to the same design problem from opposite ends. Better models can take on more ambiguity. Useful systems still need to reduce that ambiguity before a decision changes a record, sends a message, moves money, or ships code.
The question for an operator is where AI should explore, and where the workflow should force it to choose, show, or prove.
01 / THE RANGE
Capability is widening the assignment.
Claude Fable 5.2 and Mythos 5.2 are Anthropic's new models for ambitious, open-ended technical work. Anthropic says the same underlying model can coordinate smaller models, handle long-running coding and research, and work across engineering and science. Its own guidance is revealing: start most coding and knowledge work with Opus 5.5, then move up or down according to the job. [1]
The operating-system example makes the range visible. Anthropic says the agent team produced a system that booted on a laptop and included storage, networking, windows, login, and installation. That is a company-run experiment with an earlier model version, one harness, and no independent production audit. It still shows how much exploratory work can now fit inside one assignment.
Wide scope can be useful when the path is not known in advance. Architecture, investigation, and early design often require the system to form a plan, revise it, and discover intermediate work. Constraining every move too early would remove the reason to use a capable model.
The mistake is letting that freedom travel unchanged through the rest of the workflow. Exploration and action have different failure costs. A model can consider many approaches while drafting a plan. The step that selects a policy, presents a confirmation, or changes a system needs a smaller and more visible set of possibilities.
02 / THE NARROWING
A decision should expose its options.
Google's Gemini Decisions API is built for closed-set work: yes or no, a choice from two to 255 options, or a score against an ordered rubric. It returns probabilities and a confidence score rather than generating answer text token by token. Google positions it for jobs such as tool selection, policy checks, routing, and grading. [2]
This can make a decision easier to evaluate. A support workflow might choose among a defined set of queues, with an explicit fallback when confidence is low. A purchasing check might score a request against a published rubric before a person approves it. The output has a shape the rest of the system can test.
The boundary does not create truth. Someone still decides which options exist, how the rubric works, and when the system must abstain. If the valid answer is missing, a well-calibrated score can make a bad choice look orderly. Google's latency, price, and benchmark comparisons are vendor-reported and need workload-level testing.
A2UI 1.0 applies a similar idea to presentation. An agent describes a screen, while the host application renders it with registered native components. The model can arrange a form, chart, or confirmation card, but the application controls the components, data binding, and final interaction. Google says nothing is sent in its illustrated multi-app example until the user confirms. [3]
That is more inspectable than a wall of prose or arbitrary generated frontend code. It also transfers responsibility to the component registry, accessibility rules, permissions, and confirmation design. A polished card can still present the wrong options. The interface makes the boundary usable; it does not decide whether the boundary is good.
03 / THE PROOF
Move important checks into another system.
A Google developer experiment offers the most concrete example of narrowing near proof. Gemini 4 Argon translated paths through Go source and RISC-V assembly into constraints for the Z3 solver. When Z3 found a set of bytes that could reach a crash, go test ran those bytes against the real function. The workflow found three planted bugs and three latent bugs in a small linting tool. [4]
The model did not get the final vote on its own analysis. It changed the representation, a solver checked whether the constraints could be satisfied, and the real program reproduced the crash. Each layer handled a different kind of work.
The experiment also states its limits. The model's translation was not a sound proof system. An unsatisfiable result meant “maybe correct,” not proven safe. Once the author extracted pure helpers and adjusted the fuzz target, a short fuzz run caught the same three bugs. The solver model did not cover races or deadlocks.
That is the useful complication. A second system can catch errors that the first one misses, but only inside the problem it was given. The constraint model, test harness, valid options, and interface components can all contain their own blind spots.
A serious workflow therefore gets narrower in stages. Let the model explore where uncertainty is useful. Turn recurring judgments into explicit choices with an exception path. Present consequential actions through known controls. Put the claim that matters into a test, rule, calculation, or review that does not depend on the model agreeing with itself.
What this week's sources do not establish
They do not prove that long-running agent teams are ready for unsupervised production work, that a closed-set model is correct outside Google's tests, that A2UI makes every interface safe, or that one solver workflow generalizes beyond the tested Go functions. Three of the four main sources come from Google, and all four report their creators' own systems. The narrowing principle and suggested experiment are editorial analysis.
04 / PUT IT INTO PRACTICE
Narrow one path from exploration to action.
Choose one recurring AI-assisted workflow that currently depends on an open-ended prompt. Draw four stages: explore, choose, show, and prove. Keep the exploratory part only where multiple approaches are useful. For one later stage, define the valid options, an abstain or exception path, the approved output shape, and an independent check before action.
Run the current version and the bounded version against the same 10 to 20 past or test cases. Record ambiguous outputs, missing options, false confidence, reviewer corrections, time to decision, and any case the boundary sends to a person. Keep the change only if it makes the consequential step easier to inspect without hiding legitimate exceptions.
One workflow. Less freedom near the decision.
Build: A one-page bounded-workflow specification and a 10-case comparison sheet covering exploration, options, abstention, presentation, and independent checks.
Look for: Compared with the current open-ended path, the bounded version reduces ambiguous or wrong-but-plausible outputs and reviewer rework while routing legitimate exceptions to a person.
The goal is not to remove judgment. It is to spend open-ended reasoning where it helps, then make the path to action small enough for someone to inspect.