AI agents: reliability and cost don't come from the model, they come from your APIs

On 16 September 2026 I spoke at FDDAY with Simon Guerrier, Product Manager at Postman, in a session about AI agents. We chose to talk about what happens after the first successful prototype, when the agent that worked in the demo turns unstable and expensive as soon as it is wired to the real systems. That is usually the moment teams stop arguing about the model and discover they have a plumbing problem.

What we argued for forty minutes fits in one sentence: an agent’s reliability and the size of its bill do not depend on the model, but on the quality of your APIs and on your ability to govern whatever calls them.

The main lever is therefore on your side, inside systems you already own.

What an agent is made of

An agent is three building blocks called in a loop.

• The model, bottom left. It is stateless: it retains nothing from one call to the next. That matters, because it is not a brain that learns from your exchanges, it is a function you call again every turn with the whole context.
• The harness, the large grey area. This is your code, or your framework’s. It holds the context, made of the system prompt, which defines how the agent should behave, the schemas of the tools it will use, and the message history. It also runs the loop: it assembles the context, it calls the model, it routes to a tool or it stops.
• The tools, at the bottom. Files, code, and above all, in orange, your business APIs. Your CRM, your billing, your ticketing.

One turn reads straight off the diagram. The message goes to the harness, which pulls its context to work out how to handle the request and in what tone to answer. That goes to the model, which picks the tools needed to handle the request and shape its answer. The harness executes the call to the requested tool, and we come back to the assembly step to format the API’s response. If the model finds the information it got relevant, we leave the loop and the answer goes back to the user. Otherwise it tries to correct course and keeps iterating until the answer is good enough.

Three things to take away from this diagram:

• The model is rented. You swap it in one line of configuration. The harness, you write. And the APIs, you already have, to make your systems talk to each other or to expose them to external consumers.
• The loop resends the entire context to the model on every turn. That is the red circuit on the diagram: assemble, call, route, back to assemble. On each pass the model receives the system prompt again, the tool schemas again, and the history, which keeps growing. That is where the tokens go, and it is the thread running through this whole article.
• The model decides, your code executes. No guarantee can come from the model. If it decides to call your refund endpoint, it calls it.

Cost grows faster than the turn count

The cost of a task is written like this:

( system prompt + tool schemas + request )   ← fixed
+ ( history )                                ← grows every turn
× iterations

The part that grows is the part that gets multiplied. Take a plausible baseline: 4,000 fixed tokens, and a history that adds 1,500 tokens per turn (the model’s decision, the tool call, the API response).

Iterations	Input tokens billed
5	35,000
10	107,500
20	365,000

The sliders below apply that formula. The third one varies the turn count, and the two scenarios at the bottom compare a clean API to a vague spec on identical settings.

Fixed tokens

4 000

system prompt, tool schemas and request, resent every turn Tokens added per turn

1 500

model decision, tool call, API response Iterations

8

number of passes through the loop Price per million tokens

3,00 $

input rate of the model you use

Billed tokens 74 000

Cost of the task 0,222 $

For 10,000 tasks 2 220 $

Same settings, only the turn count changes. Click to apply.

Clean API 4 turns 25 000 0,075 $ Vague spec 18 turns 301 500 0,905 $

The vague spec costs 12 times more than the clean API, on the exact same task.

See the turn-by-turn detail

Turn	This turn's input	Cumulative

Twice the turns, three times the tokens. The reason is simple: by doubling the iterations, you pay twice as often for a context that has itself doubled in size. That accounts for most end-of-month surprises.

Three levers to bring the cost down

You have three grips on that bill. They differ in amplitude and in ownership.

Lever	Amplitude	Who controls it
Price per token	x2 to x5	Your provider
Tokens per turn	x2 to x3	Your harness
Number of iterations	x10 to x100	Your APIs

Price per token is negotiated by switching models, and the amplitude above holds at equivalent capability. Between two models able to carry the same task, the price gap runs from two to five times. Drop to a very basic model, the one that summarises an email, and the gap widens a lot, but you are no longer talking about the same agent. A model that reasons better also cuts the number of iterations while making every token dearer: you trade one lever for the other, and the net gain is often close to zero.

