Keynote: Why people think "agent" is a buzzword but it isn't

A chess agent perceives a board and acts by making moves. That simple example captures the definition Chip Huyen takes from Stuart Russell and Peter Norvig: an agent perceives its environment and acts on it. The term predates today’s language models; the useful engineering question is what the system can observe and what it is allowed to change.

For ChatGPT, browsing makes the internet part of the environment, alongside capabilities such as calculator use and text and image generation. For SWE-agent, the environment is a computer with a terminal and filesystem. Its actions include navigating a repository, searching, viewing files, and editing them.

The environment constrains the actions, and new actions expand the environment. A game agent cannot perform moves the game does not permit. Conversely, giving a model a browser adds access to an environment it could not previously inspect. Tool selection therefore defines the agent’s reach, not merely its convenience.

Tools first address limitations of the underlying model. A training cutoff need not prevent an application from answering questions about recent events: news APIs, weather APIs, and browsing can supply fresh information. A calculator similarly provides a direct route to numerical computation without requiring the language model to learn every calculation reliably.

Tools can also extend the modalities an application handles. A text-only language model cannot directly consume an image, but an image-captioning model can turn that image into text. The language model then uses the caption to produce a response. The combined system accepts images even though its language component still operates on text.

The larger opportunity is to put the model inside an existing workflow. Access to an inbox, Slack, a calendar, or a code editor lets an agent work where the relevant information and actions already live. Users no longer have to move every task into a separate AI interface. This is why actions matter beyond compensating for model weaknesses: they connect inference to the work someone wants completed.

If those capabilities are so useful, why are agents not already doing everything? The first obstacle is complexity. A company might tolerate a task failure rate of one or two percent, but that does not mean a model with a two-percent error rate at each step can reliably complete a long workflow.

Huyen’s example puts ten-step failure at roughly 18%. The calculation can be made explicit by assuming independent errors, a constant per-step failure probability, and a task that fails whenever any step fails, without recovery:

Under those assumptions, a 2% per-step error rate produces approximately 18.3% task failure over ten steps and 86.7% over one hundred steps. These are conditional calculations, not measured agent results. They explain why a locally acceptable error rate can become unacceptable across a workflow.

This creates a difficult product tradeoff. Simple tasks often do not need an agent, and may offer less economic value. The more attractive tasks frequently require several dependent operations—the very structure that makes them harder to finish reliably.

Consider Huyen’s apparently simple business question: how many people bought products from Company X last week? The proposed workflow has four conceptual stages:

1. Fetch Company X’s product list.
2. Retrieve last week’s order count for each product.
3. Sum the counts.
4. Generate a response.

The second stage can contain many individual calls. There is also a semantic problem to resolve before treating the answer as correct: summing per-product order counts does not establish the number of distinct buyers, and an order containing multiple products may appear in more than one count. The workflow illustrates decomposition, but answering the original question requires the right counting and deduplication rules.

Among the agent use cases Huyen had seen, consistent success on tasks requiring more than five steps was very rare. That observation motivates the next question: how do you establish the complexity your own agent can handle before giving it consequential work?

Required step count is one useful measure of complexity. Huyen describes a synthetic planning benchmark she was developing, where generated tasks let her control that count and examine how performance changes. In Huyen’s then-unpublished synthetic planning benchmark, most tested models could solve tasks requiring at most five steps, and most failed after ten steps. The result is her historical report; the talk does not supply the full dataset, prompts, or sampling settings needed to reproduce it.

A related pattern appears in the 2021 paper Evaluating Large Language Models Trained on Code. That study evaluates generated-code correctness as string-processing instructions combine more operations; it is analogous evidence, rather than a test of autonomous tool execution. Huyen’s two-operation example is to lowercase a string and then remove half its characters. The following Python function makes the composition concrete, choosing to retain the first half:

