/delegate & /validate Versions

Status: v2 is live today across Router REST/MCP/x402 surfaces. v3 and v4 are roadmap stages that progressively add explicit consensus and programmable trust.

---

1. What /delegate and /validate Are For

Two core primitives:

• /delegate – Execution primitive

  • “Send this job to the network.”

  • Offloads a bounded workflow to Cortensor (models, tools, routing, retries, redundancy).

  • Returns not just final text, but structured evidence of how work was done (steps, tools, configs in v2+).

• /validate – Safety / trust primitive

  • “Before I act or pay, check this for me.”

  • Re-runs or cross-checks a claimed result under a policy.

  • v2+ returns a standard verdict contract:

    • VALID / INVALID / RETRY / NEEDS_SPEC plus reasons, evidence, and (later) consensus metadata.

Together they give agents:

• A cloud-like execution fabric to offload heavy work (/delegate).

• A neutral trust oracle to confirm results before irreversible actions (/validate).

---

2. Current Surfaces (v1 + v2)

Today, the Router exposes:

• v1 (prompt-oriented)

  • POST /api/v1/delegate

  • POST /api/v1/validate

  • Fields like task_request_input, task_result_output, task_domain, task_type, evaluation_mode.

  • Good for simple prompt → answer / prompt → judgment flows.

• v2 (contract-first, policy-aware) – current default

  • POST /api/v2/delegate – payloads shaped around:

    • objective, input, execution, policy, optional tools / workflow / metadata.

  • POST /api/v2/validate – payloads shaped around:

    • claim, policy, context, optional actor / metadata.

  • Enforces clear separation between:

    • What is being asked (objective / claim),

    • How it should run (execution),

    • Under what guarantees (policy / tier / timeouts / basic redundancy).

All four combinations (/delegate v1/v2, /validate v1/v2) are available across:

• REST, MCP, A2A / agent cards, and x402 (pay-per-call).

---

3. Router Evolution – v0 → v4

This section describes how /delegate and /validate evolve across router versions. The same primitives are reused by Corgent (infra-facing, ERC-8004-friendly) and Bardiel (Virtual-first service agent) surfaces.

v0 – Bare LLM API (Pre-Router Era)

• Single-shot /completion-style calls to a single model or session.

• No explicit distinction between:

  • execution vs validation,

  • policy vs payload.

• Any redundancy or checking is hand-rolled per app:

  • custom retries,

  • ad-hoc “LLM judge” prompts,

  • no shared contract or common verdict format.

• Works for demos and one-off tools, but not enough for an agent economy.

---

v1 – First /delegate & /validate (Prompt-Oriented)

• Introduces the two primitives as separate endpoints:

  • /delegate → “do this for me”

  • /validate → “check this for me”

• Still prompt-centric:

  • fields like task_request_input, task_result_output, with light hints (task_domain, task_type, evaluation_mode).

• Runs against a single session_id:

  • any miner redundancy is handled inside that session’s configuration.

• Useful for:

  • early Corgent / Bardiel prototypes,

  • simple “send → get answer” and “send → get judgment” flows.

v1 remains supported as the simpler legacy path.

---

v2 – Contract-First, Policy-Aware Router (Today)

This is the current default for new integrations.

Key changes vs v1:

• Structured payloads instead of free-form prompts:

  • /delegate v2:

    • objective – what the agent wants done.

    • input – data to work on (string, array, structured).

    • execution – mode, model, max steps, tool usage, timeouts.

    • policy – tier (fast, balanced, safe, oracle), latency/timeout bounds, basic redundancy, safety rules.

  • /validate v2:

    • claim – what is being asserted (summary, transaction, tool output, plan step…).

    • policy – tier, redundancy level, rules (e.g. non-hallucination, consistency).

    • context – task/app metadata that matters for the verdict.

• Verdict contract for /validate:

  • VALID, INVALID, RETRY, NEEDS_SPEC plus reasons and evidence, so agents know how to react.

• Policy & tiers become first-class:

  • tier ⇒ high-level tradeoffs:

    • fast (low latency, minimal redundancy),

    • balanced,

    • safe,

    • oracle (higher redundancy / stricter checks).

  • Timeouts and basic redundancy (especially in factcheck-style flows) move from ad-hoc to structured policy.

• Router view is still mostly single-session:

  • Clients hit a single session_id.

  • That session may internally fan out to multiple miners / models, but consensus aggregation is implicit, not an explicit router-level knob.

• Unified surfaces:

  • v2 is available consistently across:

    • REST, MCP, agent cards (A2A), and x402 (pay-before-run).

Mental model: v2 gives you execution and verification primitives with structured contracts and policy tiers, but consensus still mostly happens inside a session.

---

v3 – Explicit Redundancy & Consensus (1 / 3 / 5 Sessions)

Goal: turn redundancy + consensus into explicit, configurable knobs at the router layer across /delegate, /validate, and factcheck.

3.1 Redundant Sessions as Policy

Requests gain a consensus block, for example (shape, not final schema):

