Agent Orchestration via MCP

Coordinate actions within organizational authority

Agent orchestration concerns how applications, agents, tools, and information sources work together. The Model Context Protocol (MCP) standardizes ways for compatible clients and servers to expose and use tools, resources, and prompts. Protocol compatibility helps structure interaction. Permission to perform a business action still depends on the surrounding identity, authorization, policy, and tool controls.

A practical design sequence

1. Map the workflow. Identify the user, agent host, clients, servers, tools, data sources, and the side effects each tool can produce.
2. Define authority outside the model. Specify who may request each action, which identity and scope apply, and where authorization is enforced by the application or tool.
3. Constrain each connection. Give tools narrow schemas and permissions, separate reading from consequential actions, and decide how secrets, approvals, logs, and errors are handled.
4. Test allowed and denied paths. Exercise ordinary, malformed, ambiguous, replayed, and unauthorized requests. Confirm that the system blocks prohibited actions and records enough context to investigate what happened.

What to keep visible

For each action, make the initiating user, requested tool, arguments, authorization decision, result, and any human intervention inspectable. A gateway can help centralize routing or observability, but placing one in the path does not by itself establish correct authorization or safe execution. Each tool and connected system still needs its own checks and operational limits.

Connection to CTRS

Agent Orchestration is one pillar of the Control Tower Reasoning System. It depends on the other questions the framework raises: whether a decision is useful, whether its context is current, and who can authorize action. The human oversight essay explores evidence, authority, and intervention around consequential agent work.

Keep approval attached to the action it authorized

Illustrative enterprise example: creating a purchase order. A procurement assistant collects a supplier quote, checks the approved budget, and prepares an order for 40 laptops. A manager approves the specified supplier, quantity, price, and delivery location. Before execution, a revised quote changes the supplier’s identity and increases the total. The earlier approval should no longer be sufficient for that revised order.

Map the work as preparation, approval, execution, and confirmation. Reading a quote can produce a proposal; it should not confer permission to create the order. The execution service needs to check the acting identity, its permitted scope, and the approval associated with the particular order being submitted. If the approved details change, return the revised proposal for review rather than asking the model whether the change seems reasonable.

MCP can provide a common way for compatible applications to expose operations. Its authorization specification also defines authorization capabilities for HTTP-based transports. Those capabilities do not determine whether this manager may approve this purchase, or whether a changed quote remains covered by an earlier approval. Those are application and organizational decisions that the connected services must enforce.

Keep an action receipt

Record the request identifier, acting identity, approved order details, approval reference, requested operation, authorization result, execution status, and purchase-order identifier. Keep sensitive credentials out of the receipt. A rejection should identify the reason and next step without exposing restricted information.

The example succeeds when the unchanged, authorized order produces one confirmed purchase order and a traceable receipt. Repeating a request after a connection timeout should reconcile with the existing order or stop for investigation, rather than blindly create another. Test a changed amount, revoked access, expired approval, unavailable supplier service, and a lost response after creation. Failure includes executing changed details against old approval, duplicating the order on retry, or describing a queued operation as completed. The orchestration is credible when these awkward states are handled as carefully as the ordinary successful call.

Further reading

Read the full analysis · MCP specification.

Bring a concrete tool boundary or counterexample to a working conversation.