AgentDescent
Evolve agent skills, prompts, and harnesses through parallel, conflict-aware edits.
Per-dimension scores and reasoning
The evidence shows a dependency-free core, isolated plugin copies, frozen permission configuration, a recursion guard, a version-controlled ledger, and explicit confirmation before starting or writing changes back. Publishing workflows use scoped permissions and OIDC, while the fixed data path and sole feedback path are described clearly. Deductions apply because no complete policy is shown for key storage, redaction, log scrubbing, or data retention; workflow dependencies use version tags rather than commit digests; and cancel, resume, and git history do not amount to a fully documented user-facing rollback procedure. The paper author, DOI, and code origin are attributed, but package authorship is generic and publisher identity remains unknown.
The README, package metadata, and test utilities are strongly consistent about Python support, offline operation, entry points, and the merge model. Golden traces deliberately exercise both fusion and conflict decisions. The dependency surface is small and the Python 3.9 versus MCP constraint is handled explicitly, but optional dependencies have only lower bounds and real runs still depend on external models, datasets, CLIs, and git. Fault fixtures cover authentication errors, throttling, permanent and transient outages, wedged work, empty responses, and ledger failures, with an explicit expectation of prompt and visible failure reporting.
The material identifies research users, agent-host users, and algorithm implementers, with scenarios spanning prompts, skills, directories, agent code, and plugins. Strategy, policy slots, aggregator factories, and serial, synchronous, and asynchronous scheduling provide substantial adaptation points. Boundaries are unusually explicit: this is a research reference rather than a production system, governance cannot be replaced, key spaces constrain fusion, and unsupported policy fields are rejected. Trigger phrases and the doctor/plan/start/status/apply procedure are described, but the actual shared skill and its trigger rules are absent, so trigger precision is not fully evidenced. Python compatibility, offline demos, multiple host CLIs, optional MCP support, and version markers support strong environment fit.
The README is well organized around installation, quickstarts, architecture, extension seams, results, documentation, citation, and scope. It distinguishes the core install, development setup, MCP option, and repository-only examples, and includes both offline and model-backed examples. Limitations are candidly documented, including research status, non-additive diffs, key-space constraints, statistical limits, and unretained raw data. MIT licensing is complete and consistent with metadata. Deductions apply because the source acknowledges historical version drift and does not include the current version file, while no changelog, release history, or migration policy is supplied. A contribution route and automated publishing exist, but named maintenance ownership, support channels, and response expectations are unclear.
The result exposes the evolved artifact, final reward, and outcome reasons, while CLI and MCP surfaces provide inspection, status, display, application, cancellation, and resumption. Parallel conflict-aware merging, configurable strategies and policies, and nineteen algorithm ports offer clear marginal value over a basic serial self-improvement loop. Model-call reduction, wall-clock speedup, accuracy change, confidence intervals, and pre-run call-count quotation provide substantial cost-benefit evidence. These scores assess the quality of the static evidence only and do not imply independent reproduction.
Major empirical claims identify tasks, models, worker counts, seeds, budgets, sample sizes, intervals, or raw-data locations. The architecture is said to derive from paper source, and test utilities explain exactly which merge decisions and fault classes they guard, providing strong traceability. README statements are corroborated in places by project metadata, workflows, and test code, but the paper, main test bodies, result files, and core implementation are not included in the supplied evidence, preventing full cross-source corroboration. The material clearly separates benchmark-faithful ports from analogues, measurements from hypotheses, confidence intervals from unavailable significance, and retained from unretained data.
- This is a low-confidence static review: no code, tests, demos, or benchmarks were executed, and linked papers, documentation, package registries, and result data were not verified.
- The project explicitly describes itself as a research reference implementation rather than a production system. Use isolated repositories, least-privilege credentials, human review, and verified backups before allowing it to modify skills, prompts, code, or plugins.
- Runs against real models or datasets may send prompts, task content, and outputs to external providers. The supplied material does not fully specify credential, sensitive-data, logging, or retention controls.
- Some per-run benchmark data was not retained, and the fidelity and performance of the nineteen algorithm ports cannot be independently established from the supplied files alone.
What does this agent do, and when should you use it?
AgentDescent is a Python research framework that represents skills, prompts, directories, or agent code as versioned state and lets multiple workers propose changes concurrently. Workers execute tasks against ledger snapshots and emit evidence-backed diffs, while a single aggregator resolves conflicts, fuses compatible edits, applies statistical acceptance, and commits the result transactionally. Its main entry point is evolve(), used with Task objects, configurable Strategy and Policies implementations, dataset helpers, scorers, and model adapters. It can run as a zero-required-dependency Python library and also exposes a CLI, an MCP server, and host plugins for Claude Code, Codex, OpenCode, and DeepSeek Harness. A run produces the evolved artifact together with held-out reward, outcome explanations, and commit, fusion, staleness, and conflict counters. The repository explicitly describes itself as a research reference implementation rather than a production system, making it a better fit for experimentation and controlled algorithm studies than unattended critical workloads.
evolve() takes a collection of Task objects, a reward function returning a value in [0, 1], and either run/propose callbacks or an LLMAgent. Each worker reads a snapshot from the git-backed ledger, runs tasks, and emits diffs with evidence cards; the aggregator then applies the five-stage pipeline with selection, staleness, conflict, fusion, acceptance, and promotion rules before committing a winner. AppendRules, KeyedRules, FileTree, and SingleSlot model the artifact as deduplicated lessons, categorized entries, a path-keyed directory, or one prompt value, respectively. tasks_from, hf_rows, and scorer convert dataset rows into tasks and evaluate outputs, while openai_compatible, claude, and claude_code connect model APIs or the Claude Code CLI. The CLI and MCP server mirror doctor, plan, start, status, show, apply, cancel, and resume operations, supporting inspection, call-count approval, detached execution, and confirmation before changes are applied.
- A researcher comparing serial, synchronous, and barrier-free asynchronous self-improvement under a controlled rollout budget.
- A prompt engineer with labeled examples who wants to evolve a single instruction using evolve(), SingleSlot, and scorer("exact").
- An agent developer who wants several workers to accumulate deduplicated lessons concurrently through AppendRules.
- A team experimenting with skill directories or agent code that wants FileTree to isolate conflicts by file path before merging compatible edits.
- An algorithm researcher who wants to run the supplied ACE, GEPA, EvoSkill, DGM, or OpenEvolve ports on one scheduler and inspect them first with --dry-run.
- A Claude Code, Codex, OpenCode, or DeepSeek Harness user who wants to plan, start, monitor, and apply evolution runs through a shared skill, MCP server, and CLI.
What are this agent's strengths and limitations?
- It treats diffs as the optimization signal and explicitly manages conflicts, fusion, staleness, and transactional commits, allowing more concurrent progress than a strictly one-change-per-iteration loop.
- The Python 3.9+ core has zero required dependencies and includes deterministic offline demo and test paths that need no credentials.
- Strategies and all eight policy slots use replaceable Protocol interfaces; drivers reject policy fields they cannot honor instead of silently ignoring them.
- It offers Python, CLI, MCP, and agent-host surfaces alongside OpenAI-compatible, Claude API, and Claude Code adapters.
- Nineteen self-evolution algorithm ports can run under serial, synchronous, or barrier-free scheduling, with benchmark-faithful ports distinguished from analogues.
- It is explicitly a research reference implementation, not a production system; production adoption would require additional reliability, security, operations, and scaling work.
- Diffs cannot be averaged like numeric gradients. Same-key proposals conflict, and SingleSlot makes every concurrent proposal contend for the only key, so results depend heavily on state design and aggregation.
- Quality improvement is not guaranteed. The throughput premise is presented as a testable hypothesis, and some reported comparisons cannot support statistically significant claims.
- Live model and dataset workflows introduce provider credentials, network traffic, and inference costs that the offline demo does not exercise.
- Algorithms requiring archives, per-instance score rows, or island pools need a custom aggregator_factory because ordinary Policy slots lack the necessary retained state.
- Per-run data was not retained for some merge-versus-selection sweeps, so those results can be re-measured from named commands but not fully recomputed from archived raw runs.
How do you install or deploy this agent?
Python 3.9 or newer is required. Install the core package with:
pip install agentdescentThe core engine has no required third-party dependencies. To run the repository examples:
git clone https://github.com/Birfy/agentdescent
cd agentdescent
pip install -e ".[dev]"
python -m examples.run_demoThat demo requires neither an API key nor network access. To connect supported agent hosts from a repository checkout, run:
bash scripts/setup-hosts.sh
agentdescent demo
agentdescent doctorHow do you use this agent?
A minimal offline run defines tasks, scoring, execution, and failure-driven proposals directly:
from agentdescent import Task, evolvetasks = [Task(id=f"t{i}", prompt=f"item {i}") for i in range(12)]def reward(task, output):
return 1.0 if "2026" in output else 0.0def run(rendered, task):
return "answer" + (" 2026" if "year" in rendered else "")def propose(rendered, task, output, reward):
return "always state the year"result = evolve(tasks, reward, run=run, propose=propose,
rounds=6, n_workers=3, max_concurrency=3)
print(result.rendered, result.final_reward, result.error)For model-backed runs, pass agent=LLMAgent(claude(...)), LLMAgent(openai_compatible(...)), or LLMAgent(claude_code()); API-backed paths require suitable credentials and network access. Set asynchronous=True and async_ratio=3 for barrier-free scheduling. In a supported host, the documented procedure runs agentdescent doctor, prepares a specification, quotes the call count, waits for approval, launches the run detached, and requests approval again before applying changes.
How does this agent compare with similar options?
Compared with serial self-improvement that accepts at most one change per iteration, AgentDescent attempts to generate edits concurrently and merge compatible work. The README reports model-call and wall-clock improvements in specified experiments, but limits those claims to their tasks, budgets, seeds, and key-space designs. ACE, GEPA, EvoSkill, SkillOpt, ADAS, DGM, OpenEvolve, and ERA are offered as ports on the common engine rather than separate end-to-end loops; the other eleven entries are explicitly described as microports or analogues and should not be cited as benchmark reproductions.