The Next Frontier Is Earned Autonomy.

01 / What makes a workflow agentic?

An agentic workflow uses an AI model to decide some of the next steps toward a goal, based on information gathered along the way. The surrounding application supplies tools, permissions, state and stopping conditions.

In a fixed workflow, code determines the route: look up the account, check eligibility, calculate a quote, request confirmation. An LLM might extract the customer’s request or write the reply without controlling that route. In an agent loop, the model can choose to inspect a contract, ask a clarifying question or use another tool before deciding what to do next. OpenAI’s 2026 explanation of the Codex agent loop shows how tool results feed into subsequent model decisions. [1]

Real applications can combine both. The agent might investigate an unusual request while ordinary application code enforces which account it may access and which subscription changes are permitted.

For the seat-expansion example, flexibility could help reconcile an email, an account record and an unfamiliar contract clause. It would add little to a calculation whose inputs and rules are already known. Start by identifying which decision needs interpretation.

This makes AI agent architecture a question about where judgment belongs. A bounded agent inside a dependable workflow can be a deliberate design choice, even when a more open-ended system is technically possible.

02 / Find the promise hidden inside the process

“Complete the upgrade” is an incomplete goal. Spend time with the people who sell, provision and support the product. Ask them to walk through a routine expansion, an exception and a case where an apparently helpful action created work for someone else.

What does the customer need by tomorrow? Additional paid seats, temporary access, or help assigning seats they already own? Who can authorize a change? Which agreement takes precedence over the standard checkout policy?

The best outcome might be discovering unused seats and getting the team ready without an unnecessary purchase. An evaluation that rewards every completed expansion would mark that useful judgment as failure. Understanding the customer’s intent changes what progress looks like.

Those questions can change the architecture. If an authoritative entitlement service already answers whether a change is allowed, call it. If the business has never agreed how to handle an exception, another reasoning step cannot settle that disagreement.

In this proposed workflow, define four things before delegating:

• The customer outcome: the intended people receive the access they need, under the agreed terms.
• The evidence: verified account authority, current entitlements and the applicable agreement.
• The boundary: which changes the system may make and which need confirmation or a human decision.
• The unacceptable outcome: an unauthorized commitment, a wrong-account change or access promised but never provisioned.

Have domain experts review examples where a small contextual difference changes the right action. Record their reasoning, including disagreements. This is how a business-specific evaluation starts to acquire meaning before production provides feedback.

The words in the request can stay identical while the correct outcome changes. That is why a general benchmark score cannot decide how much authority this particular workflow should receive.

03 / Make the architecture earn its complexity

Compare a fixed workflow, a single agent and a multi-agent system as candidates for the job. Each changes how work is coordinated and where mistakes can occur. More components need a specific reason to exist.

A fixed workflow is a useful starting point when the steps are known. A single agent can investigate a request whose next useful action depends on what it discovers. Multiple agents may help when work can be separated into useful investigations with clear responsibilities.

Anthropic’s research-system report describes benefits from parallel investigations, alongside token costs and coordination challenges. That is evidence for an architecture suited to open-ended research. It does not establish that delegating each billing step to a different agent will improve a customer workflow. [2]

The April 2026 version of Towards a Science of Scaling Agent Systems compares 260 configurations across six benchmarks, five architectures and three model families. Its results vary with task and coordination structure; some multi-agent configurations help, while others degrade performance. The study is a preprint, and its benchmark tasks do not choose the architecture for your application. [3]

For our example, a useful experiment might give a single agent freedom to investigate the customer’s agreement while retaining a fixed authorization check before any change. A second experiment could test a separate contract-review step if the first setup consistently misses exceptions.

State what the extra component is meant to improve. Keep the cases, quality criteria and available source information comparable. Account for additional calls, latency and review work. If the model, prompt and orchestration all change, report a comparison of complete setups; do not attribute the result to agent count alone.

The same discipline applies to prompt engineering, tool selection and the agent harness: the code that manages execution, state and retries. Choose the intervention that addresses the observed failure, then test whether it does.

04 / Evaluate the decision to act

An agentic workflow needs an evaluation of both the finished work and the decision to attempt it. A system that escalates every request avoids some mistakes by handing the entire job back to people. A system that completes every request may be ignoring the conditions that make completion legitimate.

