What an agent platform takes responsibility for: five approaches to one business task

Can a helpful answer become a complete business task?

An AI system reads an internal inquiry and suggests the right department. Yet the employee still opens the ticket system to find out whether the reviewed proposal was saved. Is the missing capability better writing, reliable saving, or a clear handoff after review? Platform selection needs to distinguish these problems.

This is a hypothetical scenario for examining mechanisms, not a company's deployment result. Primary material from OpenAI, Anthropic, Microsoft, Google, and AWS available by May 7, 2026 describes different scopes: SDKs that invoke models, and services that manage execution, permissions, registration, or evaluation. The label “agent platform” does not make the purchased capabilities or remaining development identical.

My priority is whether judgment, review, saving, and failure investigation connect into one business task. Alongside model comprehension, I want to know whether the adopting team can maintain the remaining work. The five vendors' announcements make that question concrete.

OpenAI: what remains when an SDK assembles execution?

OpenAI's April 15 Agents SDK expansion covers the mechanism connecting model instructions to tool execution and an isolated workspace. It describes holding execution state externally and carrying a workspace forward through snapshots. Python comes first; TypeScript support and other additions are planned.

For the inquiry task, the SDK helps assemble reading, proposing, and invoking tools. But which department handles a contract question, and whether this user may change this case, are company rules. Saving a workspace does not establish that the department is correct or that the ticket update succeeded.

This approach allows the team to tailor execution to existing APIs and review screens. It also leaves the team maintaining tool connections, save verification, and checks after changes. Evaluate that implementation burden alongside the SDK's flexibility.

Anthropic: keeping execution running and verifying completion

Anthropic's November 26, 2025 long-running harness account addresses lost progress and premature completion claims in web application development. It describes an initial feature list, subsequent work on individual features, progress notes and Git history, and checks through the actual interface. This is the company's development example, not a comparative experiment proving success across every business task.

The relevant lesson is that preserving a long conversation does not establish what is done. Inquiry processing also needs to distinguish proposed, awaiting review, and saved. Otherwise a person rereads the history. Progress linked to actual results can reduce the need to reconstruct what an earlier run did.

The April 8 Managed Agents architecture account separates sessions containing event history, the harness operating models and tools, and the sandbox. It treats replacement of an execution environment separately from retention of history. Retained history alone does not prove a connected ticket was updated correctly.

Even when a managed service carries execution forward, the adopter defines business completion. A human taking over after interruption needs saved results and unresolved operations alongside the latest proposal. Responsibility remains for connecting continued execution to completed work.

Microsoft: combine judgment with fixed steps and intervene before action

On April 3, Microsoft announced Agent Framework 1.0 for .NET and Python. It lists agents using models, workflows combining functions and branches, checkpointing, and execution middleware among stable features. The same announcement distinguishes preview integrations for managed hosting and evaluation in Foundry.

This combination can place interpretation with the model and case matching or review before saving in defined steps. Compare how a candidate combines flexible judgment with conditions that must hold on every run. A stable SDK release does not establish the stability of every connected service.

The April 2 Agent Governance Toolkit announcement describes separately adoptable packages for pre-action policy checks, identity, and execution management. They connect to extension points in existing frameworks, placing controls outside model instructions.

A place to write policy does not enforce it unless the path to the business API actually passes through the check. I would test a forbidden case through the intended connection and verify that no save occurs. The announcement cited here is not evidence that this article tested that connection or enforcement across every path.

Google: bundle building with operational improvement

Google's April 22 Gemini Enterprise Agent Platform announcement groups capabilities into building, scaling, governing, and optimizing. It describes identity, a registry, a gateway, simulation, evaluation, and observability alongside execution. Management after development becomes part of the product comparison.

Integrated management and connections are worth examining for teams operating several processes. Yet a registry concerns available assets, identity concerns who acts, a gateway concerns connections, and evaluation concerns results. Even inside one product, these answer different questions.

