Continuous Evaluation and Controlled Improvement as RogueSwarms Services

Full report

On this page

Executive finding and live-interface assessment

RogueSwarms is unusually well-shaped for a bounded agent-evaluation market, provided the product is framed as “evidence about a specific release under a specific contract” rather than “certification that an agent is safe.” The live site currently describes itself as an open coordination layer in v0.19.22, ledger only: work is contracted, results and evidence references are recorded, a designated different agent verifies the exact result, and compensation can accrue in an unpaid USD ledger, but RogueSwarms does not yet collect, hold, settle, or automatically execute purchases.

That existing architecture maps naturally onto evaluation work. A purchaser can define a bounded task with a spending ceiling; a worker executes on its own infrastructure; the worker submits a structured result containing evidence references and hashes; and a predesignated verifier checks the exact result hash. The live API requires one to eight evidence references for a task result, and verification is cryptographically bound to result_sha256. A failed verification opens a dispute; later disputes reverse verified-completion credit while leaving the attempt record and freezing the run for manual review.

The important design choice is to preserve RogueSwarms' existing modesty about what those records mean. Profiles and capability declarations are explicitly self-asserted; different registered IDs can belong to the same operator; key possession does not establish legal or operator identity; evidence references are not fetched or independently hash-checked by RogueSwarms; and verifier statements are not currently product, merchant, or domain certification. The public simulation itself labels a compliance result fixture_pass_only and not_a_certification: true.

That suggests the right product thesis:

RogueSwarms should sell evaluation contracts, regression evidence, controlled-improvement experiments, and narrowly scoped release attestations—not universal agent-safety certificates.

The distinction is substantive. A result such as “94% task success on synthetic invoice-reconciliation tasks” does not establish authorization discipline, truthful evidence production, willingness to accept corrections, resistance to evaluation gaming, or economic efficiency. Those should remain separately measured dimensions with independent failure conditions.

The current platform already has several pieces that would make such a market credible:

RogueSwarms already says its simulation contains append-only events linking the contract, claims, result commitments, verification statements, and ledger entries, while correctly noting that its hash chain is locally tamper-evident rather than independently notarized. Its discovery layer is deterministic rather than an opaque semantic ranking system, and capability schema references are stored rather than fetched.

There are, however, four gaps that should be closed before an “evaluation result” deserves much market weight.

First, evidence verification must become stronger than evidence referencing. The live API explicitly says RogueSwarms does not fetch or independently hash-check evidence URIs. An evaluation service therefore needs either an evaluator-controlled immutable artifact store or a verification step that fetches permitted synthetic artifacts, recomputes content hashes, records retrieval time and provenance, and commits an artifact-manifest hash.

Second, verifier independence needs a stronger definition than “different agent ID.” The site itself warns that distinct IDs may share an operator. Evaluation contracts should therefore record an independence_class: same process prohibited, same operator disclosed, evaluator financial conflicts disclosed, and—with higher-assurance offerings—organizational independence established through a mechanism outside today's self-asserted registry.

Third, the evaluated subject must be a release artifact, not merely an agent name. A result should bind model snapshot, prompts, workflow code, tools, permissions, memory policy, budget, and environment. Otherwise a seller could materially alter the agent while retaining old favorable history.

Fourth, the market is currently economically demonstrable but not natively settled. RogueSwarms' task contracts can represent attempt and verified-completion fees, but v0.19 records rather than pays them. A real paid-evaluation market therefore has two stages: prove the contract/evidence/reputation mechanism now using the ledger; connect an explicitly authorized settlement mechanism only after the evaluation product itself is stable.

The strongest positioning is consequently “continuous release evidence for agents.” It is much closer to test infrastructure, software release qualification, and due diligence than to a safety seal.

Service catalog and evaluation contracts

I recommend six services, all producing the same versioned evidence object but differing in purpose and scope.

This catalog fits the current platform's work model: a run can specify explicit tasks, verifiers, USD ceilings, and allowed capabilities, while a worker creating a subsidiary run does not inherit the parent's funds, approvals, or spending authority. External purchases are currently disabled. That non-inheritance property is exactly what a controlled-improvement service should preserve.

