[RESEARCH/IDEA] DeepSeek Harness evolutionary plugin backed by Prolog-RLM library #2

Open
opened 2026-08-21 04:46:41 +00:00 by lost-rob0t · 0 comments
lost-rob0t commented 2026-08-21 04:46:41 +00:00 (Migrated from github.com)

Companion upstream library issue: lost-rob0t/prolog-rlm#142.

Mission

Research and design the AgentProlog product side of evolutionary agent search as an out-of-tree DeepSeek Harness plugin with thin glue into a reusable Prolog-RLM evolutionary-search library.

The required split is:

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

Do not implement the evolutionary algorithm twice. The reusable engine belongs upstream in prolog-rlm; this repository owns DeepSeek/product integration.

Why DeepSeek Harness plugin

Current DeepSeek Harness architecture is explicitly plugin-based: Cordis plugins contribute services, typed events, and reversible effects to a shared context, profiles may install out-of-tree plugins, and product behavior should be extended by mounting plugins rather than patching a privileged core.

DeepSeek Harness is also in developer preview and warns of compatibility-breaking changes. Therefore keep this adapter narrow, versioned, and replaceable. Do not leak DeepSeek/Cordis-specific types into the upstream Prolog evolutionary library.

Research sources:

Downstream responsibilities

AgentProlog should own:

  • out-of-tree DeepSeek Harness/Cordis plugin packaging;
  • plugin lifecycle and dependency injection;
  • TypeScript/Cordis-to-Prolog transport/adapter;
  • mapping Harness sessions/jobs/events into reusable Prolog library calls;
  • cancellation/error/timeout mapping;
  • product-specific genotype fields for coding agents;
  • DeepSeek model/provider routing presets where useful;
  • UI/inspection surfaces for population, lineage, fitness and promotions;
  • product benchmark composition;
  • safe operator commands to start/stop/inspect an evolutionary experiment;
  • compatibility tests against the supported DeepSeek Harness version.

The plugin must not own generic mutation/crossover/selection, lineage semantics, generic fitness/evidence records, RLM authority, durable effects, verifier semantics, or a second scheduler.

Upstream responsibilities

lost-rob0t/prolog-rlm#142 owns the reusable domain-neutral evolutionary library:

  • typed candidate/genotype abstraction;
  • bounded mutation/crossover/selection;
  • lineage/provenance;
  • fitness/evidence;
  • promotion/rejection/rollback;
  • evaluator/Future hooks;
  • budgets/tracing/structured outcomes;
  • immutable constraint interface;
  • optional feedback/experience memory.

Initial product hypothesis

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

Candidate dimensions worth researching:

  • agent topology/delegation graph;
  • roles/system prompts;
  • skill selection and trigger metadata;
  • model routing by role/cost/latency;
  • tool availability/policy within fixed upstream authority ceilings;
  • Spec/Plan/Execute/Verify loop parameters;
  • verifier composition;
  • context selection/retrieval policy;
  • concurrency and budget allocation.

The plugin supplies/validates the AgentProlog-specific genotype schema, then delegates generic evolutionary mechanics to the upstream Prolog library.

Research basis

Compare at minimum:

Hard boundaries

  • Do not patch/fork DeepSeek Harness core when an out-of-tree plugin suffices.
  • Do not duplicate prolog-rlm#142 algorithms in TypeScript.
  • Do not evolve away Frozen-Spec, authority, durable-effect, path-confinement, cancellation, verifier or budget invariants.
  • Plugin loading grants no authority by itself.
  • Generated candidates are data, not arbitrary executable Prolog/JS.
  • No ambient unrestricted shell/call bridge.
  • Preserve dependency direction: agentProlog -> prolog-rlm; never the reverse.
  • Reuse existing AgentProlog/Prolog-RLM work before inventing parallel infrastructure.

Research questions

  1. Which DeepSeek Harness service is the narrowest stable integration point for launching/observing candidate agent runs?
  2. Should the Prolog process be embedded, persistent sidecar, or protocol service, given cancellation/reconnect and Nix packaging constraints?
  3. What is the minimum transport schema between Cordis and Prolog?
  4. How should Harness plugin unload/reload map to Prolog experiment lifecycle and Futures?
  5. How should candidate executions expose cost, latency, tokens, verification evidence and failures back to the upstream fitness layer?
  6. Which genotype fields are truly AgentProlog-specific and therefore belong only here?
  7. How can headless operation remain first-class without coupling evolution to web UI plugins?
  8. What compatibility/conformance matrix is required while DeepSeek Harness remains developer preview?

Proposed research deliverable

Produce an AgentProlog design note that pairs with prolog-rlm#142 and defines:

  • plugin package/bundle/profile integration;
  • Cordis services/events/effects used;
  • Prolog bridge protocol;
  • lifecycle/cancellation/error mapping;
  • product genotype schema;
  • benchmark runner composition;
  • inspection/UI hooks without making UI authoritative;
  • Nix packaging/dependency path;
  • compatibility tests;
  • explicit GO / HOLD / REJECT recommendation.

Research/design only until the paired upstream/downstream gate is complete. Do as much useful research as possible per loop; do not stop at one paper or one Harness API.

