---
title: "What our agents learn is a draft until we test it"
description: "Two AI Engineer workshops show how the check shapes what you keep. A newer 2026 recipe tests a saved lesson outside the agent. What holds, and what we do."
publishedAt: 2026-10-11
author: Ena Pragma
url: https://enapragma.co/field-notes/what-our-agents-learn-is-a-draft-until-we-test-it
tags: ["ai-verification", "self-improving-agents", "agent-architecture", "methodology"]
---

**What an AI agent learns is a draft until something other than that agent has tested it. The check you score it against then decides what you end up keeping.** Two workshops from the AI Engineer World's Fair, scheduled for June 29, 2026 and posted to YouTube on October 11, 2026, show this, partly by accident. A PayPal session ran a leaderboard for command-line tools that agents can use, and people optimized for the leaderboard. A Browserbase session showed an agent writing what it learned on a website into a reusable file, using a loop that grades its own runs. Research posted in September and early October 2026 adds to the point: one source gives a recipe for an outside check, and two papers flag what can go wrong without one.

Keeping what an agent found is still worth doing. This note is about keeping it safely.

This is research from public sources, not a test of ours. We have not run either workshop's code. We re-read every source below on October 11, 2026, Central time.

## The two workshops, and when they are from

Both were scheduled for Monday, June 29, 2026, according to the [conference schedule](https://www.ai.engineer/worldsfair/schedule.pdf), which places the conference at Moscone West in San Francisco. One is ["Burn your flags"](https://www.youtube.com/watch?v=aV_vgUSatqs), from PayPal's Mark Lummus and Navinkumar Patil. The other is ["Hill-climbing Skills"](https://www.youtube.com/watch?v=p7gaxmCUiIU), from Browserbase's Shubhankar Srivastava. The AI Engineer channel posted both videos to YouTube on October 11, 2026, about three and a half months after the scheduled date. So these are June talks, not new ones, and the newest evidence below is from September and October.

## What PayPal's workshop showed

PayPal starts from a failure that is easy to miss. According to the [video's description](https://www.youtube.com/watch?v=aV_vgUSatqs), "The human sees a question and arrow key options; the agent sees a redraw loop and loses the interface state." [PayPal's abstract](https://www.ai.engineer/worldsfair/schedule.pdf) calls the common fix a "non-interactive" mode, where a command "can be executed in a single pass by feeding it a bunch of flags." In the workshop, a PayPal speaker answers that "Flags multiply if you try to create flags that predict all the possible flows."

The description lists three approaches: run the command in tmux, send it keys and capture the terminal state; give the agent a side channel that returns structured JSON; and inject context that makes options and constraints explicit. A PayPal speaker frames all of the hints modestly: "I'm not going to call it a best practice. I'm just going to call it a good idea." The speakers offer tmux as the first hint and call it low effort.

Then came the contest. Participants adapted a coffee-ordering command-line tool called Barista 9000, with a leaderboard and a Mac Mini as the prize. A PayPal speaker said they would rank by score first and response time second. An audience member said a deterministic parser "defeats the spirit of this challenge entirely." Later a PayPal speaker said "a lot of people have figured out how to game the system." The winner said an agent had built a "deterministic CLI solver" and was now running it through tmux, a self-report, and the captions garble the word tmux. A PayPal speaker's own answer was that a command-line tool an agent uses should be deterministic, in a phrase credited to someone else, "a small sharp instrument."

That is a lesson about the check, not a method to copy. The leaderboard rewarded speed after correctness, so people optimized for speed. A PayPal speaker closed with three ideas to start with: "Give it good context, give it a side channel," and use tmux, which the captions spell "T-Mox."

## What Browserbase's workshop showed

Srivastava's workshop is about hill-climbing: improving something in small steps, scoring each step. His loop, which he calls auto browse, works like this. A doer agent tries a task in a browser. A teacher agent reads the doer's traces and edits a strategy file that the next attempt starts from. The [workshop repository](https://github.com/shubh24/ai-engineer-autobrowse) says the result is "a SKILL.md you can paste into Claude Code or Codex." A skill, here, is a plain markdown file of instructions that an agent loads. Browserbase's [written post](https://www.browserbase.com/blog/autobrowse), dated May 6, 2026, describes the same artifact as "a markdown file plus the deterministic glue (CLI calls, fetches, selectors, helper scripts) needed to repeat the job." So the agent explores. Later runs reuse a file or a program, and an agent still loads or runs it.

Browserbase says the loop can find things a person would miss. In the [Google Flights demo](https://www.youtube.com/watch?v=p7gaxmCUiIU), the first attempt failed, and the teacher found that a URL can encode the search directly, avoiding repeated calendar clicks. Srivastava calls it "obvious in hindsight but maybe as a human I wouldn't have thought of this."

The costs need care. In the vendor's demo the first attempt failed and cost about $12, and a later passing run cost about $3. That compares a failed try with a working one. It also does not count the cost of running the loop itself. Srivastava says that cost is spread over later runs and puts one loop at "maybe $30 $40 if it's super complicated $100 at most." We could not check that figure. A written number is in Browserbase's post: on one site, Craigslist, a "Traditional Claude Code loop: ~$0.22, ~71s" against a "Graduated Autobrowse skill: ~$0.12, 27s." The post gives no run count. All of these are vendor-reported.

The same post says where the loop fails. On a 167-row static HTML catalog, "Four iterations and ~$24 later, the loop still hadn't returned all 167 rows in a single output." The agent then wrote about 200 lines of Python that did it in under a second. That is picking the right tool, and Browserbase says so: "Autobrowse is not the right tool when the task is deterministic parsing."

Who decides that a run passed? The talk describes a teacher agent reading trace files. In the [workshop code](https://github.com/shubh24/ai-engineer-autobrowse/blob/14461ec4a3b263d2999c4d9b493b76e98237832e/src/runner.mjs), one model call rewrites the strategy file and also returns a pass or fail verdict, after reading a summary of the run, so we rest this point on the code. The teacher rewrites the strategy file after every run, pass or fail, and the code has no step that reverts it. The loop then runs the finished skill on the "same task, the polished skill applied end-to-end," so there is no held-out set. In the talk, Srivastava says "it evaluates itself. It's typically a binary" and "I try not to put many guardrails." He is open about the limits: the method needs "a replayable environment" and "some sort of verifiable outcome," and "did you find the best flight options for me might be slightly fuzzy."

Websites change, so a kept skill goes stale. He describes a setup that runs the loop when production fails and sends the fix to a human engineer as a pull request. Some customers, he says, have built pipelines where an agent heals a skill after a production failure, an anecdote we could not check. For his own version he says "This is actually one thing that I'm actively working on with the customer right now to implement."

## What the newer work says

- **A held-back set.** A [claude.dev post by Lance Martin](https://claude.dev/blog/automating-eval-design-and-hillclimbing/), September 28, 2026, builds the check into hill-climbing: "Use a train set that the hillclimber may read and a test set that is never seen." A change is kept only if both scores rise. When the train score rises but the test score stays flat, the routine "suspects overfitting and reverts the patch," and when the final gain is "within noise," it "recommends against merging." For open-ended output it uses a second model as judge, and "it should not be the model you are testing." Its worked example also changed models part-way, so we take the method, not the numbers.
- **Edits that overfit.** [SkillEvoReg](https://arxiv.org/abs/2609.30861), September 25, 2026, says "locally useful edits can accumulate into redundant or task-specific instructions, while new updates can disrupt behavior that previously worked."
- **No outcome signal.** A [paper posted October 5, 2026](https://arxiv.org/abs/2610.05777) notes that "In production, reliable information on whether a run has succeeded may be unavailable." On one of its two benchmarks, skills learned without outcomes were "worse by 3.1 pp" in its words, though the abstract does not spell out the comparison. On the other, it found "no clear preference between evidence regimes."
- **Skills written without feedback.** In [SkillsBench](https://arxiv.org/html/2602.12670v4), version 4 of June 14, 2026, "Self-generated Skills land below the no-Skills baseline on all three configurations," by 8.1 to 11.5 percentage points. There the agent wrote its skills before solving, with no feedback from runs, so this is not Browserbase's design.
- **Keeping can pay.** [Agentic Plan Caching](https://arxiv.org/abs/2506.14852), first posted June 17, 2025 and revised January 26, 2026, stores plan templates taken from finished agent runs. Its authors report that it can "reduce costs by 50.31% and latency by 27.28% on average while maintaining performance." That result predates both workshops, and it is the authors' own evaluation.

The papers are arXiv postings. Agentic Plan Caching's arXiv entry lists NeurIPS 2025, and we did not check the others for peer review. The numbers in all of these sources are the authors' or vendors' own.

## The strongest case against our argument

Many of these tasks already have an outside check, because the world supplies one. A flight search reaches results or it does not. A table returns 167 rows or it does not. Srivastava names this condition, "some sort of verifiable outcome," as what makes the method work. For tasks like that, a held-back set and five baseline runs are overhead. The video description adds that "replays make the claimed results inspectable," and his repair path ends with a human reading a pull request. The money is small too: by his own estimate a loop costs tens of dollars, which he says is spread over later runs, and a small team could spend more testing a skill than the skill saves.

An outside check is also not automatically honest. PayPal's leaderboard sat outside every entrant, and people still gamed it. So "outside" is necessary but not enough. The check has to measure what you want.

We agree where the outcome is a plain fact in the world: use it as the check and skip the ceremony. The case this note is about is narrower. It is a model's reading of its own run summary, or a stand-in such as speed, taking the place of the outcome you want.

## Keep it, but keep it like a compiler does

Compiler designers have a version of this problem. A tracing just-in-time compiler records the single path through the program's control flow that the execution takes, compiles it, and adds a guard that "bails out" when the assumption stops holding. In a [Cornell compilers course](https://www.cs.cornell.edu/courses/cs6120/2020fa/lesson/11/), "the JIT needs to switch back to interpretation" when a guard fails.

That is the shape of a kept procedure: a recorded fast path, a guard on its assumptions, and a fall back to the slow general route, here the agent exploring again, when the guard fails. The workshops give the first part. The upkeep, noticing when a kept file stops working, is the part Srivastava describes as a pattern and says he is still implementing with a customer.

## What to do this week

1. **Take the check away from the agent that did the task.** Write the pass or fail for a learned procedure yourself, or have a different agent write it before it sees the solution. You fail this step if one model call both edits the procedure and says it passed.
2. **Run the baseline five times first, and record cost per passing run.** That is everything you spent divided by the runs that passed. A failed first try then cannot pose as the "before." You fail this step if your "before" is a single run.
3. **Hold some cases back.** Keep the learned file only if the held-back cases improve by more than the spread you saw across the baseline runs. You fail this step if you cannot say what that spread was.
4. **Put a date, a re-check line and a tripwire at the top of every kept procedure.** You fail this step if any procedure your agents rely on has no date. An example of the three lines:

```text
Learned: 2026-10-11. Re-check by: 2026-11-11.
Stop using this and explore from scratch if: the first step returns a login page,
or two runs in a row fail.
```

Where your task has a fact in the world as its check, such as a booking that exists, that fact can do the work of step 1.

## What we do, and where we fall short

Two practices, stated as practice and not as a boast. Our [July field note](https://enapragma.co/field-notes/self-evolving-agents-evidence) describes the fix for a system that fools its own judge as "a check the system being improved cannot influence." That has been our rule since July: the thing that verifies a change must come from outside the thing that made it. Our builder agents' changes are reviewed by a second agent that did not build them, where the risk warrants. By our written rule, a lesson written because something failed is not done until that failure is re-run against it. We have been burned by checks that could not fail.

We fall short in at least one way: we do not yet re-test every kept procedure on a schedule, which is step 4 above. These two practices are our own account, and no outside party has checked them.

## What we did not check

- We read YouTube's auto-generated captions, not the audio or the slides. Words and numbers in the talks can be misheard, and the captions spell tmux as "T-Max" in places.
- We did not run the workshop repository, Browserbase's tools or any PayPal tool.
- I could not find a public release of PayPal's CLI or the workshop's code as of October 11, 2026. I searched GitHub repository search under the paypal, PayPalDev and paypal-examples accounts and for the names "PayPal cafe" and "Barista 9000", and looked at one page of npm results for a PayPal CLI. A control search on each source did find PayPal's agent toolkit.
- I did not find a study that compares interactive prompts with flags for agents.
- Browserbase's cost figures are vendor-reported, and the $30 to $100 loop cost is a remark, not a measurement.

Keep what the agent found. Date it, test it from outside, and write down what makes you stop using it.

## Sources

- [AI Engineer, Burn Your Flags: Interactive CLIs for Agents (Mark Lummus and Navinkumar Patil, PayPal), YouTube, posted October 11, 2026](https://www.youtube.com/watch?v=aV_vgUSatqs)
- [AI Engineer, Hill-Climbing Skills: Improve Agents Without Changing the Model (Shubhankar Srivastava, Browserbase), YouTube, posted October 11, 2026](https://www.youtube.com/watch?v=p7gaxmCUiIU)
- [AI Engineer World's Fair 2026, Schedule (PDF generated August 31, 2026)](https://www.ai.engineer/worldsfair/schedule.pdf)
- [Shubhankar Srivastava, ai-engineer-autobrowse workshop repository (last commit June 30, 2026, UTC)](https://github.com/shubh24/ai-engineer-autobrowse)
- [Browserbase, Autobrowse (May 6, 2026)](https://www.browserbase.com/blog/autobrowse)
- [claude.dev, Automating eval design and hillclimbing with Claude (Lance Martin, September 28, 2026)](https://claude.dev/blog/automating-eval-design-and-hillclimbing/)
- [arXiv, SkillEvoReg: Regularizing Agent Skill Evolution Against Overfitting (September 25, 2026)](https://arxiv.org/abs/2609.30861)
- [arXiv, Mining Agent Skills from Production Traces (October 5, 2026)](https://arxiv.org/abs/2610.05777)
- [arXiv, SkillsBench, version 4 full text (June 14, 2026)](https://arxiv.org/html/2602.12670v4)
- [arXiv, Agentic Plan Caching: Test-Time Memory for Fast and Cost-Efficient LLM Agents (first posted June 17, 2025; revised January 26, 2026)](https://arxiv.org/abs/2506.14852)
- [Cornell CS 6120, Lesson 11: Dynamic Compilers (Fall 2020 course page)](https://www.cs.cornell.edu/courses/cs6120/2020fa/lesson/11/)
- [Ena Pragma, AI Agents That Improve Themselves: What the Evidence Actually Supports (July 7, 2026)](https://enapragma.co/field-notes/self-evolving-agents-evidence)