# Agent Rsi Research

> Research, classify, reproduce, and design recursive self-improvement (RSI) systems for LLM agents. Use for Agent RSI literature reviews, classic-paper reading lists, self-evolving/self-improving agent comparisons, repository audits, reproducibility plans, or experiments involving persistent memory, skills, prompts, tools, workflows, agent code, model weights, or the updater itself. Distinguishes durable recursive improvement from ordinary reflection, self-correction, and prompt iteration.

- Skill: `pnx2003/agent-rsi-research` (Agent Skill, multi-file: 12 files)
- Install (CLI): `npx skillmds@latest add pnx2003/agent-rsi-research`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pnx2003/agent-rsi-research/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: pnx2003 (https://skillmd.com/u/pnx2003)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/pnx2003/agent-rsi-research

---


# Agent RSI Research

## Purpose

Build evidence-backed maps and experiments for self-improving agents without inflating ordinary self-correction into RSI. Treat RSI as a property of a persistent update-and-validation loop, not as a marketing label.

Use primary papers and official repositories. State the literature cutoff and call a corpus a **working census**, never literally complete.

## Route the Request

1. For definitions or taxonomy, read `references/scope-and-taxonomy.md`.
2. For a reading list or intellectual history, read `references/classic-reading-path.md`.
3. For a paper search, read `references/catalog-notes.md`, then query `references/paper-catalog.csv` with `scripts/query_catalog.py`.
4. For repository comparison or reproduction, read `references/code-notes.md`.
5. For an implementation or experiment plan, read `references/experiment-playbook.md` and `references/safety-and-evaluation.md`.
6. For a new or "latest" survey, browse primary sources and update the working census before answering.

Load only the references needed for the task. The catalog is broad; the classic path is deliberately selective.

## Core Test

Represent the deployed agent as intrinsic configuration:

`A_t = (theta_t, Sigma_t)`

Here `theta_t` is the model and `Sigma_t` is its persistent scaffold: prompts, memory, skills, tools, workflow, code, or update policy. Keep transient task state `X_t` separate.

Call a method **self-improving** only when experience produces a durable update to `theta` or `Sigma` that affects later tasks. Call it **recursive** only when the mechanism that proposes, selects, or validates updates is itself in the editable target, or when improvements demonstrably improve future improvement ability.

Apply the L0–L5 rubric in `references/scope-and-taxonomy.md`. Never infer RSI from words such as *reflection*, *evolution*, *autonomous*, or *self-* alone.

## Literature Workflow

### 1. Fix Scope

Record:

- cutoff date;
- whether the user wants core RSI, enabling methods, adjacent work, or all three;
- artifact classes: memory, skill, prompt, tool, workflow, code, weights, meta-updater;
- whether theory, empirical systems, safety, benchmarks, or code matters most.

If “Agent RSI” is ambiguous, default to recursive self-improvement of AI agents and say so.

### 2. Search in Concentric Rings

Start with exact phrases: `recursive self-improvement agent`, `self-modifying agent`, `self-improving coding agent`, `self-evolving agent`, and `agent self-improvement`.

Then search by mutable artifact plus update language:

- `memory OR skill OR prompt` + `agent` + `evolve OR optimize OR learn`;
- `workflow OR scaffold OR harness OR architecture` + `agent` + `search OR self-improve`;
- `code OR weights OR updater` + `agent` + `self-modify OR recursive`;
- `benchmark OR audit OR poisoning OR verifier` + `self-evolving agent`.

Trace citations backward from surveys and forward from the classic set. Prefer arXiv/venue pages and official code organizations. Deduplicate by title and arXiv identifier.

### 3. Classify Every Candidate

Extract these fields before judging it:

- mutable object;
- proposer identity;
- feedback/evaluator;
- persistence across tasks;
- acceptance rule;
- iteration count and lineage/population structure;
- whether the updater is editable;
- held-out evaluation and verifier independence;
- code availability and execution isolation.

Tag each item as `core`, `enabling`, `adjacent`, `benchmark`, `survey`, `audit`, or `safety`, then assign an RSI level.

### 4. Select Classics Transparently

Rank papers on conceptual novelty, field influence, clarity of the update loop, empirical evidence, code inspectability, and coverage of a distinct design family. Do not rank only by benchmark score.

Use the classic path as the default spine, but replace items when the user's domain demands it. Include at least one boundary case and one critical/audit paper so the list teaches what does **not** count.

### 5. Report With Calibrated Claims

Separate:

1. proved properties;
2. demonstrated benchmark gains;
3. repository behavior observed in code;
4. author claims not independently verified;
5. your own inference.

For recent papers, avoid calling them classics; call them frontier representatives.

## Code-Audit Workflow

Inspect the official repository rather than only the README. Locate:

- the outer improvement loop;
- the editable artifact and write boundary;
- proposal/prompt generation;
- evaluator and score aggregation;
- accept/reject, rollback, and archive logic;
- train/validation/test separation;
- subprocess, Docker, network, secrets, and generated-code controls;
- commit pin, environment file, and benchmark version.

Build a table with `repository`, `mutable artifact`, `proposer`, `validator`, `selection`, `persistence`, `isolation`, and `reproduction burden`. Use the audited examples in `references/code-notes.md` as patterns, not eternal facts; recheck repository heads when current details matter.

Never execute untrusted generated code on the host. Static inspection is the default. Reproduction uses an isolated container or VM with scoped credentials, resource caps, an explicit workspace allowlist, and no ambient secrets.

## Experiment Workflow

Choose one artifact class first. A credible study contains:

- a frozen baseline and token/compute-matched control;
- distinct development, acceptance, and final-test tasks;
- a durable versioned artifact after every accepted update;
- regression, cost, latency, and safety gates;
- rollback and a complete provenance ledger;
- multiple seeds and confidence intervals;
- an ablation of memory versus updater versus selection gate;
- a transfer test showing improvement beyond the exact training task.

For a recursive claim, also test whether later generations improve the **update process**, not just task performance. Follow `references/experiment-playbook.md`.

## Catalog Commands

Run from the skill directory:

```bash
python scripts/query_catalog.py --validate
python scripts/query_catalog.py --tier classic --format table
python scripts/query_catalog.py --min-rsi 3 --code yes --format table
python scripts/query_catalog.py --object code --year-from 2025 --format json
python scripts/query_catalog.py --query verifier --format csv
```

Update a catalog row only from a primary paper or official repository. Keep concise notes factual and put interpretation in the prose references.

## Answer Shape

For a substantial literature request, return:

1. scope and cutoff;
2. one-paragraph definition and L0–L5 criterion;
3. classic/core reading path with reasons;
4. broader landscape grouped by mutable artifact;
5. code comparison;
6. open questions, negative evidence, and safety risks;
7. a reproducible next-step plan.

Prefer a compact comparison table over a long paper dump. Link to primary papers and official repositories.

## Non-Negotiable Guardrails

- Do not call output-only critique RSI.
- Do not use final-test data as the acceptance gate.
- Do not let the same fallible signal both generate and certify updates without an independent check.
- Do not preserve an update solely because its self-reported score improved.
- Do not silently ignore failures, regressions, cost growth, or reward inflation.
- Do not run self-edited code outside isolation.
- Do not imply open-ended, safe, or generally intelligent improvement from a bounded benchmark loop.