Companion upstream library issue: `lost-rob0t/prolog-rlm#142`. ## Mission Research and design the **AgentProlog product side** of evolutionary agent search as an **out-of-tree DeepSeek Harness plugin** with thin glue into a reusable Prolog-RLM evolutionary-search library. The required split is: ```text DeepSeek Harness -> AgentProlog out-of-tree Cordis plugin -> thin TypeScript/Cordis <-> Prolog bridge -> prolog-rlm reusable evolution library (#142) -> existing RLM runtime/Future/authority/verification/tracing ``` Do not implement the evolutionary algorithm twice. The reusable engine belongs upstream in `prolog-rlm`; this repository owns DeepSeek/product integration. ## Why DeepSeek Harness plugin Current DeepSeek Harness architecture is explicitly plugin-based: Cordis plugins contribute services, typed events, and reversible effects to a shared context, profiles may install out-of-tree plugins, and product behavior should be extended by mounting plugins rather than patching a privileged core. DeepSeek Harness is also in developer preview and warns of compatibility-breaking changes. Therefore keep this adapter narrow, versioned, and replaceable. Do not leak DeepSeek/Cordis-specific types into the upstream Prolog evolutionary library. Research sources: - DeepSeek Harness architecture: https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/architecture.md - DeepSeek Harness repo: https://github.com/deepseek-ai/deepseek-harness - client plugin loading model: https://github.com/deepseek-ai/deepseek-harness/blob/master/.agents/notes/implemented/architecture/2026-07-23-client-plugin-loading-model.md ## Downstream responsibilities AgentProlog should own: - out-of-tree DeepSeek Harness/Cordis plugin packaging; - plugin lifecycle and dependency injection; - TypeScript/Cordis-to-Prolog transport/adapter; - mapping Harness sessions/jobs/events into reusable Prolog library calls; - cancellation/error/timeout mapping; - product-specific genotype fields for coding agents; - DeepSeek model/provider routing presets where useful; - UI/inspection surfaces for population, lineage, fitness and promotions; - product benchmark composition; - safe operator commands to start/stop/inspect an evolutionary experiment; - compatibility tests against the supported DeepSeek Harness version. The plugin must **not** own generic mutation/crossover/selection, lineage semantics, generic fitness/evidence records, RLM authority, durable effects, verifier semantics, or a second scheduler. ## Upstream responsibilities `lost-rob0t/prolog-rlm#142` owns the reusable domain-neutral evolutionary library: - typed candidate/genotype abstraction; - bounded mutation/crossover/selection; - lineage/provenance; - fitness/evidence; - promotion/rejection/rollback; - evaluator/Future hooks; - budgets/tracing/structured outcomes; - immutable constraint interface; - optional feedback/experience memory. ## Initial product hypothesis Start with **configuration-space evolution**, not weight-space evolution. Candidate dimensions worth researching: - agent topology/delegation graph; - roles/system prompts; - skill selection and trigger metadata; - model routing by role/cost/latency; - tool availability/policy within fixed upstream authority ceilings; - Spec/Plan/Execute/Verify loop parameters; - verifier composition; - context selection/retrieval policy; - concurrency and budget allocation. The plugin supplies/validates the AgentProlog-specific genotype schema, then delegates generic evolutionary mechanics to the upstream Prolog library. ## Research basis Compare at minimum: - Agentic ESOpt: https://arxiv.org/abs/2608.17310 - EvoMAS: https://arxiv.org/abs/2602.06511 - EvoAgent (2024): https://arxiv.org/abs/2406.14228 - EvoAgent structured skill/delegation work: https://arxiv.org/abs/2604.20133 - GEPA/DSPy reflective program optimization - current DeepSeek Harness Cordis plugin/service/event/effect conventions ## Hard boundaries - Do not patch/fork DeepSeek Harness core when an out-of-tree plugin suffices. - Do not duplicate `prolog-rlm#142` algorithms in TypeScript. - Do not evolve away Frozen-Spec, authority, durable-effect, path-confinement, cancellation, verifier or budget invariants. - Plugin loading grants no authority by itself. - Generated candidates are data, not arbitrary executable Prolog/JS. - No ambient unrestricted shell/call bridge. - Preserve dependency direction: `agentProlog -> prolog-rlm`; never the reverse. - Reuse existing AgentProlog/Prolog-RLM work before inventing parallel infrastructure. ## Research questions 1. Which DeepSeek Harness service is the narrowest stable integration point for launching/observing candidate agent runs? 2. Should the Prolog process be embedded, persistent sidecar, or protocol service, given cancellation/reconnect and Nix packaging constraints? 3. What is the minimum transport schema between Cordis and Prolog? 4. How should Harness plugin unload/reload map to Prolog experiment lifecycle and Futures? 5. How should candidate executions expose cost, latency, tokens, verification evidence and failures back to the upstream fitness layer? 6. Which genotype fields are truly AgentProlog-specific and therefore belong only here? 7. How can headless operation remain first-class without coupling evolution to web UI plugins? 8. What compatibility/conformance matrix is required while DeepSeek Harness remains developer preview? ## Proposed research deliverable Produce an AgentProlog design note that pairs with `prolog-rlm#142` and defines: - plugin package/bundle/profile integration; - Cordis services/events/effects used; - Prolog bridge protocol; - lifecycle/cancellation/error mapping; - product genotype schema; - benchmark runner composition; - inspection/UI hooks without making UI authoritative; - Nix packaging/dependency path; - compatibility tests; - explicit `GO / HOLD / REJECT` recommendation. Research/design only until the paired upstream/downstream gate is complete. Do as much useful research as possible per loop; do not stop at one paper or one Harness API.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nsaspy/agentProlog#2
No description provided.