What systems does an AI agent need to connect to?

The default assumption is that an agent needs to be wired into everything before it is useful. It does not, and trying to do that first is the most reliable way to turn a three-week deployment into a six-month one.

Read first, write later

An agent that can read your systems and cannot change anything is already useful, because the overwhelming majority of customer questions are requests for information. Where is my order. What do I owe. When is my appointment. What plan am I on.

Write access is where the risk and the approval conversations live. Separating the two means you can be answering real questions while the discussion about what the agent may change is still happening.

Start with the system behind the most common question

Look at your last two hundred customer contacts and find the single most common request. Connect whatever system holds that answer. For a retailer that is the order system, for a clinic the scheduler, for a software business the billing and entitlement records.

One well-chosen connection typically covers a large share of contacts. The second one covers much less, and the fifth covers very little, which is why the sequence matters more than the total.

Documentation counts as a system

Your help center, policy documents and internal wiki are where most policy answers come from, and connecting them is usually easier than connecting an application. It is also where the quality problem shows up fastest: an agent reading stale documentation will confidently repeat things that stopped being true.

Deploying an agent tends to surface how out of date the documentation is, which is uncomfortable and genuinely valuable. Every wrong answer traces back to a specific document somebody can fix.

Permissions should be narrow

• Give it the minimum scope that does the job. An agent that answers order status does not need access to your payroll system, and read-only is the default.
• Use a dedicated service account rather than a person's credentials, so the access is visible, revocable and does not break when somebody leaves.
• Have it inherit the permission model you already have. Nobody should be able to see a number through the agent that they could not see directly.
• Log what it read, not just what it said, so an access question can be answered from the record.

When a system has no API

It happens, particularly with older line-of-business software, and it is better to find out in week one. The options are usually a scheduled export, a middleware layer you may already own, or accepting that the agent escalates anything needing that system.

That last option is a legitimate answer rather than a failure. An agent that handles eighty percent of contacts and cleanly hands over the rest is worth having. An agent that waits for a perfect integration is worth nothing, because it is not running.

Write-back is where the time saving compounds

Once the reading works, the highest-value write is not changing customer data, it is logging the conversation back onto the contact record. The summary, the outcome, what was asked, what was resolved.

This is unglamorous and it removes a real cost: the notes your team currently writes by hand, inconsistently, when they remember. Getting it automatically, in the same shape every time, improves everything downstream that reads it.