DisCo and the Case for Reusable Agent Skills

An AI research agent plans, writes code, runs experiments, and explains its process in almost every language. It then implements k-fold cross-validation from scratch. Again.

Agents can resemble a brilliant theoretician who has read every textbook but has never stepped inside the lab. General knowledge travels well; the operating knowledge of a particular workflow often does not. Turning a design-of-experiments strategy into an executable plan requires knowing the data format, the machine limits, the measurement protocol, and the checks that catch a bad result.

Jianlyu Chen and colleagues’ DisCo agent addresses that gap by distilling know-how from repositories and papers into reusable skills. Its Creator constructs the skills; its Researcher uses them to solve subsequent tasks. Different operating instructions let the same underlying model take on different research roles ^{[1, 2]}.

What is a skill, really?

A skill packages its operating instructions, references, and callable scripts in a folder.

calendering-thermal-conductivity/
  SKILL.md
  references/
    derivation.pdf
    parameter-tables.csv
  scripts/
    compute_keff.py
    fit_parameters.py
    plot_ushape.py

SKILL.md is the agent-facing manual: what the skill does, when it applies, which inputs it expects, how to run it, and what usually goes wrong. The references hold deeper evidence. The scripts expose procedures that the agent can call instead of reimplementing. The names above illustrate a package structure; the wrappers should point to the project's actual implementation.

Here, $\mathcal{S}$ is the set of skills and $\mathcal{L}$ contains routing or dependency links. An entry skill points to the relevant component: data preparation, fitting, evaluation, diagnosis, or repair. The agent opens the material it needs at each step. This progressive disclosure makes a large library usable without loading every manual into the context window ^[1].

Scope, ground, construct, verify

A repository, paper, or concrete problem supplies the anchor $z$. Capabilities $\mathcal{Q}$ are grounded in evidence $\mathcal{X}$, packaged into a candidate skill graph, and verified with a construction record $R$.

1. Scope. Identify the capabilities worth exposing. Starting from a repository might yield “fit a thermal closure” or “run inference.” Starting from a task such as “increase energy density while keeping adhesion above a threshold” instead reveals capability gaps.
2. Ground. Gather source code, documentation, examples, configurations, data definitions, and tests. A task-driven pass may need additional papers or operating procedures to fill gaps.
3. Construct. Turn that evidence into instructions and callable tools. Package the routines, define their inputs and outputs, and connect the resulting skills.
4. Verify. Exercise the procedures with assertion-backed cases, small fixtures, and native examples or tests. Repair failures locally and retain unresolved gaps in the construction record $R$.

A file that describes an experiment is only part of the job. Verification has to establish that the procedure runs and that its checks detect meaningful failures. For manufacturing, useful checks include physical bounds, conservation, approved parameter windows, and a trace from each reported output to the data and configuration that produced it ^[2].

Creator and Researcher share the same machinery

DisCo separates skill construction from skill use while retaining the model and execution harness.

$M_\theta$ is the language model, $H$ is the harness for planning, tools, memory, and verification, and $\mathcal{K}$ is the operating knowledge available through skills. Creator builds and verifies that knowledge; Researcher retrieves the subset relevant to its task. Repository distillation is paid for once and reused, although source changes still require maintenance.

This is useful when an agent repeatedly works on related problems. The workflow for a hyperparameter search can preserve the correct split, scoring convention, and recovery path across many runs. The next session can start from that procedure instead of reconstructing it from scattered notebooks.

DisCo on my calendering model

For this article’s 30 September update, I ran DisCo 0.2.1 in Creator mode on my calendering project, using Kimi K2.6 through OpenRouter. The anchor was the actual source repository: the electrode thermal model, data-loading routines, measured calendering states, documentation, and tests. I scoped the extraction to forward through-plane conductivity and the contact/reorientation workflow ^[3].

Creator identified the conductivity and inverse-porosity APIs, the family-specific calibration routines, and the distinction between gas-filled and electrolyte-filled pores. It exercised ten groups of assertions against the repository’s Python implementation on CPU.

All ten check groups passed, including the Knudsen correction, isotropic NMC limit, material-family registry, and a single-family calibration. A second pass checked seven integrated results, including the contact and reorientation fits and inverse-porosity uncertainty. The generated skills and execution record keep the inputs and results inspectable.

These are small, fixed-parameter API cases. The error figures reproduce the repository’s own calibration summary and measure in-sample fit; held-out states and transfer to another chemistry still need their own evaluation. Conductivity alone can also leave contact evolution and graphite reorientation difficult to distinguish.

A small Researcher demo

I then opened a separate Researcher session with the generated skill and asked it to compare dry graphite at three porosities. It produced a short Python wrapper around the existing APIs. The sweep used an 18 µm particle diameter, solid conductivity of 25 W/(m·K), and bridge conductivity of 130 W/(m·K).

Separate wet-graphite forward/inverse checks recovered all three porosities with errors below $10^{-8}$. This is a small illustrative sweep, with the script and numerical output retained alongside the skill. The fixed contact fraction demonstrates the model’s response; a recipe-specific prediction requires calibration.

That exercise made the Creator/Researcher split tangible: the first session assembled the API conventions and checks; the second used them for a new request. Reviewing the generated record still mattered. I corrected its date, check-count labels, and an unsupported total-runtime claim against the command output. Execution evidence belongs next to the instructions.

The continual-learning work supplies another recurring workflow: specify the task sequence, freeze or adapt the representation explicitly, compare IGFA with matched baselines, and record accuracy together with forgetting. A low forgetting score has little value if projection has also stopped the new task from learning. The feature regime, random seeds, retained update norm, and available capacity belong in the operating instructions.

The practical starting point is one repository and one short, executable chain. Keep units, parameter conventions, and physical checks in the skill; route to deeper references when needed. For larger Researcher tasks—comparing acquisition rules, predicting held-out states, or running an IGFA sequence—the data split, task order, and resource budget should be fixed before comparing results. The CPU checks establish that the packaged procedure runs; measuring how much time or accuracy the skill adds requires a separate comparison.

Why operational knowledge is worth the effort

The AREX-Skill authors report gains while keeping the backbone, harness, and execution budget fixed.

Those correspond to relative gains of 134.3%, 34.4%, 9.2%, and 14.0%. They are the authors’ benchmark results, rather than a measurement on my projects. The implication is nevertheless interesting: better operating context can improve an existing agent without changing its backbone ^[1].

For a lab, the practical starting point is a narrow domain and a few recurring tasks. Pick the repositories and papers those tasks depend on; list the capabilities actually used; collect the examples and checks; wrap the stable routines; and connect the resulting skills through an index. Then record which skills get reused, where they fail, and what still requires improvised reasoning.

Task-oriented distillation extends the same approach. When a new process objective exposes a missing capability, the agent can gather the relevant evidence and construct a skill for it. Over time, the library can hold procedures for designing experiments, analyzing measurements, and responding to drift. This gives a concrete form to the continual-learning process controller I have been sketching.

Many labs have accumulated decades of knowledge about running a process. Research agents still rediscover the same data conventions and experimental checks each time. DisCo offers a way to make those procedures explicit, callable, and maintainable. The next agent should be able to use the wheel that already exists.