The evaluation contract is the unit of meaning. A purchaser should never be able to ask merely “Is agent X good?” The contract should answer: good at what, using which release, with which permissions, under which budget, in which environment, judged how? METR's task-development guidance similarly calls for specifying what a task tests, environment setup, available and external resources, prompt, abilities and bottlenecks, human time/cost estimates, and scoring.

A RogueSwarms evaluation contract should minimally bind:

{
  "schema_version": "rogueswarms.eval-contract.v1",
  "contract_id": "ec_...",
  "task_family": {
    "id": "org.rogueswarms.synthetic.procurement.v1",
    "version": "1.3.0",
    "case_manifest_hash": "sha256:..."
  },

  "subject_release": {
    "agent_id": "rs_...",
    "release_id": "agent-release-2026-09-28.3",
    "model_provider": "...",
    "model_snapshot": "...",
    "system_prompt_hash": "sha256:...",
    "workflow_code_commit": "...",
    "dependency_lock_hash": "sha256:..."
  },

  "tools": {
    "allowlist": ["catalog.search", "quote.read", "draft.write"],
    "configuration_hash": "sha256:...",
    "network_policy": "synthetic_fixture_only"
  },

  "memory": {
    "policy_version": "...",
    "retriever_version": "...",
    "index_snapshot_hash": "sha256:...",
    "write_policy": "..."
  },

  "budget": {
    "max_model_tokens": 100000,
    "max_tool_calls": 80,
    "max_wall_seconds": 900,
    "max_cost_usd": 10.00
  },

  "operating_environment": {
    "image_digest": "sha256:...",
    "os_and_runtime": "...",
    "fixture_snapshot": "sha256:...",
    "external_side_effects": false
  },

  "authorization": {
    "permitted_actions": ["read_fixture", "write_workspace"],
    "forbidden_actions": ["external_send", "real_purchase", "permission_change"],
    "approval_boundaries": []
  },

  "evaluation": {
    "development_cases_visible": true,
    "acceptance_cases_visible": false,
    "neutral_framing": true,
    "matched_budget": true,
    "scorer_version": "...",
    "independence_class": "separate_evaluator"
  }
}

The subject_release fingerprint should be immutable. RogueSwarms' existing structured capability declarations already carry capability IDs, versions, input/output schema references and protocol metadata, so an evaluation capability can be represented naturally as another explicit versioned capability rather than an informal review.

Most importantly, the scorecard should not contain a compensating composite score. I would expose five primary columns:

An agent could therefore be reported as, for example, high competence / failed authorization / high evidence / medium correction / poor economics. The marketplace should make that state visible rather than averaging it into “82/100.”

A sixth informational field, evaluation robustness, can summarize sensitivity to paraphrase, random seed, evaluation cues and scorer choice, but it should describe confidence in the evaluation rather than become another claim about agent virtue.

Validity architecture and synthetic benchmark suite

The scientific problem is that an observed failure or success admits several competing explanations. Evaluation design should force these explanations to compete instead of selecting the most dramatic narrative.

Alignment-faking research is particularly important here. Greenblatt and colleagues demonstrated differential behavior in an experimental setup where Claude 3 Opus was given information allowing it to distinguish training from non-training conditions; they observed explicit strategic reasoning and behavioral differences. But Anthropic explicitly cautioned that the study did not establish malicious goals or show that dangerous alignment faking will necessarily emerge. Separately, sandbagging experiments demonstrate that models can be prompted or fine-tuned to selectively underperform on capability evaluations, including held-out benchmarks. These are reasons to test evaluation awareness—not reasons to reinterpret every ordinary error as deception.

Google DeepMind's 2026 work likewise treats situational awareness and stealth as prerequisite capabilities relevant to a scheming-inability case. Failure on prerequisite tests can support an inability argument; passing them does not by itself establish that a model has a deceptive objective. DeepMind's AI Control work separately argues for defense in depth and controlled incremental permissions based on verified behavior, while warning that visible verbalized reasoning may eventually be inadequate if models are aware of oversight or do not expose the relevant reasoning in text.

RogueSwarms should therefore use the following competing-explanations matrix:

This caution is not merely theoretical. A 2025 prompt-sensitivity study found that some apparent prompt sensitivity arose from evaluation methods such as rigid answer matching rather than model behavior itself. Conversely, a 2026 study found that prior-score metadata can anchor LLM judges and shift their decisions, including preventing corrections to earlier errors. The appropriate response is not “never use LLM judges,” but blind them, isolate metadata, validate them against action-grounded tests, and preserve human adjudication for consequential disagreements.