Tokens per turn depend on your harness, and mostly on two decisions. Which tools you expose to the model, because every tool schema is resent on every turn, used or not. And your context management strategies, chief among them compaction, which summarises the history once it passes a certain size instead of sending it back in full. Be clear about what this lever does: it lowers the cost of an iteration, not the number of iterations.

The number of iterations depends on your APIs. It is the most powerful lever of the three, by two orders of magnitude, and also the one nobody brings up in the meeting. It belongs to you entirely.

A good API cuts iterations without making anything dearer. An endpoint that returns in one call what the agent was about to fetch in six, an error message that says what to fix instead of saying “Bad Request”, pagination with an explicit cursor: every time, you remove loop turns without paying a single line more. It is the only free lever in the whole equation.

What an agent actually fails on

Take the same blocker, seen first by a human and then by an agent.

A developer stuck on your API asks on Slack, reads the source, tries it, and remembers. The cost is paid once, by one person, and the knowledge stays in the team.

An agent that gets stuck rereads the same documentation, tries blind, and remembers nothing. The cost is paid on every run, by every user, indefinitely.

That is where the change is. The blind spots in your APIs have not moved: they are the same as before. Yesterday they created a bottleneck between IT and the business, a ticket, a meeting. That bottleneck is still there, and today they cost you money on top, in tokens, on every call.

Ambiguity used to cost time, once. Now it costs money, on every run.

In practice the business reasoning is rarely at fault. What blocks is the contract: how you authenticate, how many calls per minute you are allowed and what happens beyond that, how you get the next page of a list, what an error means when it lands, and whether a call can be replayed without consequence. A model cannot guess any of those answers. When they are written nowhere, it invents its own, in a perfectly confident tone, and gets it wrong.

Every failure is born in the API lifecycle

The questions an agent asks map one to one onto the stages of your API lifecycle. This is the table I keep for architecture conversations, because it moves the debate from “which model should we pick” to “which stage is broken here”.

The agent asks	What breaks	Created at stage
Which API?	Scattered estate, no portal	Publication
Which endpoint?	Vague naming and modelling	Design
How do I call it?	Contract missing, wrong or implicit	Documentation
What if it fails?	Silent errors, unknown replayability	Test
With which credential?	Nothing says, nobody decided	Governance

None of these failures comes from the model. Switching provider fixes none of them.

None of them is visible where it is born. Vague modelling decided at design time shows up six months later as an agent groping around in production. Nobody will make that connection on their own, because the symptom and the cause are separated by several teams and several quarters.

One gap is enough. Perfect documentation does not save an agent that does not know which credential to use, and an agent always finds the weak link before you do.

What a unified API platform changes

One more tool in the chain fixes nothing. The gain comes from the chain disappearing: design, documentation, test, publication and governance stop being five separate workshops and become five stages of one lifecycle. Two mechanisms follow from that, and they matter more than any productivity figure.

Quality gates. An automated check sits at every stage, and it blocks the move to the next one until it is green. A spec that departs from your design rules, a contract that breaks compatibility, a failing contract test: none of it moves forward in the lifecycle. Compliance stops depending on a human review that gets skipped when the deadline looms, and deviations show up where they are created rather than six months later, in production, in an agent trace.

Propagation. A change made at one stage ripples through all the others. Changing the spec regenerates the collection, the mocks and the tests, and updates the published documentation. The source of truth stays single and always current, which removes the silent drift between what the API does and what the contract says it does. For an agent, that drift is exactly what makes it grope around: it reads a contract describing an API that no longer exists.

So let us take the agent’s five questions again, and the stage that answers each.

Which API? Publication Which endpoint? Design How do I call it? Documentation What if it fails? Test With which credential? Governance

Stage · Publication

A single catalogue, whatever team or stack sits behind it, with an owner and a status per API. The agent looks in one place instead of digging through three portals and a wiki.

The idempotency rule mentioned in the last tab deserves a word. A person retries a failed payment once, carefully. An agent retries it a thousand times in a second. Idempotency stops being a good practice and becomes the line between one retry and a thousand duplicated transactions.

Across those five stages, the benefits fall into three families, and they do not only serve your agents.

A bill nobody can break down

Your APIs determine the agent’s reliability. They do not tell you what you are paying to get there.

