Ecosystem Connectors: MCP, A2A, and Office Protocols
Agents do not live on islands: use MCP to discover tools, A2A to reach peer agents, and enterprise chat connectors to meet users in their daily workflow.
Teams usually start with bespoke glue code: a wrapper for the GitHub API, another for the internal ticket system, a custom adapter for the database.
That works while the surface is small. As the agent reaches more services it runs into three problems.
First, the integration tax. Every external system has its own auth scheme, data shapes, and error codes. Any upstream change forces an edit and a retest of every agent that touches it.
Second, collaboration between agents does not scale. When a lead agent hands work to a specialist, natural-language back-and-forth loses information and blurs ownership, so the lead cannot tell whether the subtask actually finished.
Third, the agent stays outside the workflow. If it lives only on its own custom page, staff bounce between systems, and it can never report progress or ask for confirmation in the chat where they already work.
Becoming part of the business means replacing bespoke adapters with standard protocols.
The tool protocol: Model Context Protocol
The Model Context Protocol (MCP) is the open standard for connecting models to external tools. mcp-specification
Before it, every framework had its own tool format. MCP defines one client-server contract: an external system exposes an MCP server and any compatible agent can use it, across three dimensions:
- Tools — operations the model can invoke, with typed inputs.
- Resources — read-only data the model can pull on demand, such as files or log streams.
- Prompts — server-side templates for domain workflows.
One boundary deserves stating plainly: MCP standardizes capability transport; it does not do security or permission enforcement. Expose a high-privilege production interface through MCP without a gate and a manipulated model can do real damage. Tool calls still have to pass through the agent's own security gateway.
The agent-to-agent protocol: A2A
Once the business grows complex enough that one agent cannot hold it all in context, multi-agent work becomes necessary.
That collaboration must not degenerate into endless natural-language chatter. Efficient communication between agents is a contract-based remote task call, which is what A2A (Agent-to-Agent) provides. a2a-protocol-spec
| Element | Free-form chat | A2A contract |
|---|---|---|
| Delegation | A vague paragraph open to misreading | A typed input, a stage goal, a list of forbidden actions |
| Payload | Large artifacts copied through chat history | A controlled reference handle only |
| Constraints | No time or compute boundary; waits forever | Explicit budget, timeout, and retry limit per call |
| Acceptance | A paragraph of summary text | A structured receipt with real data and a signature |
Through that contract, agents built by different teams on different stacks can still work together.
Office connectors: meet users where they work
An agent creates business value only where the work happens.
Connectors for enterprise chat platforms bind the agent to the org chart and the daily message stream: feishu-open-platform dingtalk-stream-mode
On one side, users never leave the chat. Mention the agent in a group or send it a direct message, and a long-lived gateway captures the event and starts the run.
On the other, when a long task reaches a security checkpoint, the agent does not wait for someone to open a dedicated console. It pushes an interactive card with a detailed diff into the chat. One click sends the callback back to the interceptor gateway and the task resumes. The lower friction cuts the wait.
Credential isolation and a single gateway
Connecting broadly to the outside world means handling real secrets: access keys and short-lived tokens.
The architecture has one rule: no real credential is ever stored in the agent's code or prompt. A central vault holds them, and every outbound request passes a reverse proxy. Inside a run, the agent holds only a short-lived token; when the request reaches the gateway, it checks the task's permissions, injects the real credential, and forwards it.
Standard protocols plus a strict gateway turn the agent from an isolated code fragment into something fused with the systems the business already runs.