I was in San Jose for WeAreDevelopers World Congress, September 23 to 25, and the most telling thing about the week was a question almost nobody asked. Almost no talk I saw spent any time arguing that an agent can write code. That argument is over. Everyone in the room had already watched it happen.
The question has moved. It is no longer "can it code" but "how do we trust, govern, and pay for what agents do". Almost every talk I saw was about one of four things: verification, evaluation, context control, or cost. Those are not the topics of an industry that is still impressed. They are the topics of an industry that has put agents in front of real work and is now finding out what that takes.
This is the first of several posts on the talks, coming over the next few weeks. This one is the overview: four ideas that kept coming back, from different speakers, on different stages.
The Model Is Not the Bottleneck
The idea I would put first came from two separate speakers in two separate talks: a complete, current view of the entity the agent is working on beats swapping to a better model.
The instinct when an agent gets something wrong is to reach for a bigger model. The answer was wrong, so the brain must be too small. Two speakers, independently, said the lever is somewhere else.
My take: that matches the failure I have written about most. A model read 3/11 off a handwritten card and filed it as 2024-03-11 with high confidence. The real year was 2026. The model was not too small. The year was not on the card. A smarter model reasoning from the same card would have produced the same guess, maybe in better prose. I told that story in It Fails Plausibly, Not Loudly, and the fix had nothing to do with which model did the reading.
Say a support agent is answering a question about an order and can see the order but not the change the customer made to it yesterday. No model upgrade fixes that. Putting yesterday's change in front of it does. If the view of the entity is the lever, then the engineering effort belongs in what the agent can see, how fresh it is, and how complete it is, not in the model picker. That is less exciting than a new release. It is also the part you control.
The Answer Is Not the Grade
The second theme: grading an agent only on its final answer is unsafe. Teams that take this seriously score the plan and the tool calls too, using traces, the step-by-step record of what the agent actually did.
The clearest example of the week was a refund agent in a customer-service demo. Its refund looked correct and passed a check that looked only at the outcome. But the policy check the agent was supposed to call was never called. The outcome was right. The process that produced it was not, and nothing in an outcome-only check would ever have said so. One of the speakers put it in a single line: "A polished answer can hide an unsafe execution."
That talk gets a whole post of its own. The short version: if you only look at the answer, you are grading the part of the agent least likely to show you the problem. It is the plausible failure again, one level up. On the card, a single output looked right and was wrong. In the refund demo, a whole sequence of actions produced an output that looked right, and the danger was in a step that never happened.
Context Is Something You Engineer
The third theme was context control. Two talks took it on directly: one laid out five pillars for what goes into an agent's context and how, and one went deep on why long-running agents degrade and what their memory should look like.
The shift is from treating context as a place you put everything to treating it as a budget you spend. Tools get loaded only when they are needed. Old tool results get dropped. Work gets split across agents so no single one carries all of it. One speaker cited a figure from Uber: loading tools on demand, through a gateway the agent searches for the tool it wants, cut the context spent at startup from roughly 50,000 to 70,000 tokens to near zero. That is not an optimization at the margin. That is a large share of the window, handed back before the agent has read a word of the task.
The phrase I keep returning to from the memory talk is "paraphrase errors become the new source of truth". When an agent summarizes something and then works from its own summary, every small distortion in the summary becomes a fact. That one gets its own post too.
Gateways Are the New Control Plane
The fourth theme was cost, and the answer was architectural. Gateways are becoming the control plane: one endpoint that every model call goes through, with budgets, audit trails, and evaluations built in.
That is a quiet but real change in where control lives. When every team calls every model directly, nobody can easily say what was spent, on which model, for what result. Put a single endpoint in the middle and those three questions have one place to be answered. A budget is enforced in one place. An audit trail exists by default instead of by effort. Evaluations can run against the calls that actually happened, not only against a test set someone assembled once.
My take: the gateway will get approved as a cost tool and kept as an evaluation tool. The budget is the reason someone signs off on it. The record of every call is the reason it is still there a year later, because that record is what lets you answer the question the rest of the conference was about.
What This Means If You Are Building
Put the four themes together and they say one thing. The hard part of working with agents is no longer getting them to produce. It is knowing whether what they produced is right, and being able to show it afterward.
That is the question I already start every build with: how will we know it is right? Before I write a specification for anything an assistant will build, I write down what it must produce, how I will check it, and what it must never do. I run a large language model (LLM) as a judge, with a written rubric, for the same reason. None of that came from the conference. But it was useful to hear speaker after speaker arrive at the same place from a different direction, with traces and gateways and token counts to back it up.
If you take one thing from the week, take this. Before you upgrade the model, upgrade what it can see. Before you trust the answer, look at the steps. And before you scale anything, decide where the record of what it did will live.