Build cases on both sides of each important boundary. For the upgrade, include an authorized request with standard terms, a missing purchase order, unclear account authority, and a customer who already has enough seats. Include ordinary successes as well as difficult exceptions.

For each case, specify the allowed next step and the expected resulting state. Run candidates from the same starting conditions in an isolated environment, resetting tool state between attempts. Repeat trials to observe variation. Anthropic’s 2026 evaluation guide distinguishes the agent’s transcript from the outcome in the environment and explains why multiple trials matter. [4]

For cases with an established act-or-handoff decision, report unauthorized actions against cases that required a handoff, and avoidable handoffs against cases the system was allowed and expected to complete. Separately check whether permitted actions actually achieved the requested result. Include the number of cases and repeated trials behind each rate. Grade necessary clarification against its own expected next step; it is not an avoidable handoff.

This keeps delegation measurable without rewarding indiscriminate completion. A clean result on a small sample is limited evidence; repeated runs of one case do not create broader business coverage. Retain fresh cases that have not guided changes to the system.

Use deterministic checks for account changes and expert-calibrated judgments for the explanation and handoff. Our AI agent evaluation guide covers constructing the wider experiment. Here, the decision is specific: which responsibility has this setup earned?

05 / Put the boundary in the system

Suppose the evaluation supports letting the agent handle standard seat additions. That permission still needs to exist in the application. A prompt saying “follow account policy” is insufficient as an access-control mechanism.

For this example, the mutation tool should check current authority and agreement conditions before making the change. The harness should limit retries and stop when the necessary evidence is unavailable. Those controls remain in place even after the model performs well in testing.

Anthropic’s October 2026 report on unintended actions describes cases where Claude worked around restrictions while pursuing tasks during evaluations and internal use. The reported cases had minimal real-world impact, and they are not a general failure-rate estimate. They make a narrower point relevant here: persistence can cross the boundary of the intended task. [5]

Test what happens when the workflow is blocked. Does the agent ask for the missing purchase order, or try another route to change the subscription? Does a retry create a duplicate expansion? Does it claim success before provisioning is confirmed? Our tool calling guide follows these effects beyond the API response.

A handoff also needs a useful outcome. Pass along the verified account, the customer’s goal, the unresolved condition and the work already done. Measure whether a person can continue without starting over.

Autonomy is a decision about which responsibilities the system has earned, under which conditions.

Evidence may justify expanding one responsibility and narrowing another. A model upgrade should reopen that question rather than silently inherit every permission its predecessor held.

06 / Build the capacity to recognize progress

After release, production traces and actual customer outcomes test the assumptions behind the workflow. A new contract term may reveal a missing case. A successful clarification may show how to resolve an ambiguity with less effort.

Use reviewed examples to propose changes to the prompt, tools, model or harness. Evaluate the candidate against the baseline, check regressions and release it under the team’s agreed conditions. Automation can carry out that cycle once the acceptance rules and rollback path are established. It should not quietly rewrite the rules to pass its own test.

Keep the evaluation version fixed during each comparison. Expand it between experiments as the business learns. A production incident used to design a fix becomes development evidence; preserve it as a regression case and seek fresh evidence before claiming broader improvement.

There is a longer-term asset here: the business’s understanding of its own work. A resolved disagreement about a customer outcome can become a reviewed criterion and a case that tests it. That knowledge can outlast the current model or framework, provided its assumptions stay explicit and are revisited when the business changes.

Check the business effect after deployment too. Correct provisioning is an observable task outcome. Higher retention is a later outcome with other causes. Use controlled comparisons where feasible to investigate whether the workflow change helped, and include the work transferred to customers or employees.

We believe evaluation is part of the path toward artificial general intelligence. That is a research conviction: increasingly capable systems need increasingly meaningful ways to distinguish progress from persuasive behavior. Evaluation alone does not establish AGI, and a passing score is only as useful as the task and standard behind it.

For BENCH, that conviction starts close to the customer. Understanding what a business promises, discovering where that promise breaks and testing better ways to fulfill it gives improvement a direction. General capabilities create possibilities; business-specific evaluation helps decide which possibilities are ready to become responsibilities.

The system remains probabilistic. Customers, policies and tools keep changing. The process can improve our decisions over time, while individual changes can still fail.

Choose one decision your AI agent makes today. What evidence would justify letting it make that decision tomorrow?