Integrating an AI agent with an existing system used to mean writing a function for every API call. That remains necessary, but it is no longer the whole architecture. Modern agent environments separate connectivity, working instructions, execution context and operational control.
MCP tells an agent what external capabilities exist. Skills teach it how to perform recurring work. Cowork systems provide a persistent place to combine files, tools and human feedback. The coordinator preserves process sovereignty: it decides which proposed step becomes part of the accepted process.
Five Layers of Agent Integration
The useful question is not “Does the agent have access to Salesforce, SharePoint or the data warehouse?” It is “Which layer owns access, method, state, authority and accountability?”
| Layer | Responsibility | Example |
|---|---|---|
| System of record | Authoritative business data and transactions | CRM, ERP, CMS, ticketing system |
| Connector or MCP server | Discoverable access to data and actions | Search records, create draft, update issue |
| Skill | Reusable instructions, scripts and templates | Prepare account review, audit content, triage incident |
| Cowork environment | Files, conversation, artifacts and human collaboration | Research workspace, project folder, review session |
| Workflow/control plane | State transitions, approvals, budgets and audit | Approve before send, retry safely, record outcome |
An agent runtime sits across these layers. It interprets the request, selects capabilities and proposes actions, but it should not become the owner of every layer. The coordinator connects the layers without surrendering their authority to the model.
The Coordinator Is the Center of Process Control
The coordinator owns the run lifecycle: accepted state, permitted transitions, budgets, retries, approval and completion. That role may be delegated to an LLM, implemented with heuristics or retained in a deterministic state machine or workflow.
For production integration, the strongest default is a deterministic shell containing bounded heuristic and model-directed operators. The model may recommend the next action; the coordinator decides whether it is permitted and sufficiently supported. The dedicated hub AI Coordinator Architecture and Process Sovereignty compares all three coordinator models and explains their consequences for traceability, control and provider independence.
MCP: A Standard Interface to Capabilities
The Model Context Protocol defines primitives through which a server can expose resources, prompts and tools. Resources provide context, while tools allow the model to retrieve information or perform actions. A client can discover available tools and their schemas instead of relying on one custom integration format per agent product.
This changes the economics of integration. An organization can place a stable MCP interface in front of internal APIs and make the same capability discoverable to several compatible clients. OpenAI’s Responses API, for example, supports connectors and remote MCP servers and allows tool calls to be automatically permitted or placed behind explicit approval.
MCP does not make an integration safe by itself. A tool schema says what can be called; it does not decide whether this user may call it on this record at this moment. Authentication, authorization, tenancy, rate limits, validation and audit remain production responsibilities.
Treat every MCP server as a capability boundary:
- expose narrow business operations rather than raw database access;
- separate read tools from side-effecting tools;
- return stable entity identifiers and provenance;
- require approval for consequential actions;
- validate all arguments server-side; and
- log both the request and accepted outcome.
Skills: The Method Above the Tool
A tool may expose search_contracts, create_document and request_approval. It does not explain how the organization conducts a contract review. That knowledge belongs in a skill.
Agent skills are portable packages of instructions and optional references, templates or scripts. They use progressive disclosure: the runtime can advertise a compact description, load the detailed method when a task matches, and read supporting resources only when necessary.
The distinction is simple:
MCP tool: what operation is available?
Skill: how should this kind of work be performed?
Workflow: which steps must execute, and in what order?
A content-audit skill might specify the required metrics, evidence thresholds, editorial checks and report format. Its tools may come from analytics, search and CMS MCP servers. The same skill can be improved without changing those underlying APIs.
Skills are appropriate when judgment and adaptation are useful. They are not a substitute for deterministic workflows when side effects, mandatory ordering or expensive retries matter. Microsoft Agent Framework documentation captures the distinction well: let a skill guide adaptive work; use a workflow when execution order and recovery must be guaranteed.
Cowork Systems: The Agent’s Workbench
Cowork systems move the interface from isolated chat replies toward delegated, multi-step knowledge work. The agent operates on a bounded set of files, connected services and project instructions; produces artifacts; reports progress; and pauses when human review is required.
Examples include workspace agents in ChatGPT, Anthropic’s Cowork model of delegating work against a working folder and connected tools, and Microsoft 365 Copilot Cowork across documents, email, calendar and Teams. Product details differ, but the architectural pattern is consistent:
- a user establishes the task and working scope;
- the environment supplies identity and permissions;
- connectors expose organizational context and actions;
- skills encode team-specific methods;
- the agent produces inspectable intermediate and final artifacts; and
- sensitive actions return to the user for approval.
The cowork environment should therefore be understood as a production surface, not another connector. It owns the interaction between agent work, human judgment and deliverables.
A Reference Integration Flow
Consider an agent preparing a customer renewal review:
User delegates renewal review in cowork workspace
→ deterministic coordinator creates run and loads current state
→ skill loads the organization's review method
→ CRM MCP tool resolves account and contract
→ knowledge layer supplies ownership, policy and provenance
→ analytics tool retrieves usage and support evidence
→ agent drafts risks and proposed actions
→ heuristic/model router proposes the next permitted branch
→ coordinator validates evidence, budget and transition
→ human approves the customer-facing artifact
→ CRM/email tool performs the authorized side effect
→ event log records the accepted transition
The model handles uncertain interpretation and synthesis. The coordinator retains the process. Existing systems continue to own customer identity, contract state and communication history. The workflow owns the approval barrier. This is more reliable than copying all context into a prompt and asking the model to “handle the renewal.”
Integration Failure Modes
Treating tool availability as permission
Discovery is not authorization. Enforce access using the authenticated user, current tenant, target entity and action—not the model’s statement that an operation seems appropriate.
Encoding the whole business process in a skill
Skills are excellent for methods and judgment. Mandatory approvals, financial transactions and irreversible actions belong in explicit workflow or policy enforcement.
Delegating completion criteria to the model
A model that decides both what “done” means and whether its own work is complete cannot provide an independent acceptance boundary. The coordinator should evaluate explicit completion conditions, required artifacts and validation results.
Letting conversation memory become system state
A cowork session may remember that a document was “approved,” but the authoritative approval must be recorded against the exact version in a durable system. Stateful agent architecture depends on this separation.
Connecting broad generic APIs
An agent with low-level file, database or messaging access has too many ways to make an expensive mistake. Prefer task-oriented capabilities such as create_email_draft over unrestricted mailbox mutation.
The Architectural Payoff
MCP, skills and cowork systems solve adjacent problems, not competing ones. MCP reduces connector fragmentation. Skills make organizational methods reusable. Cowork environments make long-running agent work visible and collaborative. Workflows, policy engines and systems of record keep consequential state transitions controlled.
The coordinator makes those layers a governed production system. Keeping it outside any individual LLM makes providers replaceable, transitions testable and run histories comparable. This is process sovereignty: the organization owns how work becomes accepted, not merely the prompt sent to a model.
The resulting architecture does not ask one agent to absorb the organization. It gives the agent a bounded workbench, discoverable capabilities and explicit methods—while the coordinator preserves the process and systems designed for authority continue to own truth.