AI Engineer World's Fair 2026
The Loop Is the Product — Roland Gavrilescu, Introspection
Read the talk
The Loop Is the Product
Roland Gavrilescu’s blueprint for improving agents connects execution, human judgment and production experiments: capture what a system learns in portable recipes, then optimize for work users value at a cost that makes sense.
From a talk by Roland Gavrilescu
At a glance
Ideas worth remembering
Build the feedback path as carefully as the worker: signals guide execution, verifiers check success, and artifacts inform the next improvement loop.
Preserve operating knowledge in versioned agent recipes: failures become evaluations, repeated behavior becomes skills, and human judgment remains part of the system.
Let humans calibrate the desired judgment and agents implement the evaluations. Then test whether users value that judgment before promoting a recipe change.
Establish that the output is valuable, then make its economics viable. Efficient execution only becomes a useful product advantage when customers want the work.
A car negotiation gives the loop an outcome
An agent that negotiates a car purchase has a concrete job: find available cars, compare prices, ask dealers for better offers and recognize when to close. Roland Gavrilescu, co-founder of Introspection, uses this example to introduce a product question that grew out of his work on agent infrastructure at xAI: how do you turn agents running long tasks into services that improve with their customers?
The discussion around agents had moved from improving models to improving harnesses—the surrounding software that lets a model use tools—and then to building loops. “The loop is the product” makes that progression concrete. The product needs a process that can act, receive useful information and decide what to do next.
In Gavrilescu’s account, an OpenClaw user assembled that process around car buying. Reddit discussions supplied price information; inventory searches established what was available; conversations with dealers produced competing offers. Putting dealers head-to-head gave the agent another action to take when an offer was unsatisfactory. A verifiable way to recognize an acceptable price supplied the stopping condition, after which the buyer could lock in the purchase. Gavrilescu reports that it worked, without giving a purchase price or savings figure.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Signals guide the work; verifiers judge the result
The next reference is the OODA loop: a way to organize observation and action in a changing environment. Gavrilescu connects it to agents calling tools and taking observations. Each action changes what the system knows, and the next decision depends on that new information. In the car example, a dealer’s response becomes input to the next negotiation.
Two parts of the loop deserve separate attention:
- Signals: The information that guides the agent’s next action. Gavrilescu identifies signal quality as a determinant of the loop’s success rate.
- Verifiers: The checks that establish whether an apparent success is actually correct. A result can look promising while failing the criteria that make it useful.
What changes when the result of one loop becomes input to another? The diagram shows the extra feedback path. The first loop does the work and checks its result. Its artifacts then give a second loop material for understanding what went well, what failed and what should change. Continuous improvement depends on making that return path useful.
Execution feeds an improvement loop
Read the diagram as text
- Signals. Execution — Information that guides the worker
- Agent work. Execution — Call tools and take observations
- Verify the result. Execution — Check whether apparent success is correct
- Learn from artifacts. Improvement — Understand successes and failures before the next loop
- Signals → Agent work: Guide execution.
- Agent work → Verify the result: Check the work.
- Verify the result → Learn from artifacts: Pass results and artifacts.
- Learn from artifacts → Signals: Feed learning into the next loop.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Store what the system learns as an agent recipe
“System distillation is the moat” names the second idea: preserve the knowledge accumulated while operating an agent. A run can teach you about its harness, profiles, evaluations, model, resources, tools or environment. If those lessons remain scattered across individual runs, they are hard to reproduce or improve deliberately. An agent recipe gathers them into something portable, versioned and able to evolve.
The analogy is to data recipes in reinforcement learning. As unwanted behaviors such as hallucination and reward hacking appear, researchers change the recipe that produces the system. Gavrilescu proposes applying that accumulated know-how to the broader agent system, including adjustments and human judgments discovered only after the agent begins acting in its environment.
Different observations become different parts of the recipe:
- Failure patterns become judges and evaluations. Recurring mistakes supply criteria for checking subsequent runs.
- Repeated behavior becomes skills and prompts. Useful ways of working become reusable instructions.
- User frustration informs harness extensions and memory. Problems encountered during use change the support the agent receives.
The proposed recipe belongs to the company using it and remains independent of a particular model or provider. Putting it in a Git repository makes its evolution part of the product’s ongoing development. Here, distillation includes evaluations, skills, prompts and operating choices; the accumulated system knowledge has value even before any of it moves into model weights.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Pi recipes preserve the choices behind the agent
Introspection’s implementation uses the Pi harness, Harbor for evaluations and Git repositories for versioning. Gavrilescu describes an early release called Pi recipes, intended to be owned by the user and managed by agents. Version history gives those agents a way to track what changed and why. The release is presented as an early implementation of the recipe idea, rather than a demonstrated guarantee of reproducibility across every provider.
The knowledge worth carrying includes the maker’s taste: the judgments that distinguish a desirable result from a merely plausible one. Agents should calibrate themselves to those judgments. Reusing someone else’s recipe would therefore mean bringing along the choices that produced the system, including the reasons behind them.
That expands the recipe beyond a skill’s instructions for doing a task. It also needs ways to encode taste in evaluations, run those evaluations, improve them over time and choose useful signals. Tool choices and harness profiles may vary with the model. Provider independence therefore still leaves room for model-specific operating decisions inside the portable recipe.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Establish value before optimizing its cost
The third idea is “valued work per watt.” Gavrilescu points to Cursor and Cognition as examples of a progression from building a product, to building evaluations for that product, to building models informed by both. He proposes extending this pattern beyond coding into domains such as customer support and legal research. The order matters: first establish what work has value, then determine whether delivering it is a good economic deal.
A base harness and initial evaluations provide a starting point. Running the system in production reveals the requirements needed to reach the desired level of performance. Once the system can produce valuable work, the next research problem is delivering that value without spending more than necessary. “Per watt” serves here as an optimization principle connecting useful output to resource use; the talk does not define an energy measurement or present a numerical efficiency benchmark.
Fine-tuning APIs and infrastructure make parts of this process accessible. The harder know-how is translating judgment into evaluations and validating it through experiments. Gavrilescu describes a route from a maker’s preferences into environments and evaluations, and potentially into model weights. But improving the surrounding system also requires interpreting the artifacts a worker produces and deciding which changes are worth trying.
Experiments then test the maker’s judgment itself. Offline evaluations can establish that an agent satisfies its creator’s criteria. Production use asks whether customers appreciate those criteria. An improvement loop needs both: a way to reproduce the intended judgment and a way to discover whether that judgment creates value for users.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A sourcing agent learns that prominence is the wrong signal
The practical example begins with a talent-sourcing agent: web search, LinkedIn, subagents and a system instruction describing its recruiter role. Recruiting makes taste visible because different people leading the process have different ideas of a good candidate. The baseline can search competently while choosing a strategy its owner dislikes.
Its execution traces reveal the problem: the agent repeatedly reaches out to big-tech employees, while this recruiter wants to find hidden gems. From the agent’s perspective, a prominent candidate looks like an obvious good choice. From the recruiter’s perspective, that choice misses the purpose of sourcing. Grouping similar behaviors and user frustrations into a pattern turns a vague complaint into a specific target for improvement.
The next step is a judge that reads a trajectory—the sequence of actions in a run—and identifies the unwanted pattern. Gavrilescu’s concrete question is whether the sourcing agent contacted Google employees instead of looking for hidden gems on GitHub. That gives subsequent runs a repeatable check. The criterion expresses this recruiter’s strategy, rather than a universal rule that big-tech candidates are unsuitable.
The proposed division of labor puts a human in charge of calibrating that criterion. Does the recruiter agree that the agent should favor hidden gems over big-tech outreach? Agents can build the evaluations and put the judgment into code; the person checks whether they are encoding the intended preference. This is where the observed failure becomes an explicit product decision.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Test the recipe with users before promoting it
A calibrated judge makes it possible to create recipe candidates: changes to the system that can be compared with the existing version. In the sourcing example, the intended observable change is a move away from big-tech outreach toward discovering hidden gems. Offline evaluations test whether a candidate follows that preference. Production experiments test whether users value the resulting service. The example describes this improvement process without reporting an experimental result.
How does a recurring sourcing mistake become the next recipe version? The diagram follows the example through two distinct judgments: the human confirms the desired recruiting strategy, then users test its value in production. The path makes clear why a candidate that satisfies the maker still needs an experiment before promotion.
Gavrilescu proposes A/B testing, with a multi-arm bandit as another possible experimental approach, to check whether customers appreciate the maker’s taste. Once that preference is validated with users, the candidate becomes the next version of the agent recipe. Repeating the process lets the system reproduce an increasingly well-defined service for other people.
The ending raises the ambition of the second loop: automate more of the maker’s role as a higher-level judge, so improvement agents can apply the same judgment to workers headed for production. Gavrilescu sees the continued accumulation of that judgment, together with workers that self-verify and cooperate, as a defensible basis for a vertical AI company.
That company still has to earn the customer’s choice. The closing economic test is whether the work is valuable and whether its price makes switching from a general-purpose coding agent worthwhile. Introspection’s invitation to vertical SaaS companies and agent labs is to build these research loops around their own products: learn what good means, reproduce it and deliver it at viable cost.
From sourcing traces to a new recipe
Read the diagram as text
- Baseline sourcing traces. Repeated outreach to big-tech employees
- Identify the mismatch. The recruiter wants hidden gems
- Calibrate a judge. Human confirms the strategy; agents encode the evaluation
- Evaluate a recipe candidate. Test whether it follows the intended sourcing preference
- Experiment with users. Test whether users value the preference
- Promote the next recipe. Advance after user validation, then repeat
- Baseline sourcing traces → Identify the mismatch: Cluster recurring behavior.
- Identify the mismatch → Calibrate a judge: Turn the pattern into a criterion.
- Calibrate a judge → Evaluate a recipe candidate: Create changes to test.
- Evaluate a recipe candidate → Experiment with users: Take the preference into production.
- Experiment with users → Promote the next recipe: Promote after users validate the value.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Read the transcript and explore slides
Loading transcript and slides…