When organizations move from experimenting with a limited number of AI agents to running dozens or hundreds of agents around the clock, model quality alone is no longer the decisive factor. In the second part of the Leaders of Code conversation published by Stack Overflow, Andy Gutmann of Google discussed the economics of this transition with Peter O'Connor, Stack Overflow's Director of Platform Engineering: the amount of context required, token costs, measuring return on investment, and what platform engineering teams should build so they can manage agents in practice.
The central thesis of the conversation is that the problem has become one of an integrated system, not an individual model. Final performance depends on the model, how it is operated, the context provided to it, the degree of its customization, and the tools it invokes. According to Gutmann, the goal is not to use the most advanced model for every task, but to choose the least complex model that achieves the required result at the lowest cost. Lightweight models such as Gemini 3.5 Flash may be sufficient for some uses, while other cases require a Gemini Pro model.
The Right Context Matters More Than the Number of Tokens
Gutmann criticizes what he calls “token maximization”; increasing input size or lengthening reasoning loops does not necessarily mean a better result. The practical direction, according to his account, is to reduce context to the information that actually drives the result and improve the accuracy of execution paths so that the agent needs fewer reasoning cycles. This directly connects cost to the quality of search and data retrieval, not just to the model's price.
But identifying the “minimum usable context” is not a simple task. Gutmann says that data and model evaluation must be performed together to determine which part of the context actually improves the result. He therefore expressed skepticism toward organizations that claim to have completely solved the context problem, emphasizing that Google itself has not solved it entirely and relies on evaluations, agent trace tracking, improved search, and data enrichment to determine what deserves to be included in each task.
This point matters to AI teams because it warns against turning curated knowledge or data schemas into an independent goal. The fact that humans consider certain information useful does not prove that it will produce a better result for the agent. Measurement must begin with actual outputs and paths, while keeping a human in the loop when decision-making authority or human judgment is necessary.
Scale Changes the Cost-and-Return Equation
In a traditional work environment, usage volume can be estimated roughly from the number of employees and their working hours. Agents, however, work at a higher speed and around the clock, and one employee may have dozens of agents, or an organization may have millions of agents, depending on the scenario Gutmann presented. Usage and cost can therefore expand nonlinearly, requiring clear governance over consumption and knowledge of the return generated by each use.
Gutmann does not believe that return on investment should be measured by the number of tokens processed. The standard is whether the organization achieves a different or better result compared with what it achieved previously. He cited uses such as customer support, improving site operations and reliability, and independently managing networks at Deutsche Telekom, including proactive maintenance. These remain examples mentioned in the conversation, not quantitative results or a published comparative study included in the article.
One practical aspect raised by the conversation is reducing the cost of experimentation. Gutmann said that over one weekend he built a prototype for an idea that might previously have taken an engineer three to four months of work. He explained that the model was not production-ready code, but it helped uncover design risks early and reduce the likelihood of investing in the wrong path for several months. The value here is not replacing production development, but accelerating the testing of hypotheses before committing greater resources.
The Agent as a New Platform Persona
Gutmann suggests that platform teams treat the agent as a persona that must be served, alongside developers, data scientists, data engineers, and business users. This means that existing tools do not necessarily carry over unchanged into the agent era, but some of their areas remain essential: security and governance, cost, availability and scalability, as well as agent-specific operational monitoring.
In practice, an organization needs to know what the agent is doing in the production environment, which tools and data it invokes, how much that costs, and whether it is progressing toward the desired result. It also needs skills and controls that prevent unregulated use. The conversation indicates that infrastructure should transfer a greater share of error-prevention responsibility to the platform, rather than leaving every operational decision to the user or the agent.
Gutmann believes that bringing data scientists and data engineers into platform teams may be beneficial, even if their numbers are not large. Data engineering remains essential to ensuring that accurate, governed, and actionable data reaches the right place, while applications such as fraud detection and forecasting continue to benefit from traditional machine learning. This confirms that “AI first” does not eliminate the need for data quality or specialized judgment.
What Should New Professionals Learn?
At the end of the conversation, Gutmann emphasized the continued importance of computer science fundamentals, including mathematics, systems architecture, and understanding how technologies are built, while also pointing to the renewed importance of hardware after years of focus on software. He added that proficiency in programming with agents and achieving results through them will become a sought-after skill, alongside an understanding of business problems.
Editorial reading from certi.news: The actual change described by the article is not the launch of a new platform or model, but the shift in the bottleneck from “Can the model do it?” to “How do we design, control, and measure the system?” Nevertheless, the interview does not provide independent figures on cost savings or comparable performance metrics, and its examples come from the speakers' experience and perspectives. It should therefore be treated as a practical analysis and design direction, not as quantitative evidence that every organization will reduce its costs simply by increasing its use of agents.