TEAL: The Agent Builds Its Own Library of Tools and Skills From Its Past Runs

STEP 0: The Executor solves a batch of questions (5) with the current library
        → logs + summary: which tools were used, where there were many steps in a row without them
STEP 1: The Explorer studies the data WITHOUT questions or logs (once every 4 batches)
        → add tool / update tool (catalog, index, search, loader)
STEP 2: The Critic reads the logs + the tool list
        → update tool (defects) / promote tool (exists but unused) / add tool (gap)
STEP 3: The Skill Writer updates the rules file
        → general rules + an entry for each tool
STEP 4: Verification. The Executor reruns the questions with the new library
        → keep if: (a) the tool was used, (b) there is an answer and no more steps,
          (c) if the answer changed, the log supports the new one
        → otherwise roll back (one attempt to fix the skill wording)

Each role is a separate request or a separate agent. The Toolsmith writes code and tests based on the proposals. The Analyst acts as referee and compares two runs when their answers disagree.

Task: An Amazon seller keeps a folder of 60 exports: monthly reports on sales, returns and ads. The Excel headers don't start on the first row, and the file names make no sense. A Claude Code analyst burns the first 10 steps every time just finding the right file and parsing the header. The goal: have the agent build a catalog and scripts once, and add rules for using them to CLAUDE.md.

Prompt (Explorer role):

<Role>
You are an experienced marketplace data analyst setting up a workspace 
for your colleagues. You have not been given a single question. Your job is to prepare 
tools for the entire ./amazon_reports folder, not for one report.
</Role>

<Task>
1. Walk the folder: structure, formats, headers, sample rows.
2. Propose a list of tools (add tool) — for each: name, 
   what it does, which questions it will speed up.
3. For search — build a catalog in SQLite: file, sheet, header 
   row number, column names, 3 sample rows, period.
4. Write an Excel loader that finds the header row on its own.
5. Write unit tests and run them.
</Task>

<Constraints>
- Don't build for a specific question — only what many questions will need.
- Don't modify the source files.
</Constraints>

<Output>
A list of tools with descriptions + script files + test results.
</Output>

Result: The agent walks the folder and builds a catalog of files with columns and sample rows. It writes an Excel loader with header detection, runs the tests and hands back a list of tools, explaining which questions each one speeds up. The next steps (Critic, Skill Writer, verification) are separate requests based on the template below.

Weakness: The model doesn't accumulate experience between runs. The agent tackles every question as if it were seeing the data for the first time. Under a step limit, it spends the budget on searching and cleaning and never gets to the analysis. And there's no way to check that a new script is correct: there are no reference answers.

Strength: The model is good at reading its own logs and spotting recurring waste: seven steps in a row of file searching, the same header parsing over and over. It also writes scripts well and can compare two runs on whether an answer is backed by tool output or merely asserted.

How the method exploits this: Two roles attack the problem from different sides. The Explorer builds general tools without any questions. The Critic fixes specific defects found in the logs. Correctness is checked indirectly: if a tool is genuinely useful, the agent uses it, stays within the step budget and reaches an answer backed by the log.

Control knobs: - Step limit during "training" → the tighter the limit, the clearer the signal. A library grown under a narrow limit also worked better under a wide one. - Step tolerance during verification (in the paper: more than 20%, at least 2 steps) → loosen it for hard tasks, tighten it for easy ones. - How often the Explorer runs (in the paper: once every 4 batches) → less often for stable data. - One attempt to fix the skill when a tool is ignored → if the agent ignored a tool, the skill wording is more often to blame than the tool itself. - The referee doesn't assume the old answer is correct → don't hand it the "right" option as an anchor.

The paper doesn't include prompt texts, so the template below was assembled from the descriptions of the roles and stages. I kept the logic intact (roles, inputs, three checks).

=== ROLE 1: EXPLORER (run at the start and periodically) ===
<Role>
You are an expert in {subject_area} preparing tools for 
the entire dataset {data_path}. You do NOT see questions or logs.
</Role>
<Task>
Study the structure, formats and schemas. Propose operations:
- add tool {name}: what it does, what it speeds up
- update tool {name}: what to fix
Build tools that store precomputed data (catalog, value 
index) in {storage_format}. Implement them and verify with tests.
</Task>

=== ROLE 2: CRITIC (after each batch of questions) ===
<Role>
You are an auditor of the agent's work. You look for where it wasted steps or made mistakes.
</Role>
<Input>
Logs: {run_logs}
Tool summary: {used / unused / 
where_many_steps_in_a_row_without_tools}
Current tools: {list}
</Input>
<Task>
Propose changes using only these operations:
- update tool — a defect in a tool that is being used
- promote tool — the tool existed, could have helped, but wasn't used
- add tool — a gap the current tools don't cover
Back every proposal with a reference to an episode in the log.
</Task>

=== ROLE 3: SKILL WRITER ===
<Task>
Update the file {skills.md} / {CLAUDE.md}. Two parts:
1. General rules (for example: "query the catalog first, then search in the shell")
2. An entry for each tool: when to call it, how, an example.
Account for every change and every promote tool.
</Task>

