[RESEARCH/IDEA] Reusable evolutionary-search library for RLM callers #441

New issue

Closed

opened 2026-09-10 21:18:15 +00:00 by nsaspy · 1 comment

nsaspy commented

2026-09-10 21:18:15 +00:00

Owner

Companion to lost-rob0t/agentProlog#2.

Mission

Research and design a domain-neutral evolutionary-search library in Prolog that can be used with prolog-rlm and consumed by downstream harness integrations, especially the AgentProlog DeepSeek Harness plugin.

This is intentionally split across two repositories:

DeepSeek Harness
  -> AgentProlog out-of-tree Cordis plugin
  -> thin TypeScript/Cordis <-> Prolog adapter
  -> reusable prolog-rlm evolution library
  -> existing RLM runtime/Future/authority/verification/tracing

The algorithmic/evolutionary machinery belongs here when it is reusable beyond AgentProlog. DeepSeek-specific lifecycle, UI, service registration, plugin packaging, and adapter glue belong downstream in lost-rob0t/agentProlog.

Why a library, not product code

The reusable layer should support RLM callers without depending on DeepSeek Harness, Node, Cordis, a particular coding-agent product, or a frontend.

Likely library responsibilities include:

typed candidate/genotype representation;
bounded mutation and crossover operators;
selection / population management;
lineage and provenance;
fitness/evidence records;
promotion, rejection, rollback and reproducibility;
benchmark/evaluator hooks;
async evaluation through existing RLM Future semantics where evaluation is latency-bearing;
cost/token/time budgets;
tracing and structured outcomes;
immutable constraints that evolution cannot weaken;
optional experience/feedback memory for mutation guidance.

Do not invent a second scheduler, authority system, effect ledger, verifier stack, or async model. Reuse existing prolog-rlm contracts.

Initial hypothesis

Start with configuration-space evolution, not model-weight evolution.

A candidate could represent a typed agent/program configuration such as:

candidate(Id,
          topology(Topology),
          roles(Roles),
          skills(Skills),
          model_policy(ModelPolicy),
          tool_policy(ToolPolicy),
          loop_policy(LoopPolicy),
          verifier_policy(VerifierPolicy),
          context_policy(ContextPolicy),
          budget(Budget)).

Lineage/evidence should be first-class data:

parent(Child, Parent).
mutation(Child, Operator, Evidence).
crossover(Child, ParentA, ParentB).
fitness(Candidate, Benchmark, Metric, Score).
rejected(Candidate, Constraint, Evidence).
promoted(Candidate, Generation, Evidence).

Exact API/schema must follow repository conventions after inspecting current code.

Research basis

Compare at minimum:

Agentic ESOpt (2026-08-18): long-horizon agent evolution strategies and trajectory-level reward: https://arxiv.org/abs/2608.17310
EvoMAS: structured multi-agent system evolution with selection, mutation/crossover, execution traces and experience memory: https://arxiv.org/abs/2602.06511
EvoAgent (2024): evolving expert agents into diverse multi-agent systems: https://arxiv.org/abs/2406.14228
EvoAgent skill-learning work (2026): structured skill/delegation evolution: https://arxiv.org/abs/2604.20133
GEPA/DSPy reflective prompt/program evolution as an adjacent optimization model.

The design should also reconcile against existing prolog-rlm runtime contracts and current AgentProlog migration work, rather than treating papers as architecture authority.

Hard invariants

Evolution must never be able to mutate away or bypass:

Frozen-Spec semantics where applicable;
host authority/capability ceilings;
durable effect identity/adoption;
cancellation;
path/project confinement;
structured schema validation;
verifier requirements;
budget ceilings;
trace/evidence requirements;
stale-preimage protections;
any other security/runtime invariants already enforced by core.

Generated candidates are data. Do not pass arbitrary generated terms to unrestricted call/1 or expose mutation as ambient code execution.

Required upstream/downstream split

