Building agents means defining goals and instructions, then iterating on observed behavior instead of specifying every execution step.
2
Agents need text and context, recovery from errors, and tools whose meaning is clear without years of developer background.
3
Because agent behavior is nondeterministic, teams need evals that measure how often an outcome works rather than fixed-input unit tests.
Summary
Philipp Schmid compares traditional software development with agent development. Traditional systems relied on structured state, deterministic workflows, explicit tests, and APIs whose meaning was obvious to their authors. Agents change each of those assumptions. Developers describe goals and instructions, then refine prompts and tools based on observed runs. Models interpret text and context, choose their own steps, and need errors returned as inputs so long-running work can recover without starting again. Testing also changes because the same input may produce different paths and outcomes. Evals should measure success rates and use qualified feedback from an LLM judge or human expert. Schmid argues that APIs must expose enough semantic information for an agent that only sees a schema and docstring. His final advice is to build for recovery, preserve meaning, evaluate repeatedly, and expect to rebuild agents as models improve.
Agent development is an iterative loop around goals and observed behavior
Traditional software started with a specification, code, tests, deployment, and user use. For agents, Schmid describes a loop: define instructions, run the agent, observe what it does, adjust prompts or tools, and run it again. Developers set the goal without prescribing every step. He compares this with moving from a traffic controller, who controls the roads and signals, to a dispatcher, who tells a traveler to reach London and leaves the choice of train, plane, or car to the agent. A coding agent may take an odd route and still reach the intended outcome.
Text and context replace much of the structured state used in older software
Schmid says traditional programs represented state with data structures, booleans, and flags. An agent can interpret the meaning of a research plan and accept approval together with extra instructions, such as focusing on the US market while excluding California. A rigid workflow might have rejected the plan and required a new one. Personalization also depends on context that is hard to capture with flags. Someone might generally use Celsius because they are from Europe but prefer Fahrenheit for cooking. Agents work with text, and potentially images, video, and audio, rather than only clearly structured data.
Developers have to hand over control instead of encoding every possible workflow
A traditional customer-support system might classify a request to cancel a subscription and then follow a fixed retention or cancellation flow. An agent can interpret the request, offer another option, and respond when the user changes their mind. Schmid says it is very hard to model all those differences and stateful paths in advance. The design therefore needs to trust the language model with more control. This means accepting that the system no longer runs in a purely deterministic environment and allowing the agent to react to the meaning of the interaction.
Errors should enter the agent's context so long-running work can recover
Schmid argues that an agent failure should be treated like a normal input, similar to how a Go function can return either a value or an error. Retrying a failed HTTP request used to be cheap because the surrounding work could be repeated. That changes when an agent has already run for 5 or 15 minutes. Starting over wastes compute and can discard useful context. The failure should go back to the model, possibly alongside checks or another workaround, so the agent can continue from the current point instead of restarting the entire process.
Evals measure whether nondeterministic agents work often enough for users
Unit and integration tests assume that input A produces output C through repeatable behavior. Agents may take different steps and produce different results from the same input, so Schmid says teams need evals that measure how often a task succeeds. A customer agent that works only one time out of ten is too flaky for production. Outputs also require qualified judgment because a research report and a customer-feedback response can have different standards. Schmid names an LLM judge or a human expert as ways to assess them. Traces still matter, but the outcome is what determines success.
Agent-ready tools must explain meaning that experienced developers take for granted
A backend developer may find a product API's deleteItem endpoint self-explanatory after years of working with it. An agent sees only the function schema, docstring, and tool definition. It does not see the code or the history behind the API. Schmid says tools therefore need semantic interfaces and documentation written for agents. A delete operation should make its meaning and failure behavior clear without assuming that the caller knows the product service. Tool design has to account for the agent's limited context, not only the author's familiarity with the system.
Agents should be designed for recovery and replacement
In his summary, Schmid says teams should stop forcing a model through one fixed sequence and should preserve meaning in their application context. They should expect imperfect models and strange behavior in longer-running agents, then design recovery paths around that fact. Testing should ask how many runs need to succeed before an outcome is acceptable. His final advice is to build to delete because software is disposable: teams will rebuild the same agent many times as better models and agent designs appear.
"We define instructions on what we want our agent to do. We run it, we observe what it does, we maybe adjust our prompts, maybe we adjust our tools."00:52
Who should watch
You are building a coding, research, or customer-support agent and keep trying to force it through a fixed workflow.
Your APIs make sense to the team that wrote them, but an agent receives only schemas and docstrings.
You need to replace conventional unit tests with evals for variable outputs and recover from failures in long-running runs.
