Skip to Content

The Loop Asia

Insights

Analysis and commentary from The Loop Asia — AI, APIs, and technology leadership across Asia-Pacific.

Thanks for subscribing!

No spam. Unsubscribe any time.

The real cost of an AI agent isn't the model — it's the plumbing

Most 'AI agent' products aren't new models — they're orchestration wrapped around ones that already exist. What that means for the commercial case, and where the real engineering work actually is.
June 2, 2024 by
The real cost of an AI agent isn't the model — it's the plumbing
Jon Scheele

This deep dive expands on the Loop Asia conversation with Aki Ranin, a two-time founder and AI advisor who co-created the “Usable AI” transformation framework.


Aki Ranin said something in the episode that's easy to nod along with and easy to underestimate: most of the agent products getting attention right now — he named Devin, the software engineering agent — aren't running new models at all. They're orchestrating instances of whatever's already state of the art, moving data in and out of a lot of prompts. "Ultimately, in some ways, you could say it's just like really fancy prompt engineering code." For a CTO explaining the agent roadmap to the board, that line deserves unpacking.

What "orchestration" actually means

Strip the marketing away and an agent framework does three things: decide what to do next, call something to do it, decide what to do with the result. The deciding runs through the LLM; the calling is tool use — a model invoking an external function, an API, or another model, and getting a structured result back.

The number that caught Ranin's attention — Anthropic's Claude API reportedly handling around 200 tools in parallel — matters less as a benchmark than as a signal of where this is heading. Bambu's own platform, in his framing, was "a collection of intelligent APIs using different forms of machine learning to do specific tasks." Tool-calling removes the human clicking through screens to sequence those APIs: the model reads the task, decides which tool applies, calls it, reads the result, decides what's next. That's the "glue" he described — the same problem every integration architect has solved for two decades, just with a probabilistic router instead of a deterministic one at the centre. If you've built API gateways and event-driven integration patterns, you already have the mental model: the LLM isn't a new kind of system, it's a new kind of caller, and it needs the same governance discipline as any system with write access to production data.

The commercial bar Ranin set — and why it's higher than it looks

His cost framing is the sharpest part of the conversation: if a task takes a human a few hours and an agent needs ten hours and a thousand dollars to do the same thing, there's no commercial case — the human is simply faster. Agentic automation only clears the bar once it's substantially faster and cheaper than the person it replaces.

That's routinely ignored in how agent pilots get scoped. Most proof-of-concept projects are judged on whether the agent completes the task at all — accuracy against a test set, a demo that works. Almost none are judged against total cost including retries, human review time, and failure-mode cleanup, weighed against what a person already does. An agent that succeeds eight times out of ten and needs a human to catch the other two isn't automating the task — it's adding a review layer on top of doing the task twice. A better model lowers the error rate. It doesn't remove the orchestration cost, the tool-call latency, or the audit trail you need before letting an agent touch production — those are architecture decisions, not model decisions.

Where the harder version of this problem is heading

Ranin also gestured at what comes next: a model that, faced with a large task, decides on its own to "spin up a few local copies of various helper models that can do certain side tasks." That's delegation, not orchestration — sub-agents sharing state, duplicate or conflicting actions, a failure to trace back through several layers of delegated calls instead of one. He called it "very difficult," part of why robust agent systems at scale remain rare despite the investment: he cited the French AI lab H raising several hundred million dollars, twice the previous Mistral benchmark, specifically to chase this problem.

The practical takeaway: the highest-leverage work isn't waiting for the next model release. It's building the tool registry, the access controls on what an agent can call, the cost and latency instrumentation, the audit trail — the governance layer that makes a model deployable against production systems rather than confined to a demo. That's the same discipline that's always separated systems that scale from systems that impress in a sales meeting — and it's the exact terrain Blue Connector works in: those architecture decisions made before an agent gets near production data, not after a demo fails in front of a customer.


Scoping your own agent architecture?

I work with technology leaders on exactly this kind of governance and integration-architecture decision — before the demo, not after it fails in front of a customer.

See how I can help →