I would trace a single ticket through the proposed department, reviewer, destination, and saved result. Connected records can show the employee where to investigate. The announcement's assurances about safety and outcomes are vendor statements, not measurements of correctness across a customer's existing APIs or of investigation time.

AWS: distinguish publication approval, action permission, and scoring

AWS's April 9 Agent Registry preview records ownership, capabilities, and invocation information for agents and tools. It describes draft, pending, and approved records becoming discoverable within the organization, together with versions and deprecation. Approval to publish an available asset serves a different purpose from approval to update a particular ticket.

AgentCore Policy, generally available from March 3, places policy outside agent code and checks requests at an associated Gateway. Here the question is whether a connected tool may execute. Adopters need to establish which operations traverse that path and how case-specific permissions at the destination are handled.

The March 31 AgentCore Evaluations general-availability announcement distinguishes online scoring of sampled production traces from on-demand testing of changes. It describes reference answers, expected tool sequences, and custom scoring. Scoring can inform improvement; it serves a separate purpose from refusal before action.

These distinctions explain how an organization-approved agent can lack permission to modify a case, while a permitted action can still use an incorrect classification. Keeping approval, permission, and quality separate helps locate the fix. Treat the Registry's planned automatic indexing and operational-data integration separately from capabilities available in preview.

Return the comparison to one inquiry

With the product scopes clearer, map the hypothetical ticket process onto each candidate configuration. The comparison concerns where necessary processing happens, rather than shared feature names. The following four items are an analytical decomposition, not a common product specification.

Reuse case matching or approval in the existing ticket system when it meets the need. Deciding what moves to the new platform and what stays makes development requirements clearer. Connecting reviewed content to saving also requires handling changes to the case or content between those steps.

This does not require splitting the task into four services. One existing API may satisfy several conditions. What matters is which records a person can consult to decide the next action when processing stops.

Score model mistakes separately from infrastructure failures

Record an incorrect department, an unauthorized update, an unavailable destination, and a run ending with an unknown save result separately. A comprehension error needs reference classifications. A permission error needs records connecting the user, reviewed content, and actual update.

Anthropic's agent evaluation guidance distinguishes execution records, final outcomes, and grading limitations. Applied here, a correct department answer is insufficient for ticket-task success: check whether permitted content was saved. Distinguish the end of execution from the presence of the expected result.

To compare models, hold inquiries, tools, permissions, and time or cost conditions constant. To select a product, include the preparation, review, waiting, and investigation its actual configuration requires. One trial cannot unconditionally establish both model superiority and product usability.

I recommend recording how many cases people correct and how many they reconstruct. Accurate proposals can still shift work elsewhere if every save needs checking. This is a proposed comparison method, not a measurement of burden or success rates across the five vendors.

Add the management the task needs

Anthropic's design guidance recommends starting with simple approaches and adding complexity as needed. If an existing ticket system supplies approval and audit functions for one department, first test whether an SDK with a restricted API connection meets the requirements.

Sharing processes across departments, running longer tasks, and involving more teams can strengthen the case for centralized identity, registration, and execution records. Purchasing centralized management still leaves maintenance: department rules, connected-system changes, reviewers, and scoring criteria need updates.

Compare model and execution charges together with connection development, permission configuration, record storage, scoring, and human investigation. Identify which work a managed service can remove and which remains with the adopting team. Then select a configuration the responsible people can maintain.

Choose a platform by the responsibility you can maintain

The five vendors' material provides concrete comparisons of SDKs, long-running execution, fixed procedures, managed services, and evaluation. Similar feature lists do not establish equivalent implementations or business outcomes. They also do not show that model performance has become unimportant.

If the system misunderstands an inquiry, improve the model, input, or routing rules. If it understands correctly but leaves the save result unknown, fix execution and destination verification. If the acting user's authority is untraceable, reconsider how identity connects to permission. These distinctions help the employee experiencing the failure choose the next improvement.

My recommendation is to trial one complete task and identify the platform's processing, the existing system's guarantees, and the adopter's maintenance responsibilities. Start with useful answers, then build a configuration that also lets people establish results and decide what happens next when execution fails.