Hand work between agents with an explicit contract

To hand work between agents with an explicit contract, send a structured request that describes the task, its owner, the relevant facts, and the result required. Include the action the receiving agent may propose or perform and the conditions that require it to stop. The receiving system must check those permissions before allowing an action.

A support agent might ask a billing agent to check a refund. The request should identify the order, link to the applicable policy, and distinguish advice from permission to issue a payment. If the order is missing or the authority cannot be verified, the receiver should return the problem to the sender.

Start with one frequent handoff. Make its requirements clear enough that the team can test whether the receiver accepts the right requests, rejects incomplete ones, and returns evidence of the result.

Describe the work without forwarding every conversation

A full conversation may contain outdated assumptions, irrelevant detail, or instructions embedded in customer content. A structured handoff makes the current task easier to identify. Retain the source material where authorized reviewers can retrieve it, and include the references needed for this task.

Separate observed facts from a model's interpretation. A record stating that an invoice is unpaid is different from a model's prediction that the customer will dispute it. Include the source, version, and verification status of information that affects the next action.

Document the decision already made and the evidence behind it when the receiver needs that context. The receiver should still check whether the decision remains applicable. A changed policy, stale record, or new instruction may require the workflow owner to reconsider it.

Define the request and the expected return

The contract is an interface between parts of the application. Its fields should reflect the work being transferred, rather than a universal template for every agent.

Validate required fields, types, identifiers, and supported contract versions before invoking the receiver. Then check the meaning of the request. A correctly formatted customer identifier can still refer to the wrong customer or an account the caller cannot access.

References should identify the source version when a later edit could change the decision. They also need to be accessible to the receiver under its own permissions. A valid document link does not establish that the receiver may read the document.

Enforce permissions outside the model

An “allowed action” field describes the requested scope; it cannot grant authority on its own. Validate the caller, target record, tool operation, and applicable approval through the application and connected system. Do not place credentials in the conversational payload.

The OWASP guidance on prompt injection prevention recommends validating tool calls against user permissions and session context, checking parameters, and applying least privilege. Those checks belong at the tool boundary, even when the request passed schema validation.

Distinguish the kinds of handoff your workflow supports:

• Advice: The receiver returns an analysis or recommendation. It receives no authority to change the business record.
• Preparation: The receiver creates a proposed change for review, such as a draft response or an invoice correction.
• Execution: The receiver performs a bounded operation using verified authority and returns evidence of the outcome.
• Escalation: The receiver reports what prevents progress and routes the case to the responsible person or system.

Changing the workflow owner does not transfer credentials or grant unrestricted authority. Establish the new responsibility explicitly and check each consequential operation against the applicable permissions.

Make completion and uncertain outcomes different

Define return states the application can process, such as completed, blocked, rejected, and outcome unknown. Pair each state with the evidence needed to support it. A model saying “done” is not proof that the target system accepted a change.

For a refund, a completed result could identify the payment-system record and its verified status. If the request times out after submission, the result is uncertain until the team can establish whether the payment occurred. Do not describe it as a failed refund and immediately issue another one.

The Internet Engineering Task Force's HTTP semantics standard limits automatic retries of non-idempotent requests unless the client can establish repeat-safe behavior or that the first request was not applied. Use the actual payment or business-system contract to determine the recovery step; a task identifier alone does not make a retry safe.

Set responsibility for checking uncertain outcomes. Record the attempted operation and the information needed to find it, while excluding secrets and unnecessary customer data. If automated reconciliation is unavailable, send that evidence to the responsible operator.

Prevent repeated delegation without progress

Name the workflow owner and decide which components may update each record. Where several writers are allowed, use the concurrency controls supported by the application. The design needs to account for conflicting updates, rather than assuming that ownership exists because a prompt names an owner.

Set limits on time, cost, and further delegation where those limits matter. Track delegation centrally or in trusted workflow state so an agent cannot bypass a limit by starting a fresh request. A counter supplied by a model is insufficient enforcement on its own.

When a limit is reached, return the current status, the work already completed, and the next decision needed. Avoid sending the same incomplete request between specialists repeatedly. Resolve a missing order identifier at the source instead of asking another agent to guess it.

Give reviewers a concrete action to assess

Use the organization's approval policy to determine which actions need human review. Where approval is required, show the proposed change, affected records, supporting evidence, and consequences before execution.

Tie approval to that specific action and its relevant inputs. If the amount, recipient, or record version changes, check whether the approval still applies. Repeating a general permission statement is not a substitute for establishing authority over the changed action.

Explain the recovery options accurately. A draft may be discarded, a record may support a compensating correction, and a sent message cannot be recalled reliably. Do not promise rollback for an operation the connected system cannot reverse.

Test the handoff before expanding it

Test routine requests, missing fields, stale records, denied access, conflicting updates, repeated delivery, tool timeouts, and unsuccessful reconciliation. Check the resulting system state as well as the returned message.

Track rejected requests, rework, time spent waiting at a handoff, and cases that need an operator. Use those observations to improve the contract. Retain confirmed failures as regression cases, without claiming that a passing test eliminates every future failure.

Add another agent when distinct expertise, context, or operating boundaries justify it. A single agent with tools, or a conventional workflow, may be sufficient for a simpler task. The contract should make necessary coordination understandable and testable.

Explore X-Centric's AI consulting services for help defining agent responsibilities, connecting business systems, and testing the work transferred between them.