I’ve noticed a potentially problematic pattern over the past few months.
More and more companies seem to be 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 AI agents to solve problems that don’t actually require continuous intelligence.
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, inference, 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 with specific email inquiries.
And it worked.
Every time an email arrived, an agent would ingest the relevant information and context, work out what needed to happen, and take the appropriate action.
The problem was that each new email caused the model to load and process much of that context again.
As the volume of inbound requests grew, token usage grew with it. Costs became difficult to predict and eventually made the automation uneconomical to operate in the way it had been designed.
What made this particularly interesting to me was that much of the workflow was deterministic.
It didn’t actually require the system to reason through the same problem from scratch every time.
There were parts that genuinely benefited from intelligence, but there were also parts where we already knew what the data meant, where it needed to go, and what should happen next.
We were effectively paying for inference where infrastructure would have done the job.
Then there’s the question of failure
Traditional integrations fail too.
The difference is that they’re generally built around fairly 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.
Examples include wiping databases, renaming everyone in your CRM to a Disney character, or running tests on live systems. All things we’ve seen in real systems over the last few months.
The second may be more dangerous.
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.
Then, three months later, someone asks why the numbers don’t reconcile.
Here, examples include incorrectly formatted numbers, unexpectedly shifted commas in CSV files, or not setting pricing for a customer… that goes unnoticed for months.
I’m not arguing against agents
We’re deploying them ourselves.
We’re also helping companies build context graphs so their agents have better information to work with.
I’m very bullish about what happens when AI can reason across a business’s operational context.
That’s also why I think we need to be careful about where we use it.
I’ve started thinking about agents as workers.
Workers are particularly useful when a task requires judgment, context or the ability to deal with ambiguity.
If two systems need to exchange the same well-defined information thousands of times, I’m not convinced we need a worker standing there interpreting it every time.
We need a reliable road between them. Then we can put the worker to use doing something more valuable.
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 suspect that’s contributing to some of this.
The question I’d be asking isn’t simply where an agent could be deployed.
It’s whether the problem actually requires intelligence.
Sometimes it will.
Sometimes the better answer will be an integration, an automation or better data architecture.
And increasingly, I think the interesting part is going to be how all of those things work together.
Reliable integrations underneath. Shared context across the organization.
Agents sitting on top and using that context where reasoning actually adds value.
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 a problem requires judgment, ambiguity, or context, an agent might be exactly the right tool.
If we’re asking it to repeatedly interpret the same known information and move it from A to B, perhaps we’ve just found an integration that we haven’t built yet.
And as the pressure to “add AI” increases, I suspect knowing the difference is going to become increasingly important.
This is something we’re spending a lot of time thinking about at Syncaroo as we build both integrations, agentic systems, and guide Agent deployment (or “hiring”, if you will). If you’re wrestling with where one should end and the other begin, I’d be interested in comparing notes.