An AI agent that does not talk to your systems is a chat. To count as an operation, it has to read the order in the ERP, write the contact to the CRM and reply through the official WhatsApp. And that is exactly where most projects discover the schedule was optimistic: not because of the agent, but because of access to the data it needs.
This text covers what "without a long integration project" actually requires. The short answer: a ready connector is necessary and not sufficient. There are four other things, and they are what separates weeks from quarters.
The four levels of integration
Every system the agent needs to reach falls into one of these four levels, and the level defines the effort before any other variable.
| Level | What exists | Typical effort |
|---|---|---|
| A ready connector | The platform already has the integration built and maintained. | Configuration: credentials and permissions. |
| A documented API | REST with documentation (Swagger/OpenAPI) or equivalent. | Days. The documentation becomes the agent's tools. |
| An accessible database | No API, but read access to the database. | Weeks. Reading is workable; writing directly to the database is a risk. |
| Legacy with no API and no access | A closed system whose only interface is the screen. | A project of its own. This is where schedules blow up. |
The first job in any project is to classify each system into one of those levels. A project with three systems at level 1 and one at level 4 has level 4's schedule, and it is better to know that before promising a date.
What "without a long project" requires beyond the connector
1. Authentication that knows who asked
The fastest path is to give the agent a system credential with broad permissions. It works in the demo and fails the security review, because the ERP starts seeing the director and the intern as the same user. An integration that reaches production propagates the identity of whoever asked, or restricts the credential's scope to the minimum that agent needs. That has to exist in the connector, not be built afterwards.
2. Idempotency: an agent that retries must not create two orders
An agent retries when the call fails, when it times out, when the model decides to repeat itself. If the "create order" action is not idempotent, the retry creates a duplicate order, and the operation finds out at month-end close. Every write action needs an idempotency key or a prior check. It is the most forgotten item and the most expensive to discover late.
3. The boundary between reading and writing
Giving the agent broad read access and narrow write access is the design that survives a security review and the one that lets you start fast. The agent queries everything it needs in order to answer and only writes what was explicitly authorized, one operation at a time, with human approval where the value or the risk demands it. An integration that exposes everything as a write throws away the only cheap boundary there is.
4. Error handling that does not become silence
The ERP goes down at 3am. The API changes the format of a field. The credential expires. If the agent answers the customer as if nothing happened, the error becomes wrong information delivered with confidence. Every tool needs defined behavior on failure: retry with a limit, degrade to a partial answer or hand over to a person. And the error has to show up on the dashboard, not only in the log.
A ready connector delivers the transport. The four items above deliver the confidence. A platform that has the connector list and not the four will require your team to build the four, system by system.
Patterns that shorten the project
- Start with reading. An agent that queries the ERP and answers already changes an operation, and it passes review in days. Writing comes later, one operation at a time.
- Publish capabilities, not the API. The agent does not need the ERP's two hundred routes. It needs "look up order", "check stock" and "open a case". A tool with a business name and typed parameters makes fewer mistakes than a tool that mirrors the API.
- Use the documentation you already have. If the system has OpenAPI or Swagger, that documentation already describes the tools. A platform that reads that format turns days of integration into hours.
- MCP for whatever more than one agent will consume. Publish the system once, in an MCP server, and consume it in every agent. See what MCP solves and what it does not.
- The official channel from the start. Unofficial WhatsApp looks faster and takes the whole project down when the number is blocked. Approval for the official API takes time; start with it.
What to ask before signing
- Are my systems on the connector list? Which ones, exactly, and with which operations?
- For a system that has a documented API but no connector, how long does it take? Who does it?
- How does the agent authenticate to the ERP: with its own credential or by propagating the user?
- What happens if the agent tries to create the same record twice?
- Can I grant broad read and restricted write, per tool?
- When the integrated system goes down, what does the agent do, and where do I see that?
- For legacy with no API, what is the path, and is it in the budget?
How Runflow handles integration
The platform brings more than 150 ready connectors for ERPs, CRMs, APIs and channels (HubSpot, Twilio, Slack and your legacy systems among them), with MCP and internal tools for whatever has no connector. For a system with a documented API, the REST or Swagger description becomes the agent's tools. In the TypeScript SDK, every tool is defined with types and validation, which is what makes the boundary between reading and writing, and human approval per operation, possible.
WhatsApp comes in through the Conversation Hub, on Meta's official API, and every tool call is recorded with its parameters and return, reproducible, which is where a failure in the integrated system shows up before it becomes a wrong answer to the customer. For a level 4 system, legacy with no API, the honest answer is that it is a project, and it is the kind of project the Forward Deployed engineers do inside your operation, with your team.