`prolog-rlm`

Own reusable evolutionary primitives and RLM integration hooks.

`agentProlog`

Own the DeepSeek Harness plugin, Cordis service/event/effect lifecycle, TypeScript-to-Prolog bridge, product presets, coding-agent genotype fields, UX, and benchmark/product composition.

DeepSeek Harness is currently developer preview and warns that compatibility-breaking changes are expected, so keep the adapter narrow/versioned and prevent DeepSeek-specific types from leaking into this library.

Research questions

What is the smallest reusable public API for evolutionary search in Prolog?
Which genotype constraints are generic versus AgentProlog product schema?
Can Prolog generate only valid candidates by construction rather than generate-then-reject?
Which mutation/crossover operators are safe and useful for symbolic agent configurations?
How should evaluator hooks compose with RLM Futures, cancellation, usage, tracing and structured outcomes?
What fitness representation supports multi-objective correctness/cost/latency/robustness without collapsing everything into one magic scalar?
How should lineage and benchmark evidence persist reproducibly?
How should failed trajectories feed mutation hints without becoming trusted policy?
Which current prolog-rlm modules can be reused unchanged, and which minimal generic APIs are actually missing?
Should model-weight/parameter-space ES remain a separate optional package rather than part of the initial library?

Proposed research deliverable

Produce a design note that defines:

module/library boundary and proposed public predicates;
typed genotype/candidate abstraction;
generic versus downstream schema split;
mutation/crossover/selection contracts;
evaluator/Future interface;
immutable constraint interface;
lineage/evidence/persistence model;
multi-objective fitness representation;
benchmark protocol;
promotion/rollback rules;
cost budget;
compatibility strategy for downstream harness adapters;
explicit GO / HOLD / REJECT recommendation for a first implementation slice.

Research/design only until that gate is complete. Do as much useful research as possible per loop rather than stopping after one paper summary.

