Multi-agent research: dividing work that leads to one usable report

Combining work into one report

Does divided research reduce the work of reaching a conclusion?

Several AI participants research energy-efficient models. One collects training energy measurements; another collects inference measurements. Both return sources, but placing the numbers together does not create a valid comparison. This is my hypothetical design example. Faster collection brings the report no closer to completion if the user still has to discover the difference in measurement scope.

Semantic Kernel’s May 27 announcement presents a framework for implementing sequential, concurrent, conversational, handoff, and dynamically coordinated multi-agent work. Azure AI Foundry Agent Service becoming generally available and the Responses API updates also add components for connecting tools and following longer tasks. Using them requires defining dependencies before choosing how many participants to add.

I propose dividing independent collection, preserving comparison conditions through handoffs, and returning work for additional evidence when integration exposes a gap. The value of several participants cannot be measured by the number of outputs. It should be assessed by the research, checking, and correction a person needs before reaching one usable judgment.

Sequence and concurrency

Starting together does not help work that needs an earlier output

Semantic Kernel illustrates sequential processing with document summarization, translation, and quality assurance. Each participant receives the preceding output. In concurrent processing, several participants independently handle the same input and their results are collected, providing different proposals or perspectives. These are descriptions and implementation patterns, not an experiment comparing time or quality on the same document.

For the opening report, separate primary sources can be searched in parallel after target models and measurement scope are defined. Comparison calculations wait for the necessary values and conditions. Prose review follows the connection between conclusions and evidence. Starting all participants together cannot give a writer a comparison that does not yet exist.

A sequence alone is also insufficient. If a summary omits measurement conditions, translating it and checking its grammar will not recover them. Participants need access to the original and outputs must retain the information subsequent work requires. Execution order and handoff content belong in the same design.

Changing the path during work

A missing fact can require returning to collection instead of moving forward

The same announcement illustrates Magentic orchestration with a report comparing machine-learning models’ energy efficiency and CO₂ emissions. A manager assigns research, delegates analysis to a coding participant, and coordinates repeated research and computation as needed. It describes work whose complete path cannot be fixed at the start. The example is not a measured demonstration that the resulting energy comparison is correct.

The underlying Magentic-One paper uses a task ledger and a progress ledger. The former organizes known facts, guesses, information needed, and a plan. The latter selects participants and checks progress. Stalls can trigger replanning. Compared with a list of role names, this design can change the next action based on what has been learned.

A manager can still make a wrong judgment. Declaring completion with missing evidence or repeating the same search can increase review burden as more participants are added. Conditions for returning to research, limits on attempts, and reporting absent evidence must be defined. A fixed sequence may be easier to inspect when the sources and processing are already known.

Managing tools and execution

Separate reading and changing data through the actual tool connections

Microsoft’s May 19 Developer Essentials announcement describes knowledge tools and action tools alongside Foundry Agent Service’s general availability. Connections retrieve information from systems such as SharePoint and Azure AI Search or execute work through Logic Apps and Azure Functions. Tracing, evaluation, and monitoring are also development and operating capabilities.

In the hypothetical report, a researcher only needs to read sources. A drafting participant may need to write to a working document. Updating the publication destination can have a separate permission. This is my proposed design, not a claim that Foundry automatically derives permissions from role names.

More tools introduce different places for errors. Returning an inaccessible document, an empty search, and a failed calculation under the same “no evidence” label leaves the writer unable to identify the cause. Traces should make it possible to investigate which input and tool caused the stop. An execution record does not by itself make an argument verifiable, so the evidence used in the prose must also be retained.

The scope of general availability matters too. Semantic Kernel’s April announcement describes general availability of the core Agent API. That status cannot automatically be extended to every orchestration pattern introduced in May. Verify the features and implementation version being used, then examine an entire job.

Following longer execution

A completed response and a usable report are different conditions

The May 21 Responses API update adds remote MCP server support, Code Interpreter, and background mode for starting longer tasks asynchronously. Applications can poll response objects for completion or follow events to catch up on execution. These are components for waiting on work involving research and calculation.

The mechanism addresses execution progress. Whether enough evidence was collected and calculation assumptions match requires separate checks. A successfully finished calculation can still produce an unusable conclusion if it compares values with different units. Handling communication and waiting does not define business completion.

I would connect displays such as researching, calculating, and awaiting review to actual processing. These user-facing states are my proposal. Showing missing evidence or an outstanding human decision, instead of declaring the report finished when internal calls end, lets the user decide whether to wait or change the conditions.

A hypothetical report design

Passing numbers alone makes the integrator repeat the search for conditions

Follow the energy-comparison report as a concrete design example. Research participants return primary-source URLs, publication dates, and relevant passages, together with the model, hardware, processing scope, and measurement units. Unverified conditions remain visible. If training and inference measurements are mixed, the inputs must be aligned before calculation or separated into different comparisons.

The calculation participant returns the values used and the conversion method. The writer distinguishes measured facts from conclusions derived under specified conditions. A reviewer checks whether the conclusion exceeds the original scope. Voting for the participant with the largest number does not resolve incompatible measurements.

Adding a reviewer does not guarantee quality. If every participant reads the same summary with omitted conditions, they share the omission. Give the reviewer original passages as well as the draft so measurement scope can be checked. Confidence expressed by a collector should not be inherited as evidence strength. Removing conclusions where conditions do not align should be part of the review role.

Insufficient evidence returns from review to collection. If the missing material cannot be found, the report retains the part that cannot be compared. Completion of every participant’s response therefore does not become completion of the conclusion. The user can assess what is and is not comparable, as well as which figures are supported.

Division helps when there is enough independent exploration to justify it. A report based on one short source may acquire unnecessary handoff and integration work. Roles organize the work; they do not each have to run as a separate agent.

Deciding whether to divide work

Compare the burden of completion before adding more participants

Building effective agents recommends starting with the simplest structure that fits the problem. A single-participant baseline and a divided design should face the same report task. Record time spent collecting, handing over, integrating, reviewing, and repeating work, alongside model usage.

Align sources, available tools, models, and completion criteria in that comparison. If the divided design receives more research time or a different model, those differences also contribute to the result. They cannot be attributed solely to adding participants. Retaining stage-level differences, such as faster collection followed by slower integration, helps identify which work to divide next.

Assess source correspondence, omitted conditions, and unsupported conclusions. Include missing material and disagreement between participants. A faster draft is hard to call an improvement if a person must search for more originals afterward. Conversely, work that reduces waiting through parallel exploration while preserving conditions during integration has a reason to be divided.

May’s announcements expand the choices for placing work coordination into code and service configuration. Using those choices well requires moving from participant counts to dependencies that lead to a completed artifact. Division improves the job when it also reduces the user’s burden of reorganizing multiple answers.