=== ROLE 4: VERIFICATION (rerun the same questions) ===
<Verification>
For each change, compare the original run and the rerun:
Check 1: did the agent call the changed tool? No → ask the Skill 
            Writer to rewrite the instruction and rerun once.
Check 2: was an answer produced? no more steps than {n} + max(2, 20% of {n})?
Check 3 (only if the answer changed): compare the logs. Which answer 
            is backed by tool output rather than merely asserted? 
            Do not assume the original answer is correct. If it favors the old one — 
            fail; if it favors the new one or is unclear — pass.
The change stays if at least one rerun passed all three checks. 
Otherwise — roll back.
</Verification>

Fill in: {subject_area}, {data_path}, {run_logs}, {skills.md} (the name of your instructions file), {n} (the number of steps in the original run).

🚀 Quick start — paste into the chat:

Here is the TEAL template (a loop for improving an agent's tools). Adapt it to my task: [your task and where the data lives]. 
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask about your subject area, the format and location of your data, what typical questions look like, what tools and step limits your agent has, and where your instructions file lives. It needs these answers because the Explorer role works off the data structure, while the Critic and the verification work off logs and limits. It will take the roles and the three checks from the template and fit them to your environment.

⚠️ Requires infrastructure: in the study, five agents were orchestrated in code (OpenHands). You can repeat the loop manually in a chat step by step, but running it automatically in batches only works if you build your own pipeline or set up automation.

⚠️ Narrow domain: tested only on "data lake" analytics (lots of heterogeneous files and tables). No gains were shown for single-file tasks or tasks without repetitive work.

⚠️ May not help with a generous budget: a library grown with a limit of 20–30 steps sometimes turned out worse than the baseline without tools. The agent solves everything on its own anyway, the tool changes nothing, and there's nothing to verify against.

⚠️ A strong model in the evolution roles: all the tool-building roles were played by the most powerful model in the lineup (Opus-4.8). Results with weaker models in those roles were not tested.

⚠️ Verification is indirect: without a reference, you can let through a tool that is "backed by the log" but substantively wrong. The authors say their verification is comparable to reference-based checking, but the samples are small (dozens of questions).

The researchers took two data-lake analytics benchmarks. KramaBench: 1,742 files, 51 training questions and 53 test questions. LakeQA: 4,180 tables, 50 training questions and 80 test questions. Four models served as executors, and Opus-4.8 played the evolution roles. They compared against the same agent without a library and against other methods (including ISE, which keeps any tool that doesn't crash with an error), and varied the step limit from 10 to 30. Each measurement was repeated three times.

With a limit of 10–15 steps, every executor gained on both datasets. Sonnet-5 at 15 steps: +9.3 points on KramaBench and +21.7 on LakeQA. In five out of eight cases, the agent with the library at 15 steps was no worse than the baseline at 30. The explanation is simple: one tool call replaces "find, load, join."

The biggest surprise: a tight step limit "trains" better. A library grown at 20 steps and run at 30 scored 68.3, versus 64.2 for one grown at 30 from the start and 59.6 with no library. Under a tight limit, failures are obvious (empty answers, truncated pipelines), and a single saved step changes the outcome. With a generous budget, the agent brute-forces everything, and a useful tool is indistinguishable from a useless one.

Other findings: 50 synthetic questions (TEAL-Q) produce a library comparable to one built from real questions. Rerun-based verification is on par with verification against reference answers. A library grown in OpenHands works unchanged in Google ADK, Codex CLI and Prime Agent (up to +16.3 points).

🔧 Technique: drop the questions, keep only a tight limit → "training" under pressure

Before collecting logs for the Critic, give the executor an explicit constraint:

You have {10–15} steps per question. If you run out, answer with 
what you have and note where you lost time.

Failures become more visible, and the Critic has an easier time finding waste. Then lift the limit: the library keeps working.

Extrapolation: a manual version for Claude Code or Cursor

This isn't the paper's method, it's my simplified version for people working without an orchestrator:

Here is the log of my sessions for the week. Find the stretches where you spent 3+ steps in a row 
doing the same thing without a ready-made script. For each one, propose: 
(a) a script, (b) a line for CLAUDE.md saying "when to call it". 
Don't write anything until you've shown me the list.

Then check by hand: on the same three tasks, does the agent use the script and finish in fewer steps?

• Paper: Unsupervised Tool Evolution for Coding Agents in Data-Lake Analytics (TEAL, TEAL-Q)
• Authors: Yuqing Yang, Yurong Liu, Deqing Fu, Manav Garg, Sravan Babu Bodapati, Fatma Ozcan, Alon Y. Halevy, Jiani Zhang
• Institutions: University of Southern California, Google, New York University
• Benchmarks: KramaBench (Lai et al., 2026), LakeQA (Wang et al., 2026)
• Environment: OpenHands — github.com/OpenHands/software-agent-sdk
• Compared against: ISE (Li et al., 2026), DataCOPE (Qiu et al., 2026), EvoOntology (Chong et al., 2026)