AI-generated illustration of a sales request being checked by a warehouse team. It does not depict a customer system or project.
A sales assistant asks a warehouse assistant to check stock for a customer. The reply says “done.” Has someone checked availability, reserved the goods, or merely accepted the request? If each side reads that word differently, a customer could receive a commitment before anyone owns the delivery.
Once AI assistants hand work to one another, accuracy is only part of the question. The business also needs to know who requested the work, what each assistant may do, and what evidence shows that the result means what the receiving team thinks it means.
Episode 1 distinguished protocols, standards and open source. Episode 2 examined the meaning of ERP data, and episode 3 covered maintaining working procedures through Agent Skills. This final episode brings those questions into a bounded pilot that can measure value and stop when its evidence is insufficient.
When does one task need assistants from several teams?
If the whole task lives in one application, uses one dataset and has one process owner, another assistant may add little beyond another handoff to maintain. Start with the approach the team can inspect and repair most easily.
Delegation deserves closer consideration when teams have their own systems or responsibilities. Sales might ask the warehouse for a status check while the warehouse retains control over its checking procedure and access rules. Sales does not necessarily need direct access to every internal warehouse tool.
A2A describes communication and collaboration between independent agents. MCP connects agents with tools and resources. They can be used together, according to the official A2A and MCP documentation. The choice should follow the actual boundary in the work. A project does not need every protocol merely because it is available.
Agree on the handoff before sending the first request
A2A provides mechanisms to describe agents through Agent Cards, exchange messages, track tasks and return artifacts. Authorization after authentication still depends on the receiving implementation’s policies. The business must define the meaning of the work and the permitted data alongside the connection. See the authentication, authorization and task-lifecycle provisions in the A2A specification.
For an initial pilot, write a handoff agreement that sales and warehouse staff can read together. It should name the accepted requests, required inputs, expected result, accountable person and conditions that require human review. If the teams cannot agree what information makes a check complete, choosing a protocol will leave the ambiguity unresolved.
Keep the human requester, the assistant sending the request and the assistant reading the system identifiable. A warehouse assistant should reject work beyond the permitted scope even when the sales assistant can reach it. Delegating a task should not silently increase the request’s authority. These are design controls the project must enforce and test.
Define more than the successful path. Agree on waiting limits, missing information, duplicate results and cancelled requests. Where work has already created an ERP transaction, the business needs a way to check and reconcile the outcome. A cancelled task status should not be treated as proof that the business transaction was reversed.
A hypothetical sales-to-warehouse pilot
Suppose a distributor starts with questions about stock available for allocation in one warehouse. A salesperson initiates a request through a sales assistant, which delegates the check to a warehouse assistant. This round produces a draft for staff review. It does not reserve stock, create a sales order or automatically message the customer. This is a proposed example, not a system delivered by Enersys or a report of actual results.
The salesperson supplies the item code, warehouse, quantity and requested date. The sales assistant passes only the information the warehouse assistant needs, with a request reference. The warehouse assistant reads the ERP through a scoped tool, follows a procedure approved by the warehouse owner and returns the checked quantity, reference time, outstanding conditions and evidence that authorized staff can open.
The salesperson checks the draft and its evidence before speaking to the customer. The warehouse lead owns the definition of available-for-allocation stock. The pilot owner checks whether both assistants exchanged information and respected their agreed boundaries. These roles remain necessary when the messages travel through a standard protocol.
Consider an exception: the warehouse assistant cannot read the reservation balance and the request times out. The sales assistant must report that verification is incomplete and return the task to the existing manual process. If an old result arrives later, the pilot must associate it with the original request. A person decides whether it remains usable or needs another check. It must not automatically trigger a second customer confirmation.
The evidence for one task should connect the human request, delegated task, data references and draft response. Record access denials, reasons for human review and the procedure revision used, without collecting unnecessary secrets. The A2A specification’s security guidance recommends security-event logging and audit trails for sensitive actions, with protection for sensitive log data.
The company still has to decide what evidence to retain, who can read it and for how long. A protocol task history is not a complete business audit trail. Keeping every message without boundaries can add work and expose more information than reviewers need. Keeping only “success” will not explain a wrong answer.
Measure from the first question to a usable answer
Before the pilot, select comparable examples from the existing process. Measure from the moment sales asks until it receives an answer it can actually use, including warehouse waiting time and corrections. Timing only the AI’s text generation can suggest a gain while people wait just as long.
One proposed starting point is the first 20 eligible tasks in a single warehouse. Treat that number as a bounded initial sample, not statistically conclusive evidence or a production-readiness standard. Record excluded tasks and the reasons so that the pilot does not quietly retain only favorable cases.
Reviewers should count factual corrections, human handoffs caused by missing information and time spent checking evidence separately. A handoff required by the rules is the desired behavior, so it should not be counted as an AI error. A polished response based on the wrong balance is an error even if nobody clicks a problem-report button.
Before testing, agree on continuation criteria suited to the company’s costs and risks. These might include the agreed reduction in total time per usable answer, an acceptable review burden and no out-of-scope access found in the defined tests. Finding no incident in this sample cannot establish that other work has no risk.
If an authorization bypass occurs, or evidence for a material answer cannot be found, pause that scope and use the existing manual process. Assign a person who can stop it and test the method for revoking access. After fixing the cause, rerun the failed cases. These are proposed management controls, not certification conferred by A2A support.
A small pilot that supports the next decision
The first round may justify continuing the same task, repairing a data definition or stopping because review takes longer than the old process. Each is a useful outcome when the evidence supports it. Adding assistants or granting permission to create transactions should follow the review findings; neither has to be the next objective.
Before the next project meeting, complete this sentence: “Let the assistant for which team request what information from which other team, with whose review, and under what stop condition?” If the team cannot write it yet, use the meeting to settle that sentence before choosing tools.
The four-part series ends with the start of a small, inspectable piece of work. Once the task, data definitions, procedure owner and handoff responsibility are clear, the business and technical teams have a scope they can assess without promising that AI will take over every department.
Return to the question in episode 1: open protocols and open source give teams choices in connecting and maintaining systems. Internet history offers an analogy, not a guarantee that AI will follow the same path. What a company can test now is whether one piece of work crosses the boundary according to its agreed rules.
