How does an agent connect to an ERP, a CRM or a credit system?

A connector is the piece that translates between the agent and a system. On the system side it speaks the system's language (an API, a database, a file, an interface). On the agent side it exposes a short catalog of actions with clear names and purposes, like "look up a customer's balance" or "record a promise to pay".

That catalog does two jobs. The agent can't do anything the catalog doesn't include, and each action can be validated, limited and logged on its own. A well-built connector is what turns "a model that can write" into "an agent that can work without putting the system at risk".

It depends on whether a person is behind the request or the process runs without immediate supervision.

• Direct API. The path for unattended processes: overnight collections, reconciliations, batch loads. The connector uses the agent's own credentials with minimum permissions, and the process core calls it.
• MCP. The Model Context Protocol is an open standard for connecting AI applications to external systems. It is especially useful when the tools your team already uses (an AI assistant, an editor) need to reach live systems through a defined entry point, and when you want to write a connector once and have several agents use it.
• Both, as the case requires. It is common for one core to use APIs for unattended work and expose MCP for your team's own queries.

Some enterprise software vendors publish their own MCP servers. If a system already offers an official entry point, we use it instead of building another. But check with the vendor what kind of use it is designed for: many of those entry points assume an authenticated person behind the request, not a process running on its own. We confirm that system by system during the diagnostic.

It happens more than people admit. The options, from best to worst:

1. An API that exists but nobody uses. Many systems ship one that was never turned on. Check first.
2. Read access to the database. To query without touching the system, through a replica or read-only view agreed with IT.
3. Controlled file exchange. Scheduled imports and exports the system already knows how to do.
4. An entry point we build. A small service, sometimes with interface automation as a last resort, that gives the agent a clean action even if the system behind it is closed.

The rule is the same in every case: the agent sees a named action, not the screen and not the database. If the entry point changes internally, the catalog the agent sees doesn't, and the process keeps running.

The minimum for its task. In practice:

• The agent's own credentials, never a person's, so each action is attributed to the agent in both systems' logs.
• Separate read and write permissions, with write limited to what the process needs.
• Limits per action (which ranges, which statuses, what volume) that live in the connector, not in the text used to instruct the model.
• Sensitive actions flagged for human approval before they run.

That last point matters: a limit that exists only in an instruction to the model is a request, not a control. Controls live in the connector's code. We go deeper in agent governance and security and data.

• Which system is the source of truth for each piece of data, so the agent doesn't duplicate it.
• Who authorizes access and how it is revoked. A connector can be switched off without touching the system.
• What usage limits the system's vendor imposes and how they are respected.
• How credentials are stored: outside the code and outside the model's instructions.
• What happens when the system doesn't respond: bounded retries and escalation, never blind persistence.
• How it is tested against an environment that isn't production.

With those answers, opening an entry point is ordinary engineering work. To see what gets built on top of them, go to agentic cores. If your worry is very old systems, read build without migrating.