Before AI agents negotiate, define the handover

An AI agent that can ask another agent for help sounds like a natural extension of teamwork. In a business, however, teamwork includes boundaries. A sales colleague can ask about delivery capacity without being entitled to every supplier contract. A customer can request a quotation without authorising an order. Before connecting agents across teams or companies, define the handover: what is requested, what may be shared and what counts as an authorised action.

Jean-Denis Greze’s 3 September AI Engineer session discusses information access and privacy as central questions for agent collaboration. The publisher’s description sets out several approaches, including shared spaces and human-mediated exchanges. This article uses that framing to develop a practical business handover. It does not endorse the speaker’s broader theoretical claims or present any architecture as universally safe. The important starting point is the task and the people accountable for it.

A request is not permission to act

Imagine a small manufacturer receiving a message from a customer’s purchasing agent. The message asks whether a component could arrive by Friday. A helpful response might explain current availability and ask for the required quantity. It should not automatically reserve stock, accept a price or trigger shipment. Those steps change the business’s commitments. The example is hypothetical, but the distinction is familiar: answering a question and entering a transaction are different acts.

Write that distinction into the proposed workflow. For each handover, identify the requesting party, the purpose, the information needed and the action allowed. A delivery enquiry might permit access to a limited availability view while excluding supplier prices. An order amendment might require approval from a named person. Clear boundaries make the system easier to evaluate because the team knows which outcomes would be incorrect even if the conversation sounds reasonable.

The operational thinking in leadership and business development channels is useful here. Delegation works when authority is understood. Giving an agent access to a tool does not explain when using it is appropriate, just as handing a new employee a company card does not define purchasing authority. The workflow must carry that meaning instead of relying on the assistant to infer it from scattered conversations.

Share the smallest useful answer

Teams often begin integration by asking which systems can be connected. A better first question is which information the other party genuinely needs. To discuss a delivery date, the customer may need an available window and conditions, not the full production schedule. A supplier may need a technical specification without access to the commercial history behind it. The useful interface is the narrow answer that lets the next person proceed.

This approach also helps separate different types of uncertainty. Perhaps availability is current but transport has not been confirmed. Perhaps the specification is complete but price approval is pending. The response should preserve those qualifications. Compressing everything into “yes” may feel efficient while creating a misunderstanding that later requires several people to repair. A handover should communicate both the answer and the decision that remains open.

NIST’s AI risk framework connects risk management with defined responsibilities and continued evaluation. Applied here, the business should name an owner for each consequential handover and test it as circumstances change.

Make confirmation visible

A workflow needs a clear moment at which a proposal becomes a commitment. That moment should be visible to the people affected. In the manufacturer example, a quotation could include a reference, scope and expiry condition, followed by an explicit acceptance step. The details depend on the business. The general principle is that a conversational acknowledgement should not silently acquire a stronger meaning elsewhere in the process.

This is especially important when systems repeat requests after an interruption. A human may recognise that a second message is a duplicate. An automated process needs a reliable way to recognise it too. Ask the implementation team how the workflow prevents repeated reservations, duplicate tasks or multiple orders. This is a concrete question for the system design, not a reason to abandon automation. The answer should be demonstrated with a harmless test.

People exploring technology and AI channels will encounter impressive examples of agents cooperating. When evaluating them for a business, look for the less dramatic part: interruption, rejection and recovery. Can the process resume without losing context? Can a person see what has already happened? Can an incorrect commitment be identified and handled promptly? A smooth demonstration of the ideal path answers none of these questions by itself.

Begin inside one bounded relationship

A first trial does not need an open network of autonomous businesses. It can connect two internal teams around one repetitive request. Choose a situation with a known owner, stable information and a manageable consequence if something goes wrong. Run it alongside the existing process first. Compare the result, the checking effort and the clarity of the handover. Expand only after understanding the discrepancies.

For example, a sales team might request a standard technical document from operations. The system can locate the approved version and return it with its publication date. It should escalate if the requested configuration is outside the document’s scope. This limited task teaches the company about source quality and responsibility without beginning with negotiated prices or customer commitments. It also reveals whether automation is saving work or simply moving it to reviewers.

The customer perspective matters throughout. Sales and marketing discussions often focus on reducing friction, but some friction is useful confirmation. A buyer may welcome a fast answer and still want a person to approve a consequential change. Design the handover around that preference where possible. Automation should make responsibility clearer to the customer, not force them to discover which invisible system made a decision.

Questions to settle before connecting agents

What should the first agreement describe? The permitted request, the minimum information to share, the action boundary and the person responsible for exceptions.

How should ambiguous messages be handled? Ask for clarification or route them to a person. Do not turn uncertainty into a commitment merely to keep the process moving.

What proves the handover works? Correct outcomes across ordinary cases, interruptions and refusals, with a record that people can understand and review.

The useful next step is to choose one handover your team already performs and write down its boundaries. If the humans cannot agree on what a request authorises, connecting agents will not resolve the disagreement. Once the boundary is clear, automation has a task it can be judged against.

▶

Source session: AI Engineer, Jean-Denis Greze, 3 September 2026. The publisher’s description was reviewed; the complete recording was not watched.