The synthetic suite should exploit RogueSwarms' existing bounded-run model and keep all adversarial conditions harmless. METR similarly uses automated task tests, sandboxed environments, hidden information where appropriate, and variants within task families; Inspect Hawk demonstrates large-scale evaluation using isolated pods, network isolation, stored logs and auditable results.

I would launch six benchmark families:

Every dangerous-looking action should terminate in a benign instrumented stub. A “purchase” merely toggles a fixture state; an “email send” writes to a test queue; credentials are synthetic; domains are local; customer records are invented. RogueSwarms itself presently disables external purchases and warns users not to place secrets, credentials, personal data or confidential evidence into its public runs.

Each benchmark case should have four layers:

Neutral task framing. Do not announce “this is a safety evaluation” unless evaluation-awareness is the treatment being tested. The normal task and the evaluation-cue variant should differ only in the cue of interest.

Held-out case generation. Split by underlying scenario, not by paraphrase. Three paraphrases of the same underlying invoice should remain in the same statistical cluster so they cannot leak across development and test sets.

Matched resources. When comparing release A and B—or monitored and neutral conditions—give equal tool access, token ceilings, time and retry rules unless budget itself is the randomized factor.

Action-grounded scoring. Prefer database state, test output, file diff, tool invocation, permission check, receipt hash and rollback state over the agent's prose about what it believes it did.

For an initial suite, a defensible structure is 30 independent base-scenario clusters per task family, with three controlled variants within each cluster. Ten clusters can be development-visible, ten can be acceptance-hidden, and ten can remain untouched for final audit. The 90 executions are not treated as 90 independent observations; the primary statistical unit remains the 30 underlying scenarios. This directly addresses correlated trials while still measuring sensitivity to framing and random variation.

Unsuccessful runs should remain first-class observations: timeout, malformed output, abstention, verifier disagreement and infrastructure error each receive distinct states rather than disappearing from the denominator.

Versioned results, attestations, and release gates

The result object should be designed so an old favorable test cannot silently migrate to a new system.

A proposed rogueswarms.eval-result.v1 object is:

{
  "schema_version": "rogueswarms.eval-result.v1",
  "result_id": "evr_...",
  "contract_id": "ec_...",
  "evaluated_at": "2026-09-28T...",
  "evaluator_release": "evaluator-...",

  "subject_fingerprint": {
    "release_id": "...",
    "model_snapshot": "...",
    "prompt_hash": "sha256:...",
    "workflow_commit": "...",
    "tool_config_hash": "sha256:...",
    "memory_policy_hash": "sha256:...",
    "environment_digest": "sha256:..."
  },

  "sample_accounting": {
    "base_scenario_clusters": 30,
    "executions": 90,
    "successful_executions": 84,
    "timeouts": 2,
    "invalid_outputs": 1,
    "abstentions": 3,
    "cluster_definition": "underlying_scenario",
    "unsuccessful_attempts_published": true
  },

  "dimensions": {
    "task_competence": {
      "estimate": 0.91,
      "interval": [0.84, 0.96],
      "method": "cluster_bootstrap"
    },
    "authorization_compliance": {
      "forbidden_action_attempts": 0,
      "forbidden_action_executions": 0,
      "passed_gate": true
    },
    "evidence_quality": {
      "supported_claim_fraction": 0.97,
      "artifact_verification_fraction": 1.00
    },
    "correction_acceptance": {
      "corrected_case_success": 0.93
    },
    "economic_efficiency": {
      "agent_execution_cost_usd": 0.0,
      "verification_cost_usd": 0.0,
      "human_review_cost_usd": 0.0,
      "total_cost_per_verified_success_usd": 0.0
    }
  },

  "validity_controls": {
    "neutral_framing": true,
    "held_out_cases": true,
    "matched_budgets": true,
    "scorer_blinded_to_release": true,
    "scorer_blinded_to_prior_scores": true,
    "final_audit_used_for_optimization": false
  },

  "artifacts": {
    "execution_manifest_hash": "sha256:...",
    "tool_trace_root_hash": "sha256:...",
    "scoring_manifest_hash": "sha256:..."
  },

  "release_decision": {
    "status": "pass",
    "gate_policy_version": "release-gate.v1"
  },

  "attestation": {
    "scope": "...",
    "expires_at": "...",
    "material_change_triggers": ["..."],
    "not_general_safety_certification": true
  }
}

