Through narrow tools shaped around tasks, not broad access to systems. Give the agent its own identity, start with read-only connections, and route every write through a checkpoint that applies its bounds before anything reaches the target system. Stamp each piece of data with its source and time. Then switch on writes one capability at a time, after testing.
Why do narrow tools matter more than the connection method?
Because the agent will use whatever it is given. A connection that lets the agent call any endpoint of your CRM, or run any query against a database, turns every capability into every possible action. A tool called "create draft refund for this case, up to the case value" can do one thing, and the checks around it can be precise.
The connection method, whether API, file, database or screen, matters less than how tightly each tool is drawn. Older systems need more care, covered in whether AI agents can work with legacy systems, but the principle is the same.
What are the practical steps?
- List what each capability must read and change. From the agent's role description, not from what the system offers.
- Design one tool per task. "Read invoice", "match invoice to order", "create draft payment". No general-purpose tools.
- Give the agent its own identity. Credentials are brokered per task and never visible to the model.
- Connect read-only first. Separate read and write connections so write access can be granted later and on its own.
- Put a checkpoint in front of every write. It checks scope, depth, limits, sources and approvals at the moment of action, and records the verdict.
- Stamp all data with source and time. So the agent and its reviewers know where each fact came from and how fresh it is.
- Make writes safe to retry. Each write carries a unique reference, so a timeout and retry cannot create a second payment or a duplicate record.
- Set rate limits and timeouts. Per tool, matched to what a person doing the job would do.
- Test in shadow with live reads. The agent sees real data and proposes writes; nothing is sent.
- Enable writes per capability once testing supports it, with a stop switch the process owner controls.
Which design choices make the connection safe?
| Design choice | Why it matters |
|---|---|
| One tool per task | Limits what any single mistake can do |
| Separate read and write connections | Writes can be granted, reviewed and revoked on their own |
| Checkpoint before every write | Bounds are enforced outside the model |
| Unique reference on every write | Retries cannot duplicate actions |
| Source and time on every fact | Stale or weak data is visible before it is used |
| Per-tool rate limits | A loop or error cannot flood a system |
| Stop switch per capability | One capability can be halted without stopping all |
The unique reference is easy to forget and painful to miss. Systems time out. An agent that retries a payment because the first call did not answer in time can pay twice unless the target system recognises the second call as the same payment.
What does this look like in practice?
Take a motor insurer connecting an agent to its claims system and its payments system. The agent's job is to gather documents and prepare settlements for simple glass claims.
The integration team builds five tools: read claim, read policy, list documents on a claim, request a document from the policyholder, and create a draft settlement. There is no tool to change the claim status or to release a payment; those stay with handlers. The draft settlement tool carries a unique reference per claim and is limited to the policy's glass cover. All five run under the agent's own identity.
In shadow, the agent proposes settlements on a month of live claims. One finding: the policy system returns the glass excess in a field the team had not mapped, so early drafts ignored it. The tool is fixed before writes are enabled. Detail on this kind of build is in how to connect an AI agent to your claims system, and for finance teams, which accounting systems an AI agent can connect to.
What should you check once it is live?
- Errors per tool, to spot a changed interface early.
- Retries, to confirm duplicates are being caught.
- Data freshness, especially where files or batches are involved.
- Differences between systems. When the agent reads the same fact from two systems, mismatches are worth watching; see reconciling records between two systems.
Connecting read-only first and enabling writes later mirrors the stages in deploying an AI agent: train, shadow, certify, widen.
Questions people ask
Should the agent connect directly or through an integration layer?
Through a layer you control, so tools, checks and limits sit in one place rather than in each system.
How long does connecting an agent usually take?
It depends on your systems more than the agent. Read-only connections are usually quick; writes take longer because of testing and approval.
Can we reuse connections built for other automation?
Often, if they can be narrowed to the agent's tasks and run under its own identity.