A chatbot that only talks is useful. An agent that can look up a customer, check an order, and draft an update is far more useful. The difference is connections: the agent needs a way to reach the systems where your work actually happens.

You do not need to be technical to make good decisions here. This guide explains how those connections work, and what to ask before you give an agent access to anything.

How an agent uses a tool

An AI model on its own can only read and write text. To act in the world, it is given a list of tools, each with a name and a description, such as "look up order by number" or "create support ticket".

A typical exchange looks like this:

  1. A customer asks where their order is.
  2. The model decides the "look up order" tool would help, and requests it with the order number.
  3. Your system, not the model, runs that lookup and returns the result.
  4. The model reads the result and writes a reply.

The important detail is step 3. The model only asks for an action. Your software decides whether to carry it out, which is where permissions and safety checks live.

Common ways to connect

  • APIs: most modern business software offers an API, a structured way for programs to read and update data. This is usually the most reliable option.
  • Standard connectors: open standards such as the Model Context Protocol (MCP) give AI applications a common way to connect to tools and data, and many products now offer ready-made connectors.
  • Automation platforms: tools that link apps together can give an agent access to many services quickly, which is useful for pilots.
  • Custom connections: for older systems without an API, a small custom service or a database view may be needed.

Read access versus write access

The most useful distinction is between reading and doing:

  • Read access lets the agent look things up, such as order status or help articles. The main risk is exposing data to the wrong person.
  • Write access lets it change things, such as updating a record or sending a message. Mistakes here have direct consequences.

A sensible path is to start with read access only, add low-risk writes such as drafting replies or creating tickets, and leave high-impact actions behind a human approval.

Keeping connections safe

  • Least privilege. Give the agent only the access its task needs, and nothing more.
  • Use each person's permissions. An agent helping a user should not see what that user cannot see.
  • Require confirmation for important actions, such as sending, paying, or deleting.
  • Keep logs. Record each tool call, so you can review what happened.
  • Set limits. Cap how often and how much the agent can do, to contain mistakes and costs.
  • Treat outside content as data. Emails and web pages an agent reads can contain instructions designed to mislead it, so they must not be able to trigger actions on their own.
  • Protect credentials. Keep keys in a secure store, never in prompts, and make them easy to revoke.

Questions to ask before connecting a system

  1. What does the agent need to read, and what does it need to change?
  2. Which actions need a person's approval?
  3. Whose permissions does it use?
  4. What is logged, and who reviews it?
  5. How do we turn it off quickly if something goes wrong?

Example: a support agent's first connections

A support agent could begin with two read-only tools: searching help articles and looking up order status. Once it proves reliable, a third tool could let it draft a refund request that a person approves. Nothing changes in the order system without that approval. This is an illustrative example; the right tools depend on your systems and risk level.

The bottom line

Connections are what turn an AI model into a useful agent, and permissions are what keep it safe. Start small, begin with read access, and add actions only where you have clear limits and review.

If you want help deciding what an agent should connect to, and how to do it safely, see our AI agents and knowledge assistant service or email us.