Technology is where I started. I studied it, and my master’s thesis at the University of Salford, in 2010, was about offshore IT outsourcing in Bolivia. For my first decade at GOJA I led technology from Cochabamba, where we built the team and the tools the company ran on. In 2020 I became VP of Operations and spent six years running supply chain, merchandising, compliance and customer service.
Eighteen months ago I also took over the technology team. This year we made a decision that I think says a lot about where companies like ours are going: Technology & AI became its own function, and I moved to lead it.
Operations and technology are different disciplines, and that is fine. Operations runs the business we have. Technology & AI has to build the system that lets the business scale much faster than headcount. Building an agentic system is not a side project you run between purchase orders. It needs its own leadership, its own roadmap and its own focus.
For me it is also a return to my roots. And it feels good.
When I joined GOJA in 2010, nobody had written the book on running Amazon stores. There were no courses, no playbooks, no consultants who had done it before. We were the experts in progress.
So we did what made sense: we looked at the data. Sales by day, rankings, prices, reviews, what competitors were doing. When the tools did not exist, we built them. Experience we did not have yet, we replaced with numbers, and the numbers are how we built the expertise. In 2017 we took Riskless, a traffic, inventory and pricing system built in Cochabamba, to Collision. It was that habit turned into software.
I have used the same framework ever since, almost without naming it: when I don’t have the expertise, I replace it with data.
It is how I learned finance. About ten years ago I asked a friend in FP&A for a one-on-one on what his job actually was, and then I went to our numbers until they made sense. It is how I learned supply chain. I could not out-experience people who had run supply chains for twenty years, but I could look at every SKU’s velocity, lead time and cover every week, and see patterns before anyone explained them to me.
Friends helped me with the vocabulary. The real answers almost always came from the data.
Learning AI from the inside
Using AI as an end user and building the system other people will rely on are two very different jobs. A few principles have become clear to me in the last year. None of them are secrets. Most teams learn them the hard way.
Most AI problems are data problems first. Before any model choice, the questions are about grain, entity resolution and definitions. On Amazon, one product can carry several SKUs for different reasons, and finance and operations often look at it at different levels. If your data does not reconcile those views, no model will. Legacy decisions live in the data for years, and someone who was there when they were made reads a schema very differently from someone who just arrived.
The semantic layer and the knowledge base are the product. A model does not know what contribution margin means in your company, which joins are safe, or which numbers are actuals and which are forecasts. Expose raw tables and it will answer quickly, confidently and wrong. The semantic layer fixes that with metric definitions, business rules and valid relationships. The knowledge base goes further and holds how the business thinks: strategies, decision rules, what was tried and what happened. The semantic layer keeps the model from being wrong. The knowledge base is what makes it useful. Both deserve the same discipline as code: versioned, tested, owned. Models are becoming a commodity. Your business knowledge, written down in a way a system can use, is not.
A protocol is not a strategy. MCP made it easy to put tools and data in front of a model, and we use it. But a tool surface without semantics only makes mistakes faster. The value is in what the model understands when it gets there.
A prototype is not a system. With good data and a strong model, anyone can build a working artifact in an afternoon and schedule it to run every day. That feels like an agent. A production agentic system is a different animal: runtime, state, orchestration, evaluations, observability, governance and a cost model. The gap between the two is where most expectations break, and explaining it is a big part of my job.
Narrow agents, earned autonomy. Smaller agents with tight scopes and separate context tend to beat one agent that does everything. Autonomy should be earned in stages, inside clear policy boundaries, with a person accountable for the decision until the evidence says otherwise. And every agent has to be tied to a business outcome we already measure. If we cannot say which number it moves, we do not build it.
Use a model only where you need judgment. If the answer already exists in the database, deterministic logic is faster, cheaper and auditable. Routing well between the two is one of the most underrated design decisions.
Inference is a P&L line. Chat-style usage is cheap. A system that runs every decision through a model, every day, is a real operating cost. The business needs to see cost per decision before the invoice arrives.
Invest in what compounds. Clever workarounds for today’s model limitations age fast, because models get better every few months. A clean record of what we decided, why, and what happened next does not. Every decision captured that way feeds the knowledge base and makes the next one better.
Why operations matters here
An agentic system for an Amazon business is, in many ways, operations made explicit. A forecast agent needs to know that a promotion distorts last month’s velocity. A pricing agent needs thresholds, timing and a tolerance for sales impact. An inventory agent needs to understand that cash sitting in a slow mover is a real cost. None of that comes from the model.
Six years running operations means I know which decisions matter, where the data lies, and what the people making those decisions actually need. That is the part I bring to the technology. My engineers bring depth I will never have on the code, and that is exactly how a good team should work.
Still calling friends
My method has not changed in sixteen years. When I don’t know something, I ask someone who does for the basics, and then I go to the data. The difference is that now the data can talk back, and I am building the system that will do the same for everyone at GOJA.
I am learning faster than at any other point in my career, and from the inside this time, not as a user.
I am back to my roots, and it feels good.
Leave a Reply