How We Cut Agent Costs 10× by Turning Traces into Tools

A few years ago, two friends and I started an artisanal brewery in Bogotá called Jabato. Five years in, we've learned a lot about beer and even more about what it takes to run a consumer-goods company.

All three of us are engineers, so we did what engineers do: we documented everything, tried a few CRMs, and eventually decided to build an agent to handle our commercial pipeline.

The Job We Were Automating

Selling craft beer to bars and restaurants is a grind of small, sequential steps:

• Find candidate venues in strategic parts of the city
• Verify each one is a real prospect, a place that sells beer and not a brewery that makes it (that would be a competitor)
• Check it isn't already in our leads database, or worse, already an active client
• Research the venue enough to write something that isn't a template
• Reach out via Instagram DM, WhatsApp, or email
• Log everything and, eventually, book a meeting

That works out to about a dozen fragile browser steps per lead, repeated all day, which is exactly the kind of work you want an agent to own and exactly the kind of work where one silent failure ruins the whole chain.

Attempt 1: The Cheapest Model That Benchmarked Well

We're a young company. Most of our capital goes to production and point-of-sale material, not to an AI budget. So we started with the cheapest model that looked good on benchmarks.

It reasoned about a lead perfectly well and drafted a decent message, but it was unreliable at actually using tools, and the failure mode was worse than a refusal. It would announce the action and then never take it:

Then nothing: no tool call at all, four times in a row on the same lead. In a browser-driven task with a dozen fragile steps, “almost” is indistinguishable from “no.”

Attempt 2: Frontier Models

We moved to stronger models, first Kimi K3 and then Grok 4.5, and the difference was immediate: they completed the full loop at a natural pace, wrote genuinely personalized messages, and handled several leads a day.

Then we looked at the bill. Here are two real days from our logs, running the same agent on the same job:

The frontier model cost us eleven times as much while making roughly half as many calls, and the unit economics explain most of that. Compared to what we run today it charged about 5× more per input token and about 8× more per output token, but the number that actually hurt was cached input, which came in around 14× more expensive.

That last one matters because our system prompt is big. It carries the operating manual, the tool documentation, the business rules and the agent's memory, and all of it gets re-read on every single turn. On the expensive model those cache reads alone came to roughly $1.60 a day, while the same tokens on our current setup cost about twelve cents.

The logs also showed we were paying the agent to do nothing. It wakes up every 30 minutes to check whether anything needs attention, and on that day 48 of its 177 calls were those heartbeats, each one thinking at full depth to conclude that nothing had changed. That is 27% of the day's spend on an empty inbox.

The Idea: Use the Expensive Model as a Teacher, Not as the Operator

We had reached for the frontier model because it was the only one that could finish our browser-based sales workflow, and it was costing us roughly 10× what a cheaper model would. Paying that forever was not an option, so we started asking what we were really buying.

What we were buying was not the daily execution. It was the model figuring out how to get the job done in our particular environment. That is a one-time cost if you capture it, which turns the expensive model into an exploration and data-collection tool rather than the thing that runs in production.

What Are Traces?

A trace is the complete record of an agent's execution: what it tried to do, which tools it called, what happened, where it failed, and how it recovered. By reviewing these traces, we could see the actual procedure required to complete the task, not just the final answer.

While it ran, the frontier model made mistakes, recovered from them, and worked out what actually holds up against Instagram, WhatsApp and our own leads database. Every bit of that is sitting in the traces, whether or not anyone reads them.

We reviewed those traces and turned what we learned into three things:

That changed the cheap model's job entirely. It no longer has to work out how to perform the task, it just follows a known procedure and proves it completed each step, which happens to be the one thing it was already good at.

We never fine-tuned or retrained anything. The knowledge simply moved out of the model and into tools, documentation, and verification, and the workflow now runs on a model that costs a fraction of the original without losing reliability.

The Key Takeaway

Don't think of an expensive model as your permanent operator. Use it to discover the procedure, then turn what it learned into tools, rules, and verification. Once the process is deterministic and checkable, a much cheaper model can execute it.