What it actually means for an AI agent to integrate with your systems
An AI agent can read data, write it, or decide with it: three integration levels with different risk profiles and permissions, not one sales pitch line.

Iván Itzcovich
Co-founder
"It integrates with the tools you already use" is one of the most repeated and least specific phrases in this market. Every vendor says it, and it means completely different things depending on what the agent actually does once it's connected.
What's really behind "it integrates with your tools"?
There are three capabilities with very different risk profiles, and it's worth asking which of the three is actually on the table: reading data, writing data, or deciding with that data. Confusing them is the most common reason an integration project stalls without anyone quite understanding why.
Read, write, decide — three different integrations
What it does
Look up an order's status, an account balance, a shipping date. Nothing gets changed.
Worst case if it fails
A stale answer. Nobody loses a record or a dollar.
Who has to be in the room
Nobody else. A read-only API key and a sane timeout.
What it does
Change a shipping address, generate a return, book a meeting.
Worst case if it fails
A modified record you need to be able to trace. Demands a narrow scope and a log of who and when.
Who has to be in the room
Whoever owns permissions. It's the same conversation as with a new hire.
What it does
Approve a refund, offer a discount, cancel an order with nobody reviewing it afterwards.
Worst case if it fails
A transaction the company never authorized, that someone will have to explain.
Who has to be in the room
Legal, finance, sometimes compliance. It's governance, not architecture.
The examples are illustrative. The three levels, and where projects stall, are the distinction this article draws.
What does it mean for an agent to read?
Reading means looking something up: an order's status, an account balance, a shipping date. The agent requests a piece of data, gets it back, and hands it over in the conversation. Nothing gets changed. This is where almost every serious integration starts, and for good reason: the worst-case risk of a bad read is a stale answer. Nobody loses a record or a dollar over a query.
The engineering here is boring on purpose: a read-only API key, a sane timeout, done. If a vendor takes weeks to deliver this, the problem isn't the model.
What changes once the agent starts writing?
Writing means creating or modifying a record: changing a shipping address, generating a return, booking a meeting. That's where a question comes up that reading never forces: what happens if the agent gets it wrong? The technical answer is to scope that write as narrowly as possible (a specific "create a return ticket" action, not write access to the entire orders table) and log an auditable trail for every action: who executed it, and when.
The useful comparison here isn't against another vendor, it's against how you'd give access to a new hire. Nobody hands someone who started this week write access to the entire customer database on day one; they get a narrow form scoped to one action. An agent deserves the same standard, and in practice almost never gets it: it's given all or nothing, because designing granular permissions is more work than flipping on a generic integration.
What a narrow write scope looks like
tok_agent_prod_7f2a…- GET
/orders/{id}/statusLook up status — read level✓ allowed - POST
/returnsCreate a return ticket — one specific action✓ allowed - PATCH
/orders/{id}/addressEdit a single order, logged with who and when✓ allowed - POST
/orders/bulk-editUnscoped write access to the whole orders table✗ denied
When does an agent move to deciding, and why does the conversation change there?
Deciding means choosing between actions with a financial consequence: approving a refund, offering a discount, canceling an order with nobody reviewing it afterward. This is where the problem stops being technical. The question is no longer "can the model do this?" (it almost always can) but "who approves it, up to what amount, and what gets escalated to a person?" It's a governance conversation, not an architecture one, and it tends to pull in teams that never show up in a product meeting: legal, finance, sometimes compliance.
Gartner put a number on this in its Market Guide for Guardian Agents (February 25, 2026, read here via security firm Opsin's coverage of that report, not the original Gartner document, which sits behind a paywall). The report's sentence, verbatim: "through 2028, at least 80% of unauthorized AI agent transactions will be caused by internal violations of enterprise policies concerning information oversharing, unacceptable use or misguided AI behavior rather than from malicious attacks." The risk doesn't come from outside. It comes from someone giving an agent more scope than they'd fully thought through.
80%
Where do integration projects actually get stuck?
Almost never at reading. Almost always between writing and deciding, and almost never because of a model limitation. They get stuck because nobody defined the exact scope of the write, or because nobody wants to be the one who signs off on "the agent approves refunds up to this amount without going through me." A better model doesn't fix that. An uncomfortable meeting someone has to call does.
(If a vendor offers you "deciding" integration in the first week and your own company's approval process for that isn't written down anywhere yet, that part of the deal hasn't been thought through. It happened to us the first time: we underestimated how much time would go into defining who approves what, not into building the integration itself.)
What to ask before accepting that something "integrates with your tools"
Three short questions separate a real integration from a sales pitch. Does the agent read, write, or decide? If it writes, what's the exact scope of that write, and where does the log of each action live? If it decides, who approves it, and up to what limit does it act on its own?
A question that says nothing
- Does your product use AI?
The three that do
- Does the agent read, write, or decide?
- ★ the one that stalls most projectsIf it writes, what's the exact scope and where's the log?
- If it decides, who approves it and up to what limit does it act alone?
None of the three depend on how large the model is. They depend on how much time someone spent thinking through permissions before turning the integration on.
None of the three depend on how large the model behind it is. They depend on how much time someone on the other end spent thinking through permissions before turning the integration on. That part doesn't automate, and it's what actually separates a connected agent from one that only looks connected.
Sources: Gartner, Market Guide for Guardian Agents (February 25, 2026), via security firm Opsin's coverage of that report ("Gartner® Market Guide for Guardian Agents: What We Believe It Means for Enterprise AI Security," opsinsecurity.com, March 2026). Secondhand reading: the original Gartner document sits behind a paywall.

Iván Itzcovich · Co-founder, StudioChat
Want agents like these working for your team?
Talk to us now