Separate tool discovery from delegation to another agent

MCP generally provides a structured way for an agent host to discover and use tools or contextual resources exposed by a server. An Agent2Agent interaction is closer to delegating work between agent participants that may each plan and execute their own steps. The design distinction matters: a tool call should have a narrow documented function and input schema, whereas an agent delegation may involve longer tasks, progress updates, uncertainty, and output interpretation.

Do not treat either mechanism as a trusted shortcut around an existing API. A finance-read tool still needs a finance authority model. A delegated service agent should not inherit the calling agent's unrestricted credentials. Write down which principal authorizes the operation, what arguments the recipient may receive, and whether the remote endpoint is part of the same administrative trust domain. Review the agent security-boundary guide before granting write operations.

Define the contract before choosing transport

The interface should specify purpose, input schema, output schema, permission requirements, timeout behavior, rate limits, sensitive fields, and the exact difference between read-only and mutating operations. An action named `resolve_case` is ambiguous: does it propose a response, update a record, refund a customer, or send external messages? A safer interface splits proposal from execution and validates each transition with a deterministic business rule.

Contract versions deserve their own rollout plan. If a recipient starts returning a different entity identifier, an orchestrator may still receive syntactically valid output while taking the wrong business action. Pin versions where supported, use contract tests, and retain an emergency disable path. The ability to revoke a tool quickly is as important as the ability to discover it.

Contracts also need operational semantics. If a delegated task is asynchronous, record who is responsible for polling, cancelling, expiring, and reconciling it. A terminal "completed" state should name the business effect that actually occurred, not merely indicate that the remote agent generated a message. For state-changing calls, carry an idempotency key across retries and require the downstream application to enforce it. Without that control, network uncertainty can cause two agents to repeat the same irreversible operation.

Model identity, consent, and data movement end to end

An orchestrator acting for a signed-in employee does not automatically gain permission to copy an entire customer record into an external agent. Classify every field before transmission, apply purpose limitation, and preserve the source system's read/write authorization. Distinguish user-delegated tokens, service identities, and maker-provided credentials. The latter can quietly turn one employee's request into an operation with a much larger privilege scope.

When a secondary agent has its own knowledge store, ask whether it should receive raw records at all. Often a scoped answer or reference with expiration is safer than duplicating customer data. The audit record should show who initiated the task, which agent received it, which tool executed it, and whether the final write was approved. Follow Copilot Studio authentication boundaries for identity-related design reasoning.

Treat tool descriptions as untrusted operational inputs

A tool server advertises names and descriptions that may influence which tool a model chooses. Those descriptions are helpful metadata, not authority to change policies. Review their provenance and change control; do not allow a newly connected server to silently expose privileged operations to every agent. Retrieved documents can also carry hostile instructions. Their content must be treated as evidence to evaluate, not as permission to expand the agent's role.

Use allowlists of approved servers, explicit policies for sensitive tools, and human approval at consequence boundaries. Rate-limit high-impact operations independently of the model. For a proposed supplier payment, enforce supplier validation, currency, amount thresholds, and duplicate detection in ordinary application logic, not merely in a prompt.

Exercise failure and interoperability tests

Create an end-to-end test that calls a discovery server, requests a low-risk summary, then attempts a forbidden update. The forbidden action must fail even when the agent's natural-language reasoning argues that it is urgent. Repeat with a missing tool, an unexpected protocol response, an expired token, a revoked endpoint, and a network timeout after a write request. The last case requires an idempotency and reconciliation strategy so that a retry cannot create duplicate transactions.

Product-specific support is subject to rollout and preview status. Microsoft's Copilot Studio documentation for MCP and A2A client channels describes early-release constraints in some environments. Therefore record feature availability in the target tenant and design a fallback; do not represent preview interoperability as universally deployed. At the exam level, the transferable skill is selecting a controlled integration boundary and explaining how it remains observable.

Simulate malicious tool metadata that claims higher priority than system policy, a recipient that returns fabricated approval, and a legitimate recipient whose permissions are revoked during a long-running task. Verify that authorization is evaluated at the action boundary and that the orchestrator can stop without inventing a success state. Audit logs should distinguish agent-to-agent messages from downstream tool writes, otherwise a later investigation will only reveal which agents talked rather than which application state changed.

Close with the business owner’s acceptance test

A useful acceptance review should ask whether the agent network produces the intended outcome using only the minimum authorized information. Have a reviewer inspect one successful trace and one denied operation. They should be able to reconstruct the initiating identity, selected tool, data passed, approval, and final result without trusting the agent's own self-report.

If the architecture cannot answer those questions, adding more agents makes accountability harder rather than automation better. Interoperability is successful when tools and agents can cooperate under the same explicit business control system, not when they can merely exchange messages.