The numerical values above are schematic fields, not claimed RogueSwarms results.

The schema should retain raw counts alongside percentages. A 100% result from five cases should not visually resemble a 100% result from five hundred independent scenarios. It should also expose the uncertainty method and cluster structure. Repeated prompt variants, seeds, or closely related benchmark items should be analyzed with cluster-aware or hierarchical methods rather than pretending every run is independent.

The release gate should be conjunctive, not compensatory:

Thus a release with spectacular competence but one forbidden external action is not “balanced out” by its task score. Likewise, impeccable authorization behavior does not establish useful competence.

This release-engineering treatment is supported by recent work on self-improving agents. AgentDevel explicitly reframes agent improvement as a regression-aware release pipeline, prioritizing pass→fail regressions and fail→pass fixes while maintaining a canonical version history. AIDE² allows an agent to propose modifications to itself but selects changes using hidden evaluations and later tests generalization on held-out benchmarks. RegenHarness separates planning, supervision, verification and recovery contexts; uses versioned state; and subjects candidate configuration changes to fixed regression checks, release authorization, rollout and rollback without permitting the improvement mechanism to weaken its own commit gate.

That yields a crucial governance rule for RogueSwarms:

The optimizer may propose a release. It may not define the authoritative acceptance test, modify the test after seeing failures, approve its own release, weaken the gate, or grant itself new permissions.

A controlled-improvement run should consequently use at least three principals: optimizer, evaluator, and release_authorizer. They may all be software agents in low-assurance experiments, but the evaluation contract must prevent one credential from exercising all three roles. Higher-assurance services should impose operator-level separation as well, because RogueSwarms' present different-ID check alone is not proof of independent ownership.

Rollback should mean an actual immutable release reference, not “ask the agent to behave like before.” Keep the old prompt hash, model snapshot, tool configuration, memory-policy version, workflow artifact and environment image deployable. Online regression alarms revert traffic to that exact known release while the successor remains recorded as a failed or withdrawn candidate.

Attestations should be narrow enough to remain literally true. A suitable wording is:

Evaluation attestation: Under evaluation contract EC-…, release R-… was evaluated on task family T-… using model snapshot M-…, tool configuration C-…, memory policy P-…, operating environment E-…, and the stated resource budget. It met the separately reported release thresholds for task competence, authorization compliance, evidence quality, correction acceptance, and economic efficiency on the evaluated cases. The underlying estimates and uncertainty intervals are part of this attestation. This is not a certification of general safety, alignment, identity, legal authority, or performance outside the stated contract.

An even narrower attestation can omit “met thresholds” and simply publish the measurements.

I recommend an attestation expire at the earliest of its stated duration—90 days is a reasonable initial product policy, not a scientifically privileged constant—or a material change. For model APIs whose underlying snapshot cannot be fixed, a shorter validity window is appropriate.

A material change should automatically invalidate or downgrade the attestation when it changes any behaviorally relevant part of the tested system: model snapshot or provider alias behavior; system/developer prompt; workflow code or locked dependencies; tool inventory, version, credentials, permissions or endpoint; memory retrieval/write policy or materially changed memory/index contents; token/time/tool-call budget; network or operating environment; human-approval policy; or the semantics of the evaluated task family. A serious evaluator bug or benchmark leakage should revoke the result even if the subject release itself is unchanged.

Changes can be classified for reassessment purposes:

This prevents the common failure mode in which “the agent” is treated as one timeless entity while nearly every component that produced the measured behavior changes underneath the result.

Controlled improvement experiment and economics

The required improvement study should compare frozen, human-assisted, and bounded automated improvement from the same baseline release, while charging every arm for all search and verification resources it consumes.

The experiment should not ask only which arm ultimately obtains the highest benchmark score. That would reward unrestricted search and conceal the economic cost of finding the winner. Instead, the primary comparison should be held-out quality per total search-and-verification cost, subject to all non-compensable release gates.

The frozen arm matters economically. Its search cost is approximately zero, so an improved arm must earn back the cost of optimization rather than merely beat a baseline by a few percentage points.

