The next AI-agent test: what can it do, and what can it touch?
Why a capable model needs a carefully designed operating environment—and how to evaluate one without being an engineer.
CryptoXAI Editorial · Published 2026-09-08 · Expanded 2026-09-10 · 5 min read · Source-based analysis, AI-assisted
Match actions to acceptance tests
Proposed controls; verify whether a specific product implements them.
| Stage | Successful outcome | Failure case to test |
|---|---|---|
| Read | Uses authorised records | Missing or conflicting information |
| Propose | Shows the change and assumptions | Instructions embedded in a document |
| Execute | Acts within granted scope | A request exceeding its authority |
| Verify | Checks the destination outcome | Lost confirmation or duplicate request |
A development worth following
Anthropic’s May 2026 engineering account of containment describes different environments for different products. Its discussion of Claude Code highlights the usefulness—and the responsibility—of access to a user’s filesystem, shell and network. This is an architectural issue that applies beyond one model vendor.
Meanwhile, Google’s 1 September roundup describes its August AI releases, including Gemini 3.7 Flash and Gemini 3.5 Transcribe. More capable and specialised components broaden what teams can build. Our interpretation is that product evaluation must now examine the surrounding workflow as carefully as the model announcement.
Read, propose, execute
Imagine an assistant reviewing an invoice. Reading the invoice, drafting an accounting entry and sending a payment are three distinct levels of authority. A useful product makes those transitions visible. The same principle applies to code: explaining a patch is different from modifying a repository, which is different from deploying it.
This three-level distinction is our evaluation framework. It is not a claim that every current tool exposes the same controls. Before adopting one, ask for a demonstration of the exact action you care about, including how it requests authority and how the action appears in the activity record.
- ReadInspect only the authorised inputs
- ProposeExplain the intended change
- ExecuteApply within granted permissions
- VerifyCheck outcome and retain an audit trail
What the demonstration should include
Ask the operator to supply an incomplete request, a conflicting instruction and an unavailable dependency. Does the system stop with a useful explanation, ask for the missing fact, or silently invent a successful outcome? The failure path often reveals more about operational quality than the polished example.
For a reversible action, ask how to undo it. For an irreversible one, ask what confirmation and limits apply. Check whether the system can distinguish content it is reading from instructions it is authorised to follow. None of these questions requires believing that a model can be made infallible.
Measure useful autonomy
Define a completed task in advance and count the interventions needed to reach it. Include review time, retries and abandoned attempts. A workflow that completes ten tasks with one inspection each may be more valuable than a spectacular autonomous run that cannot be reproduced.
For buyers, the next step is a small trial with bounded permissions and representative inputs. For builders, the opportunity is to turn model capability into a dependable experience: clear boundaries, visible progress and recoverable errors. More intelligence helps; it does not remove the need for product engineering.
Worked example: an agent processing an invoice
Consider a hypothetical agent that receives an invoice and is asked to prepare it for payment. Break the job into reading the document, matching it to a purchase record, drafting an entry and requesting the final action. At each step, specify the allowed information and the condition for moving forward. This is a design exercise; it is not a description of a tested vendor product.
A missing purchase record should produce an explicit exception, not an invented match. A changed bank detail should be treated as a separate verification problem. An instruction written inside the invoice should be treated as content to inspect, not as authority to change the workflow. Define these behaviours before showing the agent a polished successful example.
Now ask the system to explain what it did and what remains pending. The answer should distinguish a prepared payment from an executed payment. It should also point to evidence of the outcome. A confident message saying done is not a substitute for an observable result in the destination system. That distinction matters even when every individual generated sentence looks plausible.
Design the failure tests before the demonstration
Build a small evaluation set with ordinary tasks and deliberately awkward variations. Include missing information, contradictory records, an unavailable dependency, duplicate requests and a request outside the authorised scope. Keep the variations realistic: the objective is to learn how the workflow handles foreseeable problems, not to create an impossible riddle.
For each case, write the expected safe and useful outcome. Sometimes that is completion; sometimes it is a well-explained hold. Count a justified hold differently from an unexplained failure. Otherwise the evaluation rewards systems that always attempt an action and penalises systems that correctly identify missing authority or evidence.
Repeat some requests to examine duplicate handling. If the first attempt may have succeeded but its confirmation was lost, the system needs a way to establish the existing outcome before trying again. Ask the builder to demonstrate that behaviour. Do not assume it exists because the model can describe idempotency in an answer. The product must implement the relevant checks.
A practical acceptance scorecard
Measure task completion against written criteria, intervention count, review time and observable unwanted actions. Use critical constraints as pass-or-fail gates. An agent that saves time on nine cases but performs an unauthorised irreversible action on the tenth has not earned approval through a high average score.
Record the exact configuration: available tools, permitted actions, data scope and any human checkpoints. Those details are part of the system being evaluated. A product with no write access and the same product with broad execution rights do not present an equivalent test. Model names alone cannot describe the risk or usefulness of the whole workflow.
In a fictional pilot, ten correctly prepared records with ten brief reviews might be preferable to twelve automatic attempts requiring extensive investigation afterwards. Do not compare those counts without measuring review and correction effort. Decide in advance whether your objective is more completed work, lower effort, faster turnaround or a combination, then report the tradeoff.
How to expand autonomy responsibly
Start with one bounded workflow and a clear owner for exceptions. Expand access only when the next task requires it and the tests cover the new actions. Moving from reading to writing changes what must be verified. Moving from a reversible draft to an external commitment changes the recovery options again.
Keep a record of inputs, decisions and final outcomes that is useful for reviewing a mistake without exposing unnecessary sensitive information. Define how a person pauses the workflow and how pending work is handled. A practical agent product should make those controls understandable to its operator rather than relying on an engineer to inspect hidden state.
The purchase decision should therefore ask two questions together: can the system do the work, and can your team understand and manage what happens when it cannot? This framework does not promise perfect safety or validate any specific vendor. It provides a reproducible way to turn an impressive demonstration into evidence about a real operational task.
Sources & method
Linked sources support the documented facts. Evaluation frameworks are CryptoXAI analysis; hypothetical examples are labelled. No hands-on benchmark results are claimed. An expansion date records an editorial change, not a new verification of every source.