When I think about the promise of agentic systems, I think about being able to give a system meaningful work and trust it to follow through.

“Investigate this potentially compromised account” is a good example. That request leaves a lot to determine. What evidence is needed? Which systems should be examined? Who can perform each part of the investigation? What happens when the findings raise another question?

The system needs to develop an approach, involve the right specialists, evaluate their contributions, and determine what remains to be done. It also needs to recognize when a person should make a decision.

That is where multi-agent orchestration becomes important. Different agents bring different expertise, tools, and access. Completing the work depends on how those contributions fit together.

The ambition is to give the system an objective and have it organize the work needed to achieve it. People still set the direction, authorize actions, and decide where review is required.

An agent can contribute and coordinate

In the account investigation, an identity agent might take responsibility for assessing whether the account was compromised. It may need an endpoint specialist to examine device activity and a cloud specialist to investigate actions taken through a suspicious session.

An agent can already give another agent a high-level task and rely on it to work out an approach. The architecture needs to make that cooperation dependable: define the expected contribution, establish dependencies, evaluate what comes back, and determine what remains unfinished.

Suppose the endpoint agent finds a suspicious file and needs another specialist to analyze it. It should be able to organize that supporting work, evaluate the findings, and use them to complete its own assignment. It then returns the relevant result to the identity agent. The identity agent then combines those findings with its own evidence and returns an assessment to the agent coordinating the overall investigation.

The endpoint agent is both a contributor and an orchestrator. Those roles depend on the task. It contributes to the investigation it was assigned while coordinating the help it needs.

A central orchestrator can assign broad tasks and consult specialists too. The design choice here is allowing that coordination process to repeat within supporting tasks, with clear responsibility at each level.

There may still be a top-level agent responsible for the overall investigation. It should be able to rely on a specialist to manage its assignment while receiving enough evidence and status information to assess the result.

A supporting task is still a task. The same questions apply: what needs to be accomplished, what help is required, and what evidence will show whether the assignment has been fulfilled?

Let specialists help shape the plan

Useful coordination begins before an assignment is finalized.

An endpoint specialist might say it can examine device activity, but needs a device identifier and a time window. That response tells the coordinating agent something about how to organize the investigation. Another step may need to establish those inputs first.

The specialist’s response has helped define the work, its sequence, and its dependencies. The coordinating agent can use that information to decide what to assign and to whom.

This is the interview process we want to introduce for external agents. Given this particular task, what can you contribute? What would you need? What would you return?

At Bricklayer, we use information in the platform to select agents and organize their work into step-by-step procedures. We can also learn about external agents through use. The interview would help fill the gap before an unfamiliar agent’s first assignment, when detailed capability information has not otherwise been supplied.

The amount of discussion should fit the uncertainty. A familiar task with a well-understood collaborator may need very little. An unfamiliar agent or a new kind of assignment may warrant more. Work can begin as its requirements become clear, and the procedure can adapt as new evidence arrives.

How A2A fits into the architecture

Agents built by different organizations need a common way to interact. A2A supports that interaction through Agent Cards describing skills and connection requirements, messages, tasks, status updates, and results.

That gives us a foundation for involving external agents in a procedure. It also gives us a way to carry the proposed interview conversation.

The application still needs to decide how to use those exchanges. Which questions should it ask before assigning work? How should a response affect the plan? What makes the returned evidence sufficient?

Simply enabling conversation leaves those decisions open. Multi-agent orchestration gives the exchanges a purpose within the work: identifying a contribution, arranging the steps, tracking progress, and deciding what comes next.

For the account investigation, a message from the endpoint agent might identify a missing input, report a finding, or request permission for an additional action. Each requires a different response from the agent coordinating the investigation.

The value comes from connecting communication to those decisions.

The next investigation should benefit

Following through also means learning from what happened.

If the endpoint investigation succeeds only after receiving a device identifier and a narrower time window, that experience should inform future assignments. The next procedure may need an earlier step to establish those inputs.

If the returned evidence repeatedly needs correction, the system should reconsider how it uses that agent. It may need another collaborator, clearer task boundaries, or an additional review step. The lesson depends on why the work fell short.

These improvements require evaluation. An agent’s confident answer is a claim to examine. Useful evidence can confirm part of an investigation while leaving the larger question unresolved.

Sometimes the right result is a supported conclusion. Sometimes it is a clear explanation of what remains unknown and what a person needs to decide. A system that makes those limits visible is more useful than one that silently treats every response as completed work.

Experience should improve future procedures, with human review where changes affect consequential decisions. Learning about a collaborator is valuable when it changes how the next assignment is planned, performed, or checked.

That is the promise I want us to pursue. When the work gets complicated, can the system organize the next step, explain what it still needs, and keep moving toward the objective?

In the account investigation, I want to understand what the evidence supports, what remains unresolved, and what decision is needed next. The agents and their coordination should help us get there.