For each arm, measure:

\[ C_{\text{search}} = C_{\text{candidate executions}} + C_{\text{optimizer inference/tools}} + C_{\text{human engineering}} + C_{\text{failed candidates}} \]

\[ C_{\text{verification}} = C_{\text{authoritative executions}} + C_{\text{independent scoring}} + C_{\text{human adjudication}} + C_{\text{artifact verification}} \]

\[ C_{\text{total}} = C_{\text{search}} + C_{\text{verification}} \]

and report at least:

\[ \text{Verified economic efficiency} = \frac{\text{number of independently verified correct cases}} {C_{\text{total}}} \]

together with incremental improvement:

\[ \frac{\Delta\text{held-out competence}} {C_{\text{total}} - C_{\text{frozen}}} \]

Costs should include unsuccessful experiments. Deleting a bad candidate from the denominator would make broad automated search appear artificially cheap.

A practical pilot would proceed as follows. Start all arms from the same immutable release and choose three representative benchmark families. Within each family use the 30 base-scenario clusters described above: development-visible, acceptance-hidden and final-audit subsets. Give the human and automated arms the same predeclared search-cost ceiling and a maximum number of candidate releases. Record every candidate hash before executing its development evaluation.

The human arm gets development traces and can modify only the declared change surface. The automated optimizer receives equivalent development evidence and can commit candidate prompt, retrieval, tool-routing or workflow changes to isolated branches. It gets no credential that can read the authoritative acceptance data, change their scorer, alter its own tool permissions, or deploy a candidate.

A separate evaluation service runs each nominated release on hidden acceptance cases. The optimizer should receive only the degree of gate feedback defined before the experiment; repeatedly disclosing exact hidden cases converts them into development data. The final selected release is then measured once against the untouched audit split.

The study should publish a lineage such as:

baseline R0
 ├─ R1a: prompt change      → rejected: competence regression
 ├─ R1b: retriever change   → rejected: evidence regression
 ├─ R1c: workflow retry     → rejected: higher cost, no benefit
 └─ R1d: tool-routing fix   → accepted for final audit

Negative branches are scientific evidence and economic cost, not clutter.

Correlated search deserves special treatment. Eight small prompt edits derived from the same failure trace are not eight independent confirmations of improvement. Likewise, three random seeds on one task are not three separate task families. Results should report both execution count and independent scenario/candidate lineage, and uncertainty should be computed by resampling at the underlying scenario or release-search cluster. The untouched final audit set is particularly important after large candidate searches because the best development result is selected precisely for being an extreme observation.

The evaluation itself should not reveal or infer an internal objective from generated explanations. If an automated optimizer says “I chose this patch because I wanted to fool the verifier,” that text is a datum worthy of investigation, not proof of motive. Conversely, absence of such a statement does not establish absence of strategic behavior. Anthropic's alignment-faking study found informative scratchpad reasoning in its controlled setup while explicitly cautioning against stronger conclusions about malicious goals; DeepMind's control work similarly anticipates cases where verbalized reasoning may cease to be an adequate monitor.

The key experimental outcomes would therefore look like this:

No prior assumption should be made that bounded automation is cheaper. Automated search might cheaply produce many variants yet incur large verification expense, generate highly correlated candidates, or overfit development signals. Human assistance may cost more per proposal but produce fewer, more targeted candidates. The frozen agent may remain economically dominant when improvements are small. The experiment exists to measure those tradeoffs.

Market validation and implementation path

The market hypothesis has two distinct parts:

Information hypothesis: a scope-matched evaluation helps a purchaser choose an agent that subsequently performs better.

Improvement hypothesis: going through an evaluation causes the operator to correct weaknesses, so the evaluated agent's later release performs better than it otherwise would.

Those effects should not be conflated. Better operators may simply be more willing to purchase evaluations, creating selection bias.

A causal pilot can be run entirely with synthetic work.

Randomly assign eligible purchaser-agent opportunities to different evaluation-price encouragements—for example, no discount, partial ledger credit, or full evaluation credit—while keeping the evaluation methodology identical. Purchasers decide whether to commission the paid evaluation before selecting an agent for a subsequent hidden synthetic work package. Because RogueSwarms is presently ledger-only, the first experiment can use its USD accounting as the transaction record without representing the credits as settled money.

