AI agents in 2025: what changed the work we can delegate?

Looking back at 2025

What turns a working prototype into work we can delegate?

An AI opens websites, gathers material, and writes a comparison report. On screen, the job appears finished. Before publication, however, the reviewer discovers that unavailable sources have disappeared from the comparison and product claims have blended into the author's judgments. In this hypothetical example, the remaining work includes repeating the research, as well as editing the prose.

During 2025, browser operation, external connections, SDKs for iterative execution, and products for editing and evaluating procedures became more concrete. This article compares their official announcements and specifications to ask which parts of a job became easier to assemble. It does not infer adoption rates or whole-job success rates from the number of announcements.

My conclusion is to define delegation from “what would count as finishing this job?” alongside “what can the agent do?” More components for action and connection make it possible to produce different outputs: collected sources, a draft, and a published report. Accounting for the gaps between them, and the effort people spend checking again, helps identify which part to delegate next.

Actions and handoffs

Browser operation expanded where a job could begin

The January 23 Operator announcement introduced a research preview that sees and operates a browser. It offered a route through screens and forms on sites without an API. It also described handing control to users for logins, payment information, and CAPTCHAs, and requesting confirmation for important actions.

This gives us a reason to distinguish screen interaction from completing a job unattended. In the report scenario, an agent might read public material but wait for a person to log into a members-only site. If it proceeds as though the missing material does not exist, the later comparison will be incomplete. The interface needs to distinguish waiting for a person from either job failure or the absence of a source.

A handoff can provide an opportunity for the user to decide whose credentials to use and which actions to allow. Its significance goes beyond incomplete automation. But if each handoff forces the person to start investigating again, delegation may offer little benefit. Whether the system can explain what it obtained and where it is waiting becomes part of the practical comparison.

Common connections

Separate the connection from the meaning of its result

The April 9 A2A announcement presented a design and draft specification for discovering capabilities and exchanging task progress and artifacts. The MCP tools specification dated June 18, 2025 covers tool calls, results, and structured output. Handing work between agents and connecting an agent to data or functions are related but serve different purposes.

A common connection method may reduce the work of building communication separately for each provider. Yet two search services returning identically named fields need not offer the same source versions, visibility, or failure behavior. When changing the report's search provider, we should establish whether an empty result means no material exists or access was insufficient.

The MCP tools specification distinguishes protocol errors from errors returned during tool execution. Receiving a response therefore cannot, by itself, establish that the job finished. For this report, I would retain unavailable sources alongside the retrieved text and citations. That is an output requirement proposed here; a shared protocol does not guarantee a complete comparison report.

Models and iteration

Choosing the next action meets a mechanism for checking again

The August 7 GPT-5 developer announcement described custom tools that accept text rather than only JSON, with grammars to constrain the format. The September 29 Claude Agent SDK article described a gather, act, and verify loop, together with mechanisms for using files and commands. Both the operations a model can express and the implementation that repeatedly executes them affect how a job is assembled.

For a report, iteration can help identify a paragraph with inadequate evidence, find another source, and revise the draft. It allows a return to missing information beyond a single generation. But repeated execution cannot establish correctness if the verifier repeats the same misreading or accepts a plausible explanation as evidence.

We should therefore separate conditions that can be checked by a defined procedure, such as the existence of a source or agreement of numerical values. A model may interpret the material without being allowed to invent an unread value. An SDK can create opportunities to verify; it does not determine whether the verification target and acceptance criteria are right.

This comparison cannot support the conclusion that model capability no longer matters. A sound procedure will not help enough if reading, planning, or tool selection is inadequate. Conversely, changing the model does not establish how to record which sources were used and what was checked. Capability and implementation both need evaluation on the same job.

Building and checking changes

Visible procedures offer more places to investigate an error

The October 6 AgentKit announcement presented visual procedure building, versioning, and evaluation using execution traces. Its components had different availability: ChatKit and Evals were generally available, while Agent Builder was in beta. The November 25 Foundry multi-agent workflows announcement introduced a public preview connecting steps through diagrams, YAML, variables, and structured output.

Both announcements make procedures and their execution more concrete objects to build and inspect. They do not establish identical implementations or observation coverage. Foundry describes its initial observability release as focused on individual Foundry agents within the workflow. A visible diagram does not establish that the state of every external source and publication destination can be inspected together.

A trace showing “search, write, review” in the expected order provides a starting point for diagnosis. We still need to establish whether search used outdated material, writing omitted a condition, or review returned to the cited source. Following the intended path and producing a correct comparison should have separate acceptance criteria.

Versioning requires the same distinction. Restoring the procedure's version will not reproduce the previous draft if external sources have changed. Comparisons before and after a change should hold inputs and source material constant, alongside the procedure. A visible process helps judgment without automatically selecting the conditions judgment requires.

Constraining execution

Check permitted actions separately from useful results

The December 2 preview announcement of AgentCore Policy and Evaluations illustrates this distinction. Policy applies conditions outside agent reasoning to tool calls through an associated Gateway. The refund example checks a role in the authentication context and an amount below 200. The Gateway configuration also distinguishes enforcement from logging only.

Meeting those example conditions does not establish that the order qualifies for a refund or that the customer and amount are correct. Conversely, a well-written refund explanation does not confer execution permission. Conditions for allowing an action need to be distinguished from conditions for judging its content correct.

Evaluations in the same announcement describes built-in and custom quality checks on traces, sessions, and other evaluation units. It also describes sampling executions at a configured rate. A mechanism for examining quality trends cannot establish that every action was authorized beforehand. In the report scenario, a draft quality score should not substitute for permission to publish a particular version to a particular destination.

Connecting the scenario

Make source collection, drafting, and publication separately finishable

We can apply these developments to three stages of the comparison report. This is neither a proposal to combine every product nor a measured deployment success. It is a design example that makes the end of each delegated task concrete, regardless of the components selected.

Delegating source collection alone may reduce human effort. Its output is useful if the reviewer can return to evidence, understand the gaps, and begin comparing directly. If a polished draft requires finding every source again, the job has advanced less than its apparent progress suggests.

I would examine that difference before expanding delegation to drafting and publication. Verifiable intermediate outputs allow a return to the stage where an error appeared. Delegating the whole process at once also needs comparison on the effort required to discover where corrections should begin when an error is found at the end.

Deciding what to delegate next

Choose by the work remaining after review

A comparison should use the same request and sources, with the existing human process or a fixed procedure as a baseline. Examine the share of publishable outputs, whether missing evidence was detected, and the time people spend correcting and researching again. Include retrieval failures, ambiguous requests, and source updates. This investigates where effort decreases rather than assuming that a narrower task must be faster.

The 2025 material supports a conclusion that options for implementing action, connection, iteration, construction, evaluation, and restrictions increased. It cannot establish industry-wide adoption success or an end to model competition. Where an existing procedure is sufficient, declining to add another component remains an option.

For this report, the first objective would be to provide material that lets the reviewer proceed without repeating the research, rather than to run unattended to the end. Once that condition is met, delegation can expand to drafting and publication. Turning a year's developments into better work depends on verifying that the output advances a person's next decision, beyond counting the features available.