Start with one request
After connecting tools and specialists, who finishes the request?
Consider a customer asking how to configure a product and what has happened to their order. This is a hypothetical example for comparing the scope a platform manages. Product documents supply the instructions; customer-specific data supplies order status. Alongside model calls, the developer needs search, an order API connection, request routing, and a way to combine the results.
OpenAI’s March 11 announcement of agent-building tools and Amazon Bedrock’s March 10 general availability of multi-agent collaboration make some of that work available as selectable components. Search can run in a service, handoffs can be composed with an SDK, and coordination can be configured within a service. The starting point for development becomes more concrete, although the two vendors assume different responsibilities.
My comparison focuses on who executes each part of a request, rather than the number of named features. Searching documents still leaves the question of whether a customer’s order may be accessed. Routing between specialists leaves the handling of conflicting results unresolved. Breaking down the work makes the value of a managed platform easier to assess.
Search within the service
Delegating search separates connection work from judgments about the material
The Responses API presents web search, file search, and computer use as built-in tools. Web search retrieves external information, while file search looks through supplied documents. Registering product documents for search can reduce the retrieval implementation a developer must build. The application team still chooses which materials to register and when to use them.
For the opening request, public instructions and customer-specific contract conditions should be treated differently. A correctly retrieved procedure for an older product or another customer still produces the wrong answer for this request. Document version, product identity, and access scope need to connect to search conditions and the evidence behind the response. A citation also does not establish that the material applies to this customer.
The reduction is in part of the implementation needed to obtain information. Maintaining documents and determining applicability remain necessary work. In evaluating a search component, examine whether the team can control exclusion of outdated documents and selection conditions alongside retrieval accuracy.
Where screen actions run
Tools in the same API can still require execution by the application
The computer-use tool is described as generating mouse and keyboard actions for execution in the developer’s environment. Being offered in the same API as search does not mean the service hosts the entire environment in which a screen is operated. The application needs to execute actions, obtain the resulting screen, and pass it back for the next decision.
The distinction becomes clearer alongside Operator’s January 23 announcement. Operator provides browser interaction as a research preview for users, with control returned to a person for tasks such as login. Accessing its model through a developer API and receiving the consumer product’s browser and handoff behavior inside an application are different arrangements.
An order system with an API offers that route for integration. A system available only through screens requires the application to handle login state, waiting, and the result of an action. Identify where execution occurs and who observes the result rather than grouping everything under tool calling. This is an initial distinction for estimating the required development work.
Coordination embedded in an application
A short SDK example still leaves refund-request logic to be implemented
OpenAI’s Agents SDK presents components for agent configuration, handoffs, input and output checks, and inspection of execution records. A developer can embed a flow that receives an inquiry and passes it to shopping or support specialists. It is an open-source SDK; it does not host application deployment or customer authentication.
The announcement’s sample leaves the logic inside a refund-request function for the developer to add. Its example return value is a short success string, while the actual business process must be implemented there. That small gap contains work such as finding the order, checking whether a change is allowed, recording the request, and returning evidence of acceptance. A working handoff must be distinguished from an accepted request.
Input and output checks likewise require conditions defined by the developer. Checking response format alone cannot determine whether another customer’s order may be accessed. Execution records help identify the specialist and function called, but evidence of a change to the correct order is also needed from the business system.
Coordination within a service
Bedrock separates consolidation from direct routing
Amazon Bedrock’s general availability release describes a supervisor that decomposes complex requests, assigns work, and combines the results. Its supervisor-with-routing mode sends simple requests directly to an appropriate specialist, returning complex or unclear requests to full coordination. Handling this coordination as service configuration differs from composing it in an application SDK.
A question about instructions alone can follow a route to a document specialist. A question combining instructions and order status needs results from both sources. Independent retrieval may run in parallel, while an operation requiring identification of the order first may need to wait. Splitting the work and choosing its correct sequence need separate tests.
The release includes interfaces for inspecting interactions and records of execution substeps. These support investigation of coordination; they are not comparative evidence that an internal support request necessarily becomes faster or more accurate. If overlapping specialist descriptions produce misrouting, the application team must revise those descriptions and the execution path.
Reading roles through research
Managing conversation and progress does not settle the business answer
The original AutoGen paper describes building applications through multi-agent conversation, combining human input and tools. The original Magentic-One paper uses an Orchestrator with a ledger of facts, guesses, and plans and a ledger of progress and assignments, coordinating specialists for browsers, files, and code. These provide a way to understand division of work, without establishing a platform’s performance or a universal arrangement for every task.
In the support example, suppose the document specialist says the delivery address can be changed while the order specialist reports that shipment is complete. The team must establish which order states the document’s change conditions cover and when the order information was updated. Adding an integrator does not settle that answer. Smoothing a mismatch into a fluent sentence hides what remains unverified from the user.
Division of work should have a reason beyond increasing agent count. Use it where separating materials, APIs, or permission to change data serves the task and the results can be checked against one another. Keep conversation-management features separate from the conditions for establishing an answer to the customer’s request.
Connecting existing business processes
A managed platform can also return an operation to the application
Bedrock’s April 2024 announcement describes returning control to the calling application as an alternative to executing an action through Lambda. Its customer-settings example also shows the application providing the function’s result. Existing integrations and business processes can therefore remain in use without moving every operation into a new platform.
The November custom-orchestration announcement additionally describes defining execution logic in Lambda. Using service-provided coordination can coexist with an organization defining the order of operations. Allowing the model to choose every search, check, and update on each occasion is only one implementation choice.
For an order inquiry, the business system should establish the relationship between the person and order, the permitted access scope, and the state in which a change is allowed. A customer name generated by the agent should not become verified identity by itself. If an API fails, return a distinction between an accepted request and an unconfirmed result. This lets the user understand evidence for the document answer separately from progress in the order process.
Bring the choice back to one job
Compare reduced implementation and remaining judgments through the same request
Building effective agents describes beginning with simple arrangements and choosing predefined paths or model-selected actions as needed. A question satisfied by document explanation alone does not inherently require multiple specialists. Separating roles or processes becomes useful when their data and permission to make changes differ.
Processing delegated to a service
Identify the search and coordination delegated, the feature used, and the location where it runs.
Processing implemented in the app
Include screen actions, external APIs, identity checks, and outcome records, including logic omitted from SDK examples.
Results returned to the user
Separate answer evidence from order state and retain uncertainty. Evaluate the effort spent reinvestigating.
For selection, test normal answers, outdated documents, disagreement between specialists, and order-API failure using the same documents and order data. Record what the platform handles, what the application supplies, and what a person repairs. Compare response time and usage alongside that breakdown. Differences in model or configuration should not become conclusions about coordination alone.
The March releases expand the choices for delegating development work. Delivering their value to users requires recognizing the work that remains after implementation is reduced. Connect retrieval, coordination, external execution, and outcome verification through a single request. A platform whose responsibilities can be explained provides a path from richer components to a usable service.