def lowercase_first_half(text: str) -> str:
    lowered = text.lower()
    return lowered[:len(lowered) // 2]

result = lowercase_first_half("ABCDefgh")
assert result == "abcd"

Each instruction is simple in isolation. Success requires satisfying both, in order. The study’s pass rates fall rapidly as more operations are composed; Huyen distinguishes that pattern from the absolute scores of the older models, which she expects to have improved.

Her planning results also show progress. DeepSeek-R1, Gemini 2.0 Flash Thinking, and o1-preview move the success curves upward, solving more complex tasks than the other models in her comparison. She did not test o1 or o3, because she lacked access when she ran the experiment. Her aggregate task-count comparison separates those reasoning models from Sonnet 3.5, Gemini 2.0 Pro, and GPT-4o, without giving exact counts in the spoken explanation.

Step count is not the only way to define difficulty. ZebraLogic studies logic-grid puzzles and uses Z3 solver conflicts as a complexity measure alongside search-space size. Those conflicts describe the solver’s work, not the language model’s reasoning steps; puzzle success requires the whole grid to be correct. Huyen highlights the same qualitative relationship: model success falls rapidly as conflict counts rise. The broader lesson is to measure difficulty in terms that fit the task, then evaluate performance across that range.

Once the operating limit is known, there are several ways to work within it or extend it:

• Decompose the task. If the workload usually takes five or six steps but the agent reliably handles only three, split it into two smaller subtasks. Assign work at a granularity the agent can complete.
• Increase test-time compute. Give the model more inference computation, either through more thinking tokens or through multiple candidate outputs. For a math problem, Huyen suggests generating ten solutions and selecting the most common answer.
• Use a stronger model. Huyen frames investment in training larger, stronger models as train-time compute scaling, in contrast to spending more computation on each inference.

These approaches address different parts of the problem: decomposition reduces the scope of an individual assignment, while additional compute seeks to improve the model’s ability to solve it.

Tool use is a translation problem: a person gives an instruction in natural language, but the environment expects particular function calls. Given a customer email and a request to create an order, an agent might first extract a customer ID from the email address, then extract an order ID from the email contents, and finally call the function that creates the order. Both sides of this translation can fail: the request may be ambiguous, and the API may be badly designed or documented.

Huyen illustrates the mismatch with two tools. Written as identifiers, fetch_top_products(start_date, end_date, number_of_products) retrieves a ranked product list, while fetch_product_info supplies information such as price. Now consider a request to find best-selling products under $10.

The model may recognize the right tool without having enough information to call it correctly. Yesterday’s best sellers, last week’s, and last month’s answer different questions. Valid argument types do not resolve missing intent.

An agent cannot use an interface reliably if its contract is unclear. At minimum, the documentation needs to describe the function’s purpose, parameter types and meanings, error codes, and expected return values. This is more than supplying a function name and a JSON shape: the agent needs enough information to decide when a call is appropriate and what its result establishes.

Errors need operational meaning too. An opaque error code does little to guide the next step. Explain the likely cause and what the agent should do when it encounters that condition. Otherwise, the tool reports failure without helping the planner recover.

Successful returns can be equally ambiguous. What does a returned value of 1 mean? Without that interpretation, the agent may be unable to decide whether to continue, retry, or take a different action. Huyen reports that an unnamed company saw one of its biggest agent improvements after documenting how to interpret function results. Return-value semantics are part of the planning interface. They determine what the agent can infer from a completed call.

Good tool design also requires recognizing that humans and agents may use the same environment differently. A person working in Salesforce may prefer its website, while an agent may be better served by direct API calls that avoid interpreting visual cues. Similarly, a person commonly performs work sequentially, whereas an agent system can issue independent operations in parallel.

Browsing and summarizing hundreds or thousands of websites illustrates the difference. Huyen recalls the tedium of visiting thousands of sites while researching her book. An agent workflow can distribute independent retrieval and summarization work across concurrent calls. The point is the available execution strategy, not a measured throughput claim.

That difference matters when creating training examples. A human annotator’s sequence of actions may not be the best sequence for an AI system. Supervised fine-tuning teaches the model to imitate the demonstrated behavior; reinforcement learning can let it discover other strategies through trial and error. An effective agent policy need not reproduce the way a person navigates the task.

Alongside good documentation, Huyen recommends narrow, well-defined tools. An acquaintance at an unnamed large search company reported using only three or four small tools; for that team’s tasks, the agents did not work with more than five tools. This is a task-specific experience that motivates testing the tool inventory, rather than treating every additional capability as an automatic improvement.

On the language side, query rewriting and intent classification can help establish what the user wants. When the missing information remains consequential, the agent should ask. A request for five best-selling products under $10 now supplies the product count, but still lacks a date range. Asking whether the user means yesterday or last week is preferable to silently choosing yesterday or last year.

Another direction is to train specialized action models for particular environments. Coding models and tools such as VS Code provide an existing example of specialization; similarly complex enterprise environments may benefit from models trained around their own APIs and tasks. Huyen presents this as a general opportunity, rather than a confirmed initiative at a particular company.

The third challenge is context. Even before adding agent behavior, an application may have lengthy system instructions governing permitted requests, security, and tone, plus user instructions and examples. Agents add more information on top of that baseline.

Tool documentation grows with the number of tools. Tool outputs accumulate with execution steps. Reasoning about those outputs—what to do next, whether a plan is sensible, whether to execute it—adds further tokens as the task becomes more complex. The information needed to continue the task can grow much faster than the original user request suggests.

Domain information can be large before execution even begins. In a text-to-SQL application with a thousand tables, the model must first identify which tables are relevant. Supplying all thousand schemas to support that choice can itself create a substantial context burden. The challenge is not simply remembering the conversation; it is retaining enough of the environment’s structure to act correctly.

Planning strength does not automatically solve this problem. Huyen describes planning as output-heavy, because it produces reasoning tokens, while long-context processing is input-heavy. In her personal benchmarks, models that performed well on planning were not necessarily the models that performed well on long context, and vice versa. Model selection therefore needs to test both demands together for the intended workload.

Nominal context capacity is not the same as effective context use. Huyen illustrates the distinction with a hypothetical model that accepts a million tokens but becomes unreliable beyond a few thousand; those numbers are not a measured threshold for an identified model. Her practical method is to evaluate when adding more documentation begins to produce hallucinations or invented details. Information that exceeds the model’s effective working context needs another place to persist.

Treat the active context as short-term memory: it should hold information relevant to the task at hand. External databases and storage provide long-term memory, as they do in retrieval-augmented generation. The model does not need every stored fact in its active context at every moment.

For an agent working through a ten-step task, the outputs of all ten steps may not fit together. Earlier outputs can be saved to external files once they are no longer immediately relevant, then retrieved when a later step needs them. This preserves the information without requiring it to remain continuously present in the prompt. Storage and retrieval become part of how the agent carries work forward.

A third layer is internal knowledge: information already learned by the model. Huyen suggests including knowledge that is essential across many tasks in training data or fine-tuning, rather than repeatedly spending context tokens to supply it.

This makes memory design a question of placement and timing: what must be present now, what can be retrieved later, and what should the model already know?

The engineering work connects across these boundaries. Task decomposition limits what an agent must complete at once; precise tool contracts make each action interpretable; a memory system keeps the information needed to continue available. Huyen closes by inviting discussion of her ongoing planning benchmark—the measurement problem that determines how much work an agent can responsibly take on in the first place.