I’ve noticed a pattern over the past few months.
More and more companies are looking at AI agents as a way to integrate systems.
On the surface… I get it.
Why spend weeks building an integration when an agent can look at one system, understand the data, transform it, and put it into another? There are absolutely situations where that’s useful!
But I think we’re starting to ask agents to solve problems that don’t require continuous intelligence.
An agent is a worker. A lot of us are using them as plumbing.
Infrastructure should be boring
If System A says a customer is named Jane Smith, has membership X, and owes $400, we shouldn’t need something intelligent to work out what all that means every single time we want to move the information into System B.
Once we’ve established what the data means, where it belongs, and how it should be transformed, we’ve learned something.
That knowledge can become infrastructure.
But with an agent-first approach, there’s a risk that we end up paying a model to repeatedly reason through a problem we’ve already solved.
That changes the economics.
A traditional integration has an obvious upfront cost. You define the problem, map the data, build the pipes, test them, and maintain them.
An agent can make that initial cost look dramatically smaller. But every time the task runs, you’re potentially paying for tokens, orchestration, retries, monitoring, and (more often than you’d like) human intervention.
The cost hasn’t disappeared. We’ve changed when we pay it and made it much harder to predict.
I’ve seen this happen in practice
A client had built a set of AI-powered workflows to process, triage, and follow up on specific email inquiries.
And it worked.
Every time an email arrived, the workflow would ingest the message, build a lookup, load a reference spreadsheet of several hundred rows into context, determine what needed to happen, and generate a response or notification.
Generating the response is where the intelligence was. The rest was the same work, redone from scratch, every single time.
Each run cost between 60 and 200 credits. At the plan they were on, $100 a month bought 15,000 of them.
So $100 a month processed somewhere between 75 and 250 emails.
We replaced the spreadsheet processing with a structured API lookup. Same workflow, same outputs. The reference data is now fetched deterministically rather than reasoned over.
That took it to 10–20 credits per run.
The same $100 now processes between 750 and 1,500 emails per month.
Nothing about that change made the system smarter. It just stopped paying a model to re-read the same few hundred rows every time an email arrived.
The obvious response to this is that inference keeps getting cheaper.
It does. And you could reasonably argue that we should have cached that spreadsheet rather than re-reading it, which would have cut the bill substantially.
Both are true. But neither changes my view.
Cheaper tokens rarely turn into savings. They turn into longer context, more tool calls, more reasoning steps, and more agents. Every price drop I’ve watched so far has been absorbed within months by doing more per run, rather than by paying less per run.
And caching a lookup makes the wrong shape cheaper. It doesn’t make it right. You’re still asking a model to interpret data you already understand. You’ve added a cache invalidation problem on top of that. And the answer is still probabilistic.
A cheaper probabilistic lookup is still a probabilistic lookup.
Price was never the strongest part of this argument anyway. If the bill were the only problem here, you could wait eighteen months and it would solve itself.
Reliability doesn’t get cheaper.
Then there’s the question of failure
This is the part I’d worry about most.
Traditional integrations fail too. The difference is that they’re built around deterministic expectations. Input X should produce output Y.
When something doesn’t conform, well-designed integration infrastructure can reject it, log it, retry it, or flag it for someone to investigate.
Agents have deliberately been given more room to reason. That also gives them more room to be wrong.
There are two failure modes here that concern me.
The first is obvious. An agent misunderstands something, takes an action it shouldn’t, and creates a very visible problem. Wiped databases, corrupted records, tests run against production. Those are bad days, but they’re loud. You find out immediately, and you fix it.
The second is quieter, and I think it’s worse.
The workflow keeps running. Everything appears healthy. But something is being interpreted slightly incorrectly, categorized inconsistently, skipped, duplicated, or transformed in a way nobody notices.
A comma shifts in a CSV export. A number or date comes through formatted incorrectly. A customer gets set up without pricing.
Nothing fails, and nobody gets alerted. The dashboard stays green.
Then, three months later, someone asks why the numbers don’t reconcile, and the answer is buried in ninety days of decisions that were each made slightly differently.
There’s a related point that I think gets underestimated.
A deterministic integration can be inspected. You can read the mapping, re-run the input, and get the same output. When someone asks why a record changed in March, there’s an answer, and it’s the same answer every time you ask.
You can log what an agent did. That gets you less than it sounds like. Run the same input again and you may get a different answer, reached a different way. What you have is a record of one event rather than an explanation of a rule.
For plenty of workflows, that’s fine. For anything that ends up in a financial statement, a regulatory filing, or a customer contract, “we have the trace, but we can’t reproduce it” is not where you want to be when someone asks.
I’m not arguing against agents
We deploy them ourselves.
I’m bullish about what happens when AI can reason across a business’s operational context. That’s exactly why I think we should be careful about where we point it.
The worker framing is what I keep coming back to.
A worker earns their keep when a task needs judgment, context, or the ability to handle ambiguity. Someone who can look at a situation and decide what to do about it.
You wouldn’t hire someone capable and then sit them at a desk re-reading the same form ten thousand times. Not because they couldn’t do it, but because it would be a waste of them.
If two systems need to exchange the same well-defined information thousands of times, nobody needs a worker standing between them interpreting it each time.
They need a reliable road. Then the worker can go and do something worth their time.
Agents are good at scoping integrations
There’s a reason people reach for an agent instead of building the pipe, and it’s not laziness.
Often you genuinely don’t know what the mapping is yet. Which fields matter, which edge cases exist, what the exceptions actually look like. Writing a specification for something you don’t understand yet is slow and usually wrong.
An agent is a very good way to find out.
Point it at the problem, let it reason through a few (hundred) real cases, and watch what it does. Some of those decisions will turn out to be genuine judgment calls. Most of them, in my experience, turn out to be a rule you could have written down.
The mistake isn’t using an agent to work that out. The mistake is leaving it there.
Once you can see which parts of a workflow resolve the same way every time, those parts are no longer a reasoning problem. They’ve become a specification. And a specification is something you can build, test, monitor, and stop paying for on every single run.
That’s more or less what happened with the email workflow. The agent showed us what the lookup needed to be. Then we built it properly.
So I’ve started thinking about this less as a decision and more as a lifecycle. Use an agent to discover the mapping. Harvest whatever turned out to be deterministic. Promote it to infrastructure. Leave the agent doing the part that’s still a judgment call.
The pressure to put AI everywhere
There’s enormous pressure on CIOs, CTOs, and executives right now to demonstrate what they’re doing with AI.
I think that’s a bigger factor in all of this than the technology is.
Deploying an agent is visible. You can name it, count it, and put it in a board update. Building a reliable integration is invisible. Its success looks like nothing going wrong, which has never once appeared on a slide.
So the incentives quietly favor the more expensive and less predictable option, regardless of which one the problem actually calls for.
What concerns me is where that lands. Agent costs don’t sit in a capital line that someone approves once and then tracks. They sit in variable spend, spread across teams, growing quietly with volume.
Which means the bill for this year’s enthusiasm tends to arrive next year, as an operating cost that nobody can fully attribute. And the CFO usually notices before the board does.
So the question I’d be asking isn’t where an agent could be deployed. It’s whether the problem requires continuous intelligence at all.
Sometimes it will. Sometimes the better answer is an integration, an automation, or better data architecture.
And increasingly, I think the interesting part is how all of those things work together.
Reliable integrations underneath. A shared layer of context that the organization can query rather than re-derive. Agents on top, using that context where reasoning adds value.
That middle layer is the part I find most interesting at the moment. An agent shouldn’t have to rediscover what your business already knows every time it runs.
I don’t think the lesson here is to use fewer agents. I think it’s to get much more deliberate about what we’re asking them to do.
If we’re asking one to repeatedly interpret the same known information and move it from A to B, we’ve probably just found an integration we haven’t built yet.
This is something we’re spending a lot of time thinking about at Syncaroo, as we build integrations, help deploy agentic systems, and guide agent “hiring,” if you will.
If you’re wrestling with where one should end and the other begin, I’d be interested in comparing notes.