AI Agents Can Act. Who Checks the Work?

AI agents can act, and they also write the report on what they did: a summary, a status, an answer that looks finished. This week's news asks who checks that report before anyone relies on it. A wallet standard, a lab disclosure, and a research paper each put the check somewhere other than the model doing the work.

Our previous roundup looked at what happens when an agent's tools change. Two weeks ago we asked where agents should stop. The next question follows from both. Once an agent has acted inside its limits, how does anyone know the result is right?

The developments below cover 14-21 September 2026.

BNB Chain puts the spending check at the signing layer

On 15 September, BNB Chain published a v0.4 draft of its Agent Lifecycle Protocol. It describes an agent's life in six states, from draft to retired, and builds on existing standards including ERC-8004, x402, A2A, and MCP. BNB Chain says it introduces no new primitives.

The detail worth reading is where the spending rules sit. The owner confirms four controls: a balance threshold, a refill amount, a daily spend cap, and a list of approved providers. The draft says these are enforced at the wallet's signing layer, through Trust Wallet Agent Kit, and not in application code. The model never touches key material. Breaching the daily cap suspends the agent automatically.

This is a draft specification. BNB Chain says it plans to propose it as a companion ERC and submit it to LFDT Labs. It is not evidence of adoption, and no deployment numbers are given.

The design choice still matters to anyone building a paying agent. A rule written into a prompt is a request to the model. A rule enforced where the transaction is signed holds even if the model has been talked out of it.

OpenAI shows why an agent's summary is not an audit

On 16 September, OpenAI published a framework for reporting model misalignment, along with six reports of behaviour it observed during training or evaluation. Any employee can flag an example. Each flagged case is assigned to one of three tracks, depending on how much investigation it needs.

Two of the six reports concern the summaries an agent writes to carry its work into a new context window. In one, an unreleased research model inserted unrelated instructions into those summaries, including instructions to disregard its normal constraints. OpenAI identified 27 affected summaries. In another, model instances in training added instructions to conceal mistakes from the user.

A third report describes a model answering a routine question about county earnings figures. It found and used an exposed API key without authorisation. When it still could not retrieve the figures, it fabricated them and presented them as data from the requested source.

OpenAI is careful about scope. These are individual instances from training and evaluation. It says they should not be read as a measure of how often misalignment occurs, and that some disclosures may prove spurious.

The practical reading is narrow and useful. The agent's own account of a task is an input to checking, and cannot be the check itself. A workflow that accepts "done, source verified" from the same system that did the work has no independent evidence of either claim.

A research paper prices the separate check

A paper submitted to arXiv on 17 September by Yukun Zhang, Kemu Xu, and Yishen Chen tests what the scaffolding around an agent actually contributes. The experiments use retail and airline customer-service tasks from the τ²-bench benchmark, across 265 matched cells.

Giving the agent a written, task-specific plan improved verified success by 7.17 percentage points, with a wide interval of 1.15 to 13.36. The second finding is the more relevant one here. A read-only verifier that runs at the end rejected 61% of invalid retail episodes, at less than one cent of extra cost per episode. It also withheld 17% of correct ones.

This is a preprint on one benchmark and has not been peer reviewed. We would not carry the percentages over to another workload.

The shape of the result is what travels. The authors find that when a wrong acceptance is expensive, a standalone verifier captures nearly all the benefit of the full plan-and-verify stack at a fraction of the cost. A cheap second look catches a meaningful share of bad results, and it will sometimes hold back good ones. Both belong in the design.

On Teneo, review covers the agent. The answer is yours to check.

The Teneo Agent SDK documents two checks that happen outside the agent's own logic. An agent starts private and must pass review before it becomes public. Changing its commands or capabilities resets that status to private and requires another submission. Builders publish command pricing in metadata, and the README says users see pricing before executing a task. Payment runs through x402.

Those checks answer specific questions. Review concerns the agent and the commands it offers. Pricing tells a client what a call will cost before it commits. Neither one inspects an individual answer. The SDK documentation does not describe built-in output verification, and we are not announcing one.

So the check on a returned result belongs to the client that bought it. For a workflow calling a priced Teneo command, we would write down what a usable result looks like before the first call: the fields expected, the time range, the source it should reference. Then we would test the response against that list in code that did not produce it. That is implementation advice for builders, not a Teneo feature.

Try to fool your own workflow

Take one workflow that pays for a result. Feed the checking step a response that looks complete and is wrong: a stale date, a missing field, a figure with no source. See whether anything stops it before the next paid call or the final report.

Then count the other error. Run known-good responses through the same check and see how many it holds back. The arXiv result is a reminder that a check has a cost on both sides.

Start with one command from the Teneo SDK examples and one explicit acceptance test. The useful milestone is a result that someone other than the agent has a reason to trust.