Companion to `lost-rob0t/agentProlog#2`. ## Mission Research and design a **domain-neutral evolutionary-search library in Prolog** that can be used with `prolog-rlm` and consumed by downstream harness integrations, especially the AgentProlog DeepSeek Harness plugin. This is intentionally split across two repositories: ```text DeepSeek Harness -> AgentProlog out-of-tree Cordis plugin -> thin TypeScript/Cordis <-> Prolog adapter -> reusable prolog-rlm evolution library -> existing RLM runtime/Future/authority/verification/tracing ``` The algorithmic/evolutionary machinery belongs here when it is reusable beyond AgentProlog. DeepSeek-specific lifecycle, UI, service registration, plugin packaging, and adapter glue belong downstream in `lost-rob0t/agentProlog`. ## Why a library, not product code The reusable layer should support RLM callers without depending on DeepSeek Harness, Node, Cordis, a particular coding-agent product, or a frontend. Likely library responsibilities include: - typed candidate/genotype representation; - bounded mutation and crossover operators; - selection / population management; - lineage and provenance; - fitness/evidence records; - promotion, rejection, rollback and reproducibility; - benchmark/evaluator hooks; - async evaluation through existing RLM Future semantics where evaluation is latency-bearing; - cost/token/time budgets; - tracing and structured outcomes; - immutable constraints that evolution cannot weaken; - optional experience/feedback memory for mutation guidance. Do not invent a second scheduler, authority system, effect ledger, verifier stack, or async model. Reuse existing `prolog-rlm` contracts. ## Initial hypothesis Start with **configuration-space evolution**, not model-weight evolution. A candidate could represent a typed agent/program configuration such as: ```prolog candidate(Id, topology(Topology), roles(Roles), skills(Skills), model_policy(ModelPolicy), tool_policy(ToolPolicy), loop_policy(LoopPolicy), verifier_policy(VerifierPolicy), context_policy(ContextPolicy), budget(Budget)). ``` Lineage/evidence should be first-class data: ```prolog parent(Child, Parent). mutation(Child, Operator, Evidence). crossover(Child, ParentA, ParentB). fitness(Candidate, Benchmark, Metric, Score). rejected(Candidate, Constraint, Evidence). promoted(Candidate, Generation, Evidence). ``` Exact API/schema must follow repository conventions after inspecting current code. ## Research basis Compare at minimum: - Agentic ESOpt (2026-08-18): long-horizon agent evolution strategies and trajectory-level reward: https://arxiv.org/abs/2608.17310 - EvoMAS: structured multi-agent system evolution with selection, mutation/crossover, execution traces and experience memory: https://arxiv.org/abs/2602.06511 - EvoAgent (2024): evolving expert agents into diverse multi-agent systems: https://arxiv.org/abs/2406.14228 - EvoAgent skill-learning work (2026): structured skill/delegation evolution: https://arxiv.org/abs/2604.20133 - GEPA/DSPy reflective prompt/program evolution as an adjacent optimization model. The design should also reconcile against existing `prolog-rlm` runtime contracts and current AgentProlog migration work, rather than treating papers as architecture authority. ## Hard invariants Evolution must never be able to mutate away or bypass: - Frozen-Spec semantics where applicable; - host authority/capability ceilings; - durable effect identity/adoption; - cancellation; - path/project confinement; - structured schema validation; - verifier requirements; - budget ceilings; - trace/evidence requirements; - stale-preimage protections; - any other security/runtime invariants already enforced by core. Generated candidates are data. Do not pass arbitrary generated terms to unrestricted `call/1` or expose mutation as ambient code execution. ## Required upstream/downstream split ### `prolog-rlm` Own reusable evolutionary primitives and RLM integration hooks. ### `agentProlog` Own the DeepSeek Harness plugin, Cordis service/event/effect lifecycle, TypeScript-to-Prolog bridge, product presets, coding-agent genotype fields, UX, and benchmark/product composition. DeepSeek Harness is currently developer preview and warns that compatibility-breaking changes are expected, so keep the adapter narrow/versioned and prevent DeepSeek-specific types from leaking into this library. ## Research questions 1. What is the smallest reusable public API for evolutionary search in Prolog? 2. Which genotype constraints are generic versus AgentProlog product schema? 3. Can Prolog generate only valid candidates by construction rather than generate-then-reject? 4. Which mutation/crossover operators are safe and useful for symbolic agent configurations? 5. How should evaluator hooks compose with RLM Futures, cancellation, usage, tracing and structured outcomes? 6. What fitness representation supports multi-objective correctness/cost/latency/robustness without collapsing everything into one magic scalar? 7. How should lineage and benchmark evidence persist reproducibly? 8. How should failed trajectories feed mutation hints without becoming trusted policy? 9. Which current `prolog-rlm` modules can be reused unchanged, and which minimal generic APIs are actually missing? 10. Should model-weight/parameter-space ES remain a separate optional package rather than part of the initial library? ## Proposed research deliverable Produce a design note that defines: - module/library boundary and proposed public predicates; - typed genotype/candidate abstraction; - generic versus downstream schema split; - mutation/crossover/selection contracts; - evaluator/Future interface; - immutable constraint interface; - lineage/evidence/persistence model; - multi-objective fitness representation; - benchmark protocol; - promotion/rollback rules; - cost budget; - compatibility strategy for downstream harness adapters; - explicit `GO / HOLD / REJECT` recommendation for a first implementation slice. Research/design only until that gate is complete. Do as much useful research as possible per loop rather than stopping after one paper summary.

nsaspy commented

2026-09-10 21:23:37 +00:00

Author

Owner

Duplicate of #142 (pre-existing Forgejo mirror with GitHub number parity). Closing this accidental duplicate created by today's open-state sync; #142 stays canonical on Forgejo.

nsaspy closed this issue

2026-09-10 21:23:37 +00:00