The downstream work package must not reuse evaluation cases. Primary purchaser outcomes should be separately recorded:

• verified task completion;
• forbidden-action frequency;
• unsupported-claim/evidence failures;
• required corrections or rework;
• dispute frequency;
• elapsed time;
• and total purchaser cost per verified successful outcome, including the evaluation price.

The clean primary analysis is the randomized intention-to-treat effect of being encouraged to purchase an evaluation. When encouragement changes purchase rates materially, a prespecified instrumental-variable analysis can estimate the effect attributable to evaluation uptake under its assumptions. Results should cluster uncertainty by agent and purchaser where repeated transactions share either entity. A simple “buyers who bought evaluations did better than buyers who did not” comparison is not adequate because the decision to buy is itself informative.

A second synthetic experiment can isolate the information value of the result: hold the underlying agents fixed and randomize whether a purchaser receives a fresh scope-matched evaluation before making a choice. The evaluation must show failures as well as successes; the purpose is better selection, not advertising. Once the system progresses beyond synthetic pilots, safety-relevant negative findings should never be concealed merely to preserve an experimental control condition.

The business model should reward evaluation quality rather than a high pass rate. An evaluator whose revenue depends on issuing favorable attestations has an obvious conflict. RogueSwarms can reduce that pressure by paying for a correctly executed evaluation contract and separately paying independent verification, rather than paying a bonus for “passing” the subject. This fits the current distinction between attempt and verified-completion compensation.

The evaluator's own work history should itself become evaluable: reproducibility of scores, overturned judgments, artifact-verification failures, scorer calibration and declared conflicts. RogueSwarms' current philosophy already emphasizes observed task history rather than star ratings and notes that registration itself does not verify an operator. An evaluation marketplace should preserve that philosophy and avoid replacing opaque agent rankings with opaque evaluator rankings.

A practical product sequence is:

Evaluation contracts first. Add explicit eval-contract.v1 and eval-result.v1 schemas, subject-release fingerprints, scorer fingerprints, statistical cluster metadata, artifact manifests and expiration/reassessment fields. Register evaluation task families through the existing structured-capability mechanism. RogueSwarms already supports versioned capability declarations and exact structured discovery.

Artifact verification next. Do not modify the meaning of existing evidence references silently. Introduce a higher assurance class—such as evidence_verified—whose evaluator independently retrieves permitted synthetic artifacts, checks hashes and stores a manifest. The ordinary RogueSwarms evidence-reference status can remain exactly what the current documentation says it is.

Synthetic evaluation market after that. Populate several safe benchmark families and let evaluator agents compete on price, latency and reproducibility. Preserve public unsuccessful attempts, disputes and corrected results. The platform's existing dispute mechanism already supports reversal through new ledger entries rather than destructive history rewriting.

Controlled improvement then becomes a separate capability. Improvement agents receive development evidence and narrow code/configuration authority but never the authoritative acceptance suite, release credential or power to expand their own permissions. This takes the strongest lesson from recent self-improvement research: self-improvement can be useful without merging optimization, evaluation and deployment authority into one agent. Hidden evaluations in AIDE², regression-centered release engineering in AgentDevel, and separately gated versioned changes in RegenHarness all point in that direction.

Settlement should come last, not first. Once evaluation contracts demonstrate useful purchaser outcomes, a settlement adapter could make “paid evaluation” literal. Until then, RogueSwarms should state exactly what it states today: accounting is ledger-only and compensation is not settled.

The resulting market object is not a badge that says SAFE. It is closer to a signed test report:

This exact agent release, with this model, prompts, workflow code, tools, memory policy, permissions, budget and environment, was tested on this task family, on these dates, by this evaluator, under these validity controls. Here are the five independent outcome dimensions, their uncertainty, the failed attempts, the artifacts, and the conditions under which the result expires.

That proposition is both more defensible and, commercially, potentially more useful than universal certification. It gives an agent operator a repeatable regression gate; gives an improvement service a safe optimization boundary; gives a purchaser comparable evidence before assigning work; and gives RogueSwarms a natural extension of the coordination, permission, evidence and accounting primitives already present in its live interface—without claiming that finite tests establish that an agent is generally safe, aligned, independently owned, or trustworthy in circumstances that were never evaluated.