AI agent integration is the work of connecting an AI agent to the business systems it needs to finish a real job: reading records, writing updates and taking actions inside those systems under a defined permission scope. Without integrations, an agent can only produce text. With them, it can complete the workflow end to end.
Integration is what separates a demo from something your team relies on. The model is rarely what holds a project back. What usually holds it back is whether the agent can reach your inbox, your CRM, your project board and your accounting file, with the right permissions, at the volume your work requires.
This guide is for the person who has to answer that question before a build starts. It covers the five ways an agent can connect to a system, where your data probably lives today, six checks that tell you whether a given system is ready, a scorecard you can run on your own stack in an afternoon, where the agent's credentials end up, and the blockers that show up most often.
Why does integration decide whether an AI agent is useful?
Integration decides usefulness because every workflow worth automating already lives inside software you own. The agent has to get into those systems to see the trigger, gather context and record the result. If it cannot, a person still has to do the part that takes the time, and the agent becomes one more place to paste things.
Take a concrete workflow. "Follow up on a stalled lead" sounds like a writing task, but it has six steps: notice the lead has gone quiet, read the last three touches, check whether a meeting was already booked, draft something that reflects all of it, send it from the right identity, and log it where the next person will see it. Only the drafting step is writing. The other five depend on integration.
This is also where a managed build differs most from a do-it-yourself platform. Signing up for an agent tool takes minutes. The real work is getting that agent authorized against your systems, scoped correctly and reliable at your volume. We cover that tradeoff in more depth in Build Your Own AI Agents or Buy a Managed Service?, and the wider set of options in AI agents for business.
What are the five ways an AI agent can connect to a system?
An agent can reach a system in five ways, and they are not interchangeable. From most to least useful, they are an official API, a partner or restricted API, an event feed with no write path, a file exchange, and screen-level access with no API at all. The type a system offers sets the limit on what the agent can do there.
| Connection type | What it means | What the agent can do | What it costs you |
|---|---|---|---|
| Official public API | Documented endpoints, published auth, stable versioning | Read and write the objects the API exposes, on demand | Scope approval and rate limit planning |
| Partner or restricted API | Access exists but is gated behind an application, a tier, or a vendor review | Same as above, once approved | A waiting period you do not control |
| Event feed or webhook only | The system pushes notifications out but accepts nothing back | React to events, but write results somewhere else | A second system has to hold the output |
| File exchange or export | Scheduled CSV, SFTP drop, or report export | Work on a snapshot, not live state | Latency, and a reconciliation step |
| Screen-level only | No API, so access means driving the interface | Narrow, brittle, breaks on redesigns | Ongoing maintenance, and higher risk |
Most systems are a mix. The API often covers most of what you need, while the last action you care about is available only in the interface. Keep in mind too that the connection type belongs to the system rather than the agent, so no vendor can give you an endpoint the system does not publish. One wrinkle the connection type hides: the same system often holds several accounts for one person, and an agent that reads only the first of them looks like it succeeded. That is the problem behind reading six calendars for one person.
Where does your business data actually live, and how does an agent reach it?
Most companies hold the data for one workflow in five or six different places, each with its own connection type and its own likely failure. The table below maps the places we find data most often to the way an agent normally reaches them, and to the readiness check that tends to fail there first. Use it to predict where a workflow will stall before you score anything.
| Where the data lives | How an agent usually reaches it | The check most likely to fail there |
|---|---|---|
| Email and calendar | Official API under a reviewed permission scope | Scope approval, and the sign-in method your tenant allows |
| CRM | Official API, often gated to a higher plan tier | Whether your plan includes API access at all |
| Accounting software | Official API, frequently read-only in practice | Write permission, and somewhere to test |
| Help desk or ticketing | Official API with an event feed alongside it | Rate limits, usually during the first history read |
| Shared spreadsheets | Official API, but the sheet itself is the schema | A reliable match key, since anyone can rename a column |
| Databases and warehouses | Direct connection or a query API, read-only by default | Who can approve a credential, and whether a read replica exists |
| Document storage | Official API, with permissions that vary per file | Per-item permissions, which are not the same as account-level scope |
| Internal or custom apps | Whatever your own team built, which is sometimes nothing | Whether anyone still owns the code |
| Legacy desktop software | Screen-level access, if anything | All six, and this is the one to route around |
Spreadsheets are the row that surprises people. They look like the easy case and are usually the fragile one, because the structure is a convention rather than a schema, and nothing stops a colleague from inserting a column. Internal apps go the other way: they sound hard, but your own team can add the endpoint the workflow needs, which no third-party vendor will do for you.
What makes a system ready for an AI agent?
A system is ready when six things are true: the API covers the actions your workflow needs, the agent can hold its own identity, someone can approve the permission scope, the rate limits fit your volume, records carry a reliable key to match on, and there is a place to test that is not production. If one is missing, the integration usually still happens, but later and smaller than planned.
1. The API covers each action in the workflow
Most API documentation leads with the objects it exposes, such as contacts, invoices, tickets and tasks. What you need to know is narrower: whether each step of your workflow has an endpoint. Walk the workflow step by step and check. Reading a deal is usually supported. Moving it to a specific stage, attaching a note that a particular person will see and triggering the notification that follows may each have a different answer.
2. The agent can hold its own identity
An agent that logs in as a person inherits all of that person's access, leaves an audit trail with the wrong name on it, and stops working the day that person changes their password or leaves. You want a service account, a dedicated user seat or a scoped application credential. Google describes a service account as a special kind of account typically used by an application or compute workload rather than a person, which is exactly the distinction to ask your own vendors about. Some systems support it well, some charge for an extra seat, and a system that offers only shared logins has a real readiness problem.
3. Someone can approve the permission scope
Granting access is often as much a vendor decision as yours. Google categorizes OAuth scopes as non-sensitive, sensitive or restricted, and apps requesting sensitive or restricted scopes must complete Google's OAuth app verification before being granted access. Google's own guidance is to select the minimum necessary scopes and prefer non-sensitive alternatives where they exist, partly because broader scopes trigger additional review. Find out early whether your workflow needs a reviewed scope, because that queue sits outside your project plan.
There is a second approval people miss, and it is not about permissions at all. It is the sign-in method. Microsoft's security defaults block device code flow alongside legacy authentication protocols, and Microsoft says those defaults are rolled out to all new tenants at creation. A connector that signs in that way will fail in a recent Microsoft tenant no matter how carefully its permissions are configured, because the block is a tenant setting rather than an application setting. Ask which sign-in method a connector uses before you plan a date around it.
Deciding how much access to grant is its own exercise, and we cover it separately in What Access Should an AI Agent Have to Your Business Systems?.
4. The rate limits fit your volume
Every major platform throttles requests. Microsoft states that Graph returns HTTP 429 with a suggested wait time when a throttling threshold is exceeded, that thresholds vary by request type, and that writes can be throttled while reads still succeed. Slack publishes tiered per-method limits, with most methods allowing at least 20 requests per minute and message posting generally allowed at one per second per channel.
Limits also change. Slack's own rate limit page records that effective May 29, 2025, newly created commercially distributed apps that have not been approved for the Slack Marketplace are subject to new limits on the conversations.history and conversations.replies methods. A change like that affects what a backfill or a history read can do, so build on current limits and plan to revisit them.
5. Records carry a reliable key to match on
An agent that cannot tell whether two records are the same customer will create a third. Before connecting a system, check what uniquely identifies a record, whether that identifier also exists in the other systems in the workflow, and how many duplicates are already sitting there. You do not need a perfect data set, only one dependable join between the systems the agent has to cross.
6. There is somewhere to test that is not production
Sandboxes, developer accounts and test workspaces exist so that a first integration does not learn on live customer records. Where there is no sandbox, the fallback is a read-only first phase plus a narrow set of test records. Make that decision before the build starts.
The AI agent integration readiness scorecard
Score each system you are considering on the six checks above, from 0 to 3. Multiply each score by its weight, add the six results, then divide by three. The result is a number out of 100 that tells you whether to connect the system in phase one, scope a blocker first or route around it.
| Check | Weight | Score 0 | Score 1 | Score 2 | Score 3 |
|---|---|---|---|---|---|
| API covers the workflow actions | 25 | No API | Read-only | Most actions | Every action |
| Agent can hold its own identity | 15 | Shared login only | Named human seat | Extra paid seat available | Service account supported |
| Permission scope can be approved | 15 | Nobody can approve | Approver unclear | Approver known, review needed | Approved and granted |
| Rate limits fit the volume | 15 | Unknown or clearly too low | Tight, needs batching | Comfortable | Generous, published |
| Records have a reliable match key | 20 | No stable identifier | Identifier exists, many duplicates | Clean inside one system | Clean and shared across systems |
| Test environment exists | 10 | Production only | Test records in production | Developer account | Full sandbox |
Use the bands below to read the result. They are a planning heuristic we use to sequence work, and they are not a validated industry benchmark.
| Score | What it means | What to do |
|---|---|---|
| 80 to 100 | Ready | Connect it in the first build |
| 60 to 79 | Ready with one known blocker | Connect it, and scope that blocker as an explicit task with an owner |
| 40 to 59 | Not ready for phase one | Keep the system in the workflow but route the agent around it for now |
| Below 40 | Not connectable yet | Leave it out, and revisit only if the workflow genuinely depends on it |
The scorecard matters most when your highest-value system gets the lowest score. That outcome still tells you something useful: start where the agent can work today, and come back to that system later.
Where do the agent's credentials live, and who can revoke them?
An agent's access to your systems is a stored credential sitting somewhere, and the four places it can sit have different consequences for auditing and for the day you want access to stop. Ask any vendor which of the four rows below describes their design, because the answer tells you how you get your access back.
| Where the credential sits | What that means day to day | How you revoke it |
|---|---|---|
| The vendor's multi-tenant cloud | You authorize their application against your systems, and their platform holds the token for every customer | Remove the app's access in your own system's admin console |
| Your own cloud tenant | The application is registered in your directory, so your admins can see and audit it | Remove the registration or the consent grant yourself |
| The environment running your agent | The token is written where that one agent runs, so nothing central can replay it | Revoke at the provider, then confirm that environment holds no working token |
| A person's browser session | The agent acts as that person for as long as they stay signed in | Change their password, which ends the agent's access too |
Microsoft draws the same line in its own permissions model. It describes delegated access, where an app calls on behalf of a signed-in user, and app-only access, where the app calls with its own identity and no signed-in user. Those are different audit stories, and the choice is usually made for you by whichever connector you pick.
Here is how we handle it on our own service, since it is a fair question to ask before signing anything. Our design is the first row of the table above. You connect each app yourself and approve the request on the provider's own consent screen, where you see everything being asked for and can decline it. The integration platform we use then holds the token, in a project set up for your deployment alone rather than one shared with other customers. You can revoke access from that app's own settings at any time, so cutting it off does not depend on us.
Which systems should you connect first?
Connect the system that holds the workflow's trigger and the system that holds its finish line. Those two make the agent's work visible and complete. Add the channel where the responsible person already works, so approvals and exceptions reach them. Everything else, including reporting and analytics, can wait for a later phase.
| Priority | The system that holds | The question it answers |
|---|---|---|
| 1 | The trigger | How does the agent know there is work to do? |
| 2 | The finish line | Where does the result have to land to count as done? |
| 3 | The human channel | Where does the agent ask, and where does it escalate? |
| 4 | Context sources | What does the agent need to read to do the work well? |
| 5 | Reporting | How do we see whether it is working? |
For VantaSoft customers, the human channel is the messaging platform the team already works in, whether that is Slack, Microsoft Teams or something else. The approval design behind it matters as much as the connection itself, and it is the subject of Human in the Loop for AI Agents.
There is also a commercial point to plan for. On our own Agent Service, minor in-scope configuration changes are included in the subscription, while new integrations are scoped as a change order. That is a good reason to name the systems you expect to need during discovery rather than finding them after launch.
What usually blocks an AI agent integration?
The blockers are predictable. These are the ones we see most often, with the realistic response to each.
A vendor review stands between you and the scope you need
Start the application on day one of the project rather than after the build. In the meantime, design the first phase around the scopes you already have.
The one action you need has no endpoint
Split the workflow. Let the agent do everything up to that action, then hand a prepared item to a person for the final click. That often keeps most of the time saving without the risk of the agent taking that action itself.
Rate limits do not fit the volume
Batch requests, schedule them and cache the results. Treat a history backfill as a separate one-time job rather than something the live agent does on every run.
Records cannot be matched across systems
Pick one system as the source of truth for identity, and have the agent write its matching key back into the others as it works. Matching then improves over time, and you do not need a cleanup project first.
Everyone shares one login
Ask what a dedicated seat costs. It is almost always cheaper than the audit and offboarding problems that shared credentials create.
The API is gated behind a higher plan tier
Price the upgrade honestly against the workflow's value before you treat it as a blocker. Sometimes it is one tier and a small monthly difference. Sometimes it changes the business case, and then the right move is to put the number into your AI agent ROI worksheet rather than abandon the idea.
Do you need an integration platform to connect an AI agent?
Search for this topic and most of what you find is an integration platform selling itself: a unified API or workflow layer that sits between your agent and your systems. It is a real category and it removes real work, mostly the per-system plumbing plus one place to handle auth, retries and errors. What it cannot do is change the answer to any of the six readiness checks.
An integration layer will not create an endpoint your system does not publish, approve a scope your vendor has to review, merge your duplicate records or raise a published rate limit. Those are properties of your systems, and they survive whatever you put in front of them.
The decision comes down to counting systems. If one workflow touches two or three systems that all have good APIs, a platform adds a dependency and a bill in exchange for little. If you are connecting the same dozen systems repeatedly, across business units or customers, standardizing starts to pay. Score your systems first, then decide, because the scores do not change either way.
Does MCP remove the integration work?
No. The Model Context Protocol describes itself as an open-source standard for connecting AI applications to external systems, and compares itself to a USB-C port for AI applications. It standardizes how an agent talks to a tool, which is useful. It cannot create an API where a system has none, grant permissions you have not been approved for, fix duplicate records or raise a rate limit.
MCP means less of the plumbing has to be custom than it used to. The six readiness checks still apply.
Frequently asked questions
How many systems does a first AI agent need?
Usually two or three: the system that holds the trigger, the one that holds the finish line, and the channel where the responsible person can be reached. Agents that touch seven systems in their first week are harder to test, slower to get approved and much harder to diagnose when something goes wrong. Add systems once the first version has earned trust.
Do we have to clean our data before we start?
No, and waiting for clean data is a common reason projects never start. What you need is one dependable way to match a record across the systems in the workflow. Everything else can improve while the agent runs.
How does this work if each of our business units runs a different tech stack?
Score each unit's stack separately and build for one of them first. An agent designed to work across several different stacks at once inherits every weakness in all of them, and you cannot tell which stack caused a failure. Pick the unit whose workflow and systems score highest, prove the workflow there, then reuse the pattern rather than the configuration.
Can an agent just use the browser if a system has no API?
It can, and sometimes that is the right answer for a narrow, stable task. Understand the tradeoff first. Interface-level access breaks when the vendor redesigns a page, and it is harder to permission precisely and harder to audit. We treat it as a deliberate exception rather than a default.
Who owns the connection, us or the vendor?
You own the account and the data. A managed build should mean the agent is authorized against your systems under scopes you approved, in an environment specific to your company, with a documented way to revoke access. Ask any vendor exactly where credentials live and how you disconnect.
What if we need to add a system after launch?
Expect to, and ask how it is handled commercially before you sign. On our service, minor in-scope configuration is included and a new integration is scoped as a change order, so naming the likely systems during discovery keeps the plan realistic.
Do we have to build these integrations ourselves?
No. That is the main difference between a platform you configure and a service built for you. Our delivery sequence starts with discovery, then moves to building and provisioning the agents, integrations and managed environment, then testing together, launch, and ongoing coaching and maintenance. We cover the rest of that sequence in How to Implement an AI Agent in Your Business, and how to judge the firm doing it in How to Choose an AI Agent Development Company.
Score your systems before the first build call
The quickest way to move an agent project forward is to stop debating capabilities and start scoring systems. Take your top workflow, list the systems it touches, run each one through the six checks and bring the scores to your first conversation. You will know right away which parts of the workflow an agent can own now and which parts need a decision first.
If you want us to look over that list with you, start with a workflow discovery session. It takes 30 minutes, and you come away with a clear view of what can be connected, what has to be routed around and what it would take to change that.