• replicas: 1 / 3 / 5

• session_pool: list of candidate session_ids (e.g. [201, 202, 203])

• aggregation: "majority" (later "weighted", "median", etc.)

• disagreement_policy: "return_all" / "fail_hard" / "best_effort"

Router behavior:

• replicas = 1 → behaves like v2 today.

• replicas = 3 or 5:

  • router fans the same logical request to 3 or 5 independent sessions, each with its own miner sample and infra slice.

  • each session runs independently (Cortensor principle: redundant, independent runs).

  • router aggregates the results and returns:

    • a final answer / verdict, and

    • per-replica evidence + agreement metrics.

Applies to:

• /delegate – redundant execution runs.

• /validate – redundant verification runs.

• factcheck – redundant world/fact checks (generalizing today’s 1/3 pattern into a standard “1/3/5 replicas” contract).

3.2 Consensus Metadata in Responses

Every v3 router response includes a consensus block, e.g.:

• replicas: how many runs were executed.

• agreement: fractional agreement (e.g. 0.67 for 2/3).

• verdicts: list of per-replica verdicts or high-level statuses.

• strategy: aggregation strategy used ("majority" initially).

• confidence: derived confidence score.

Examples:

• /delegate: “2 of 3 runs agree on this structured result.”

• /validate or factcheck: “3 of 5 runs agreed the claim is TRUE under this policy.”

Agents don’t just get “an answer” – they see how many independent runs agreed, and with what confidence.

3.3 Uniform Semantics Across Surfaces

The same consensus semantics apply across:

• REST, MCP, A2A, and x402.

Agents can tune reliability vs cost using:

• tier (fast vs balanced vs safe vs oracle),

• replicas (1 / 3 / 5),

• aggregation and disagreement_policy.

v3 tagline: “Agent-ready consensus” – explicit redundancy knobs + structured consensus metadata for /delegate, /validate, and factcheck.

---

v4 – Programmable Trust & Reusable Artifacts

If v3 turns consensus into a knob, v4 turns it into a programmable trust fabric and a pool of reusable artifacts, not just one-off responses.

4.1 Pluggable Aggregation Strategies

Beyond simple majority:

• aggregation choices like:

  • "majority", "weighted", "median_of_means", "model_ensemble".

• Optional hints such as:

  • weight_by: "reputation", "stake", "latency", "cost".

Router still hides miner-level complexity, but agents decide how consensus is formed, not just how many replicas run.

4.2 Reusable Validation / Fact Artifacts

High-value /validate or factcheck calls can emit stable validation artifacts, e.g.:

• id: unique artifact identifier (e.g. val_0xabc123...).

• kind: "validation" / "factcheck".

• scope: logical scope (e.g. trade:1234).

• ttl: suggested time-to-live.

Other agents or flows (ERC-8004, A2A, x402, on-chain actions) can then:

• reference this artifact instead of re-running full consensus,

• express policies like:

  • “Only execute this action if val_0xabc123... is VALID with confidence ≥ 0.9.”

The agentic web becomes:

• A graph of delegated calls + shared validations, not just isolated API calls.

4.3 Cost-Aware, Dynamic Redundancy

Redundancy becomes dynamic, driven by policy + observed risk:

• Low-risk paths:

  • auto-downgrade to replicas = 1 once enough similar calls have consistent validations.

• High-risk paths (payments, on-chain writes, critical financial or safety actions):

  • auto-upgrade to replicas = 5 with stricter aggregation.

  • optionally require multi-model redundancy (different backbone families must agree).

All controlled by high-level policy, not per-call plumbing.

4.4 Deep Integration with Cortensor’s Core

v4 explicitly ties consensus and artifacts into:

• Proof of Inference (PoI) and Proof of Useful Work (PoUW).

• Miner reputation / slashing signals.

• Optional on-chain anchoring of critical validations via Corgent in ERC-8004 markets.

v4 tagline: “Programmable, reusable trust” – pluggable consensus strategies, reusable validation artifacts, and dynamic redundancy driven by cost, risk, and PoI/PoUW-powered reputation.

---

4. Snapshot Summary

Use this block for high-level roadmaps:

• v0 – Bare LLM API Single-shot completions; no shared contracts; redundancy and validation hand-rolled per app.

• v1 – First /delegate & /validate Prompt-oriented, single-session endpoints; early agent flows; simple “do this / check this” semantics.

• v2 – Today: Contract-first, policy-aware router Structured payloads for /delegate and /validate, explicit verdict contract, tiers, and basic redundancy inside a session; unified across REST, MCP, A2A, x402.

• v3 – Next: Explicit consensus-aware router 1/3/5 replicas as policy; standardized consensus blocks in requests/responses; explicit redundancy knobs and consensus metadata across /delegate, /validate, and factcheck.

• v4 – Later: Programmable trust fabric Pluggable aggregation strategies, reusable validation artifacts, and dynamic redundancy tied to PoI/PoUW, reputation, and risk – making /delegate + /validate the core “intelligent delegation” layer for agents.