The short answer
An AI agent integration is the bridge between a model's ability to understand and plan, and a real business system's ability to execute something or return current data. Without that bridge, an agent is limited to whatever it knows from the conversation itself or from general training data — it can suggest, but it cannot update a CRM record, send an actual email, or open a support ticket. The integration is what turns a suggestion into a verifiable action.
Why an agent needs integrations at all
A language model on its own processes text and generates text. It doesn't automatically know a specific customer's balance, a shipment's status, or the last open support ticket, because that information lives inside your business systems, not inside the model. And even if you fed it that information manually every time, it would still be unable to make any real change — it can't add a row to a table or update an order's status unless it's granted actual access to that system through an integration. So the difference between an assistant that gives generic advice and an agent that acts on your behalf is, to a large extent, a difference in the integrations available to it, not in the model's intelligence.
Read vs write integrations
It's worth always distinguishing between two kinds of access an integration grants an agent:
- Read: pulling data in to enrich the agent's context — such as reading a customer record or an order's status — with no change to the source system.
- Write: executing an action that changes the system's state — such as creating a ticket, updating a field, or sending a message — which is where the real risk lives.
Most useful integrations start with read access because it's relatively low-risk, while write permissions are typically granted incrementally and narrowly, often with human oversight over sensitive or hard-to-reverse actions.
Common integration categories
Integrations that connect agents to business systems tend to fall into recurring categories across industries. These are representative examples, not an exhaustive list:
- CRM systems: reading a customer's record and interaction history, and possibly writing a note or updating a deal's stage.
- Email: reading relevant incoming messages, and possibly drafting or sending a reply.
- Calendars: reading available time slots, and possibly booking or rescheduling an appointment.
- Support/ticketing systems: reading an open ticket and its context, and possibly creating a ticket or updating its status.
- Ecommerce: reading order status or inventory, and possibly updating a shipment or issuing a refund within set limits.
- Finance tools: reading an invoice or balance, with very limited and typically monitored write access given the sensitivity of this data.
- Databases: reading a scoped query result, with writes usually restricted to very narrow permissions.
- Collaboration tools: reading a shared message or document, and possibly posting an update to a team channel.
These categories are illustrative only. For the actual list of connectors available in WKIL, see the integrations page; for details on connecting a specific vendor to your agent, see that vendor's dedicated page.
What makes an integration agent-ready
Not every API is automatically suitable for an agent that makes decisions and calls tools without direct supervision at every step. An agent-ready integration typically has:
- Clear schemas: a precise description of expected inputs and outputs that lets the model call the tool correctly instead of guessing.
- Scoped auth: permissions limited to what the agent actually needs, not blanket access to the whole system.
- Idempotent writes: so retrying a call after an error doesn't accidentally repeat the same action.
- Useful error messages: clear enough about why something failed that the agent — or a supervising user — can decide the right next step instead of guessing.
Common failure modes
Even well-designed integrations fail in recurring ways worth anticipating and planning for:
- Stale data: reading a cached or delayed snapshot of a system means the agent's decision is based on information that's no longer accurate.
- Rate limits: exceeding the allowed number of calls temporarily halts the integration at an unpredictable time.
- Partial writes: a multi-step action failing midway leaves the system in an incomplete state that's hard to trace.
- Permission drift: permissions granted for a temporary purpose that remain active after the need has passed, quietly widening the risk surface.
How MCP relates to integrations
MCP (Model Context Protocol) isn't a new category of integration — it's a standard way of exposing the same read and write integrations through one interface that any protocol-supporting agent understands. Instead of building a bespoke integration for every system and every agent, a single MCP server can expose a given system's read and write tools for any compatible client to use. This doesn't remove the need to design an agent-ready integration with the properties above; it just provides a standard transport layer for it.
Integration category → read → write → risk to control
| Integration category | What the agent typically reads | What it may write | Typical risk to control |
|---|---|---|---|
| CRM | Customer record, interaction history, deal stage | A note, a field update, a deal stage change | Writing to the wrong record due to inexact identity matching |
| Relevant incoming messages | Drafting or sending a reply | Sending to the wrong recipient or leaking sensitive content | |
| Calendars | Available slots and existing appointments | Booking or rescheduling an appointment | Double-booking or an unintended cancellation |
| Support/ticketing | Open ticket details and its history | Creating a ticket or updating its status | Closing a ticket before the issue is actually resolved |
| Ecommerce | Order status and inventory | Updating a shipment or issuing a refund within limits | Unauthorised refund amount or scope |
| Finance tools | An invoice or account balance | Very limited, typically monitored writes | Overly broad access to sensitive financial data |
| Databases | A scoped query result | Narrowly scoped writes, if allowed at all | A broad query exposing data beyond what the agent needs |
| Collaboration tools | A shared message or document | Posting an update to a channel or document | Posting sensitive information to the wrong channel |