The typical situation at this point: you receive the bill from the model provider, and you know neither who is spending, nor for what, nor through what. The spend is indivisible. It arrives as one block.

That block covers at least three very different populations:

• Coding agents, Claude Code, Codex, Cursor, used by your developers.
• Production agents, the ones talking to your customers or to your systems.
• Local and personal agents, built by a team for its own use, sometimes known to nobody else.

Without that breakdown you cannot spot the inefficient agents, the ones looping twelve times where another manages in three, nor reduce the cost, for lack of knowing where to push, nor answer the question the CFO will eventually ask about AI’s real impact on the business.

How you get that visibility

You need three building blocks, and none of them replaces the others.

Traces and logs give you the execution thread: how many turns, which tools were called, where the agent groped around. That is what connects a bill to a cause. A backend tool attaches a token cost to each trace, which turns “we spent 700 dollars” into “this agent spends 1.50 dollars per request and its neighbour 0.005”. And an AI Gateway, a single point of access to the models, gives you attribution by provider and by model, including for the usage nobody declared.

Coding agents are handled differently: you pull the data at the provider level and classify prompts by category and by user. Without that classification, there is no telling how much of your Claude Code spend goes to software engineering rather than writing, or how much is professional rather than personal.

Once those blocks are in place you get a 360-degree view: spend per agent, per user, per model, and the trace that explains every line.

What observability does not tell you

Observability tells you what happened. It does not tell you whether it was any good. That is what evaluations are for, and the two come as a pair: evals without observability have no data to judge, observability without evals only produces charts.

In practice you put a checkpoint at each step of the loop and evaluate each one separately.

The real work is upstream: choosing the criteria, business, infrastructure, security, and curating a dataset to evaluate from your traces, logs and transcripts. That dataset is the asset that makes iteration possible. Without it, changing model or prompt is a blind decision, and you have no way of knowing whether the next version is better or merely different.

That is what makes customisation usable. Every block of the agent is independently replaceable, the harness, the model, the tools, so you can switch model as the need changes, update the harness in production, improve the connected tools. Measure the effect of each change, or you are iterating at random.

Governing a non-deterministic program

Knowing what you pay does not tell you what you risk.

An agent in production has two boundaries, and on most projects nothing filters either one.

What goes in: usage outside the intended scope, an instruction hidden in a document the agent reads, a permission the user does not have.

What goes out: customer personal data sent to a third-party provider, an irreversible action on your systems, a false commitment made to a customer, an answer signed with your brand.

Some bills are counted in tokens, the others are counted in customers. And your tests cover what the agent is supposed to do, while the incidents all come from what it is able to do.

The public incidents of the last three years all share the same structure: the rule meant to hold the agent lived in its prompt, so it was negotiable, and somebody eventually negotiated it. A rule that stays in the context is only a preference.

Guardrails

The answer is to insert blocking points at different moments of the loop, independent of the agent itself.

The rules are defined by your teams and cover distinct themes: content safety, data privacy, prompt injection detection, permissions on actions, compliance. The important point is structural: these checks are independent of the agent. They are not in its prompt, so it cannot talk itself out of them.

The third outcome matters as much as the other two. An agent that knows how to stop and ask beats an agent that is right 95% of the time on irreversible actions.

Access and identity

This is the control people forget most often, and the one that produces internal leaks.

A single agent, shared by several business units, calling several systems. If the agent calls the APIs with its own technical identity, it carries the union of all its users’ permissions. A salesperson then gets HR record information through the agent, without any access control being fraudulently bypassed: the agent’s permissions were simply broader than theirs.

The agent must carry the user’s identity all the way to the API, not its own. Three questions to ask, in this order: who has access to which agent, who has access to what through which agent, and can you reconstruct afterwards the actions taken on behalf of each user.

Two layers to answer all of it

Attributing the spend, evaluating quality, filtering what goes in and out, tracing who did what: none of that gets solved inside the agent’s code, it gets solved around it. At Postman, it splits across two layers.

Fabric controls what goes in and out of the agent.
Astro controls the agent itself, across its whole lifetime.

If you are working on agents wired to your systems, or if you think I am wrong somewhere, write to me on LinkedIn. I would be glad to talk.