Delegate & Validate – Core Primitives for Agent-Scale & Safety

Status: Draft – API shapes and policies may evolve as Corgent, Bardiel, and the Cortensor router advance.

Corgent and Bardiel both expose the same two core primitives:

• /delegate – Execution primitive “Send this job to the Cortensor network under a specific policy.”

• /validate – Safety / trust primitive “Check this result under a specific policy before I act or pay.”

These endpoints are how agents, protocols, and applications plug into Cortensor’s decentralized AI fabric without hand-rolling routing, retries, or verification logic.

They are:

• The primary surface for Corgent (Cortensor’s infra-native agent for ERC-8004 and agent ecosystems).

• The trust + execution backbone for Bardiel (Virtual-native service agent that runs on Cortensor and can also operate in ERC-8004).

---

1. High-Level Concept

1.1 What /delegate Does (Execution Primitive)

/delegate is “send this job to the network”:

• You describe what you want done and how it should be run (policy).

• Cortensor routes the task across miners under those constraints.

• You get back results + evidence, not just a string.

Two generations are supported:

• /delegate v1

  • Simple prompt → single completion.

  • Uses legacy fields like task_request_input for compatibility.

• /delegate v2

  • Lets agents offload small, bounded workflows with:

    • tools

    • max-step limits

    • timeouts & policies

  • Returns structured evidence (steps taken, tools used, configs) so upstream agents can reason about how work was performed, not just what the answer is.

Mental model: /delegate turns Cortensor into the “execution fabric” for agents – like EC2 + Lambda + a router, exposed as a single contract.

---

1.2 What /validate Does (Safety Primitive)

/validate is the checkpoint before an agent takes an irreversible step:

• You send what was asked, what was produced, and how you want it judged.

• Cortensor re-runs or cross-checks work on the network.

• You get a stable verdict and supporting evidence.

Two generations are supported:

• /validate v1

  • LLM-style “check this” with free-form output.

  • Uses task_request_input / task_result_output + basic criteria.

• /validate v2

  • Standard verdict contract:

    • VALID / INVALID / RETRY / NEEDS_SPEC

  • Structured payload focused on:

    • the claim being judged

    • the context around it

    • the policy (tier, redundancy, rules)

  • Can run redundant checks and aggregate them into a single verdict the calling agent can trust.

Mental model: /validate is the “are we sure?” API – the neutral trust oracle agents can consult before acting, paying, or committing.

---

1.3 Why These Two Matter for an Agent Economy

Without these primitives:

• Without /delegate Every agent builder ends up babysitting:

  • GPUs / infra

  • retries / fallbacks

  • custom routing & tool orchestration

• Without /validate There is no shared, neutral checkpoint to say: “This result is safe enough to act or pay on.”

Together, they give agents:

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

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

This v2 surface is what Corgent and Bardiel lean on for:

• REST

• MCP

• ERC-8004 / A2A

• x402 (pay-per-call) flows

v1 remains as a simpler, legacy-compatible path.

---

2. Endpoint Matrix (Router / Corgent / Bardiel)

At the router level (and via Corgent/Bardiel), endpoints are exposed with:

• v1 vs v2 payloads

• normal, trial, and x402 (payment-gated) variants

2.1 REST Endpoint Matrix

Flow	Normal	Trial	x402
Delegate v1	/api/v1/delegate	/api/v1/trial/delegate	/api/v1/x402/delegate
Validate v1	/api/v1/validate	/api/v1/trial/validate	/api/v1/x402/validate
Delegate v2	/api/v2/delegate	/api/v2/trial/delegate	/api/v2/x402/delegate
Validate v2	/api/v2/validate	/api/v2/trial/validate	/api/v2/x402/validate

2.2 Usage Modes

• Normal – Standard authenticated calls, suitable for long-lived apps & agents.

• Trial – Rate-limited evaluation path for onboarding, demos, and quick tests.

• x402 – Payment-gated variant:

  • First call returns HTTP 402 with payment terms.

  • Client pays (e.g., Base Sepolia USDC) and retries with proof header (X-PAYMENT).

  • Intended for production pay-per-call flows.

---

3. Payload Shapes – v1 vs v2

3.1 /delegate v1 – Prompt-Oriented

Use when:

• You want a simple completion.

• You’re migrating existing systems that already speak the legacy format.

Example (POST /api/v1/delegate):

{
  "session_id": 110,
  "task_request_input": "Create incident communication draft for MCP downtime.",
  "task_domain": "ops",
  "task_type": "communication",
  "evaluation_mode": "high_reliability",
  "web_url": "https://status.example.com"
}

Key fields (v1):

• session_id – which Cortensor session (budget + routing config) to use.

• task_request_input – the main user/agent prompt.

• Optional domain/type hints (task_domain, task_type) to guide routing.

• Optional mode (evaluation_mode) and context (e.g., URLs).

---

3.2 /delegate v2 – Workflow-Oriented

Use when:

• You want structured workflows, not just single prompts.

• You need tools, step limits, explicit policies (latency, cost, safety).

Example (POST /api/v2/delegate):

{
  "session_id": 205,
  "objective": "Use tools to evaluate candidate responses and choose the best one.",
  "input": {
    "kind": "array",
    "items": ["response A", "response B", "response C"]
  },
  "execution": {
    "mode": "tools",
    "model": "auto",
    "tools": ["rank_candidates", "summarize_text"],
    "max_steps": 8
  },
  "policy": {
    "tier": "balanced",
    "timeout_ms": 30000
  }
}

Key fields (v2):

• objective – short, plain-language description of the task.

• input – structured input (string, array, object, etc.).

• execution – how the network should run it:

  • mode (e.g., tools, simple, chain)

  • model (or auto)

  • tools, max_steps, etc.

• policy – trust / SLA profile:

  • e.g., tier: "fast" | "balanced" | "safe" | "oracle"

  • timeout_ms, redundancy knobs, safety flags (varies by version).

---

3.3 /validate v1 – Prompt-Oriented Check

Use when:

• You want LLM-style “is this OK?” checks with minimal structure.

• You’re validating text-like outputs with simple acceptance rules.

Example (POST /api/v1/validate):

{
  "session_id": 302,
  "task_request_input": "Provide three bullet points about x402 payment flow.",
  "task_result_output": "x402 returns 402, client pays, then retries with receipt.",
  "task_domain": "api",
  "task_type": "explanation",
  "acceptance_criteria": ["accuracy", "conciseness", "non_hallucination"],
  "evaluation_mode": "llm_judge"
}

Key fields (v1):

• task_request_input – what was originally asked.

• task_result_output – what the model/agent produced.

• acceptance_criteria – free-form list of what “good” means.

• evaluation_mode – hints for how to judge (LLM judge, rubric, etc.).

---

3.4 /validate v2 – Verdict-Oriented Check

Use when:

• You need a clear verdict contract:

  • VALID / INVALID / RETRY / NEEDS_SPEC

• You’re validating outputs that may trigger payments, on-chain actions, or high-impact decisions.

Example (POST /api/v2/validate):

{
  "session_id": 409,
  "request_id": "v2-val-009",
  "claim": {
    "type": "summary",
    "description": "Summarize MCP endpoints exposed by router.",
    "output": "Stream endpoint is /mcp/messages and legacy is /messages.",
    "input_hash": "0xabc123"
  },
  "policy": {
    "tier": "balanced",
    "redundancy": 1,
    "rules": ["consistency", "non-hallucination"]
  },
  "context": {
    "dapp": "mcp-docs"
  }
}

Key fields (v2):

• claim – what is being asserted:

  • type (summary, classification, tool_call, transaction, etc.)

  • description (human-readable)

  • output (the thing to judge)

  • input_hash / IDs for traceability (optional but recommended)

• policy – how to judge:

  • tier (fast / balanced / safe / oracle)

  • redundancy (how many independent checks)

  • rules (consistency, non-hallucination, schema compliance, etc.)

• context – optional domain/app metadata.

Typical response shape (conceptual):

{
  "verdict": "VALID",
  "confidence": 0.92,
  "reasons": ["matches spec", "internally consistent"],
  "evidence": {
    "runs": [...],
    "scores": [...]
  }
}

---

4. How Agents Use /delegate and /validate

These primitives are designed to support agent → network and agent → agent workflows.

4.1 Typical Agent Pattern

1. Plan locally The agent decides what needs to be done (e.g., “summarize docs then draft an email”).

2. Offload work with /delegate It sends tasks + context to Cortensor via Corgent or Bardiel.

3. Optionally cross-check with /validate Before taking an irreversible step (send, pay, execute), the agent asks the network: “Is this good enough and safe enough?”

4. Act or adjust Based on VALID / INVALID / RETRY / NEEDS_SPEC, the agent:

   • proceeds

   • retries with clarification

   • escalates to another agent or a human

---

4.2 Combined Flow Example

Scenario: An ERC-8004 trading agent wants to execute a trade only if the research summary is trustworthy.

1. Agent calls Corgent /delegate v2 with:

   • objective: “Summarize recent market news for token X.”

   • policy: tier: "balanced", timeout_ms: 25000.

2. Network runs miners, returns a summary + evidence.

3. Agent calls Corgent /validate v2 with:

   • claim.output: the summary

   • policy.tier: "safe"

   • policy.redundancy: 3

   • rules: ["non-hallucination", "consistency"]

4. Verdict comes back, for example:

   { "verdict": "VALID", "confidence": 0.89 }

5. If verdict is:

   • VALID with high confidence → proceed with trade logic.

   • RETRY / NEEDS_SPEC → refine objective or fetch more data.

   • INVALID → discard and escalate (another agent, human review).

The same pattern applies in Virtual via Bardiel, using GAME/ACP Workers and Functions that wrap these endpoints.

---

5. Corgent, Bardiel & the “AWS for Agents” Analogy

Cortensor often describes itself as “AWS for agents” because the pattern rhymes with the early web:

• Before AWS: Everyone ran their own servers, fought hardware, and manually handled failover.

• After AWS: Apps call compute/storage/network primitives and focus on product.

Agents are at a similar inflection point:

• Today:

  • One-off scripts

  • Per-project routing & retries

  • Ad-hoc “trust” decisions

• With /delegate & /validate:

  • Agents keep their brains wherever they want (local, cloud, browser).

  • They call Cortensor for network muscles:

    • /delegate for execution

    • /validate for trust

  • They tune policy, not hardware:

    • fast vs safe

    • cheap vs paranoid

    • single-run vs multi-run consensus

In this model:

• Corgent is the infra-facing, ERC-8004-friendly surface:

  • REST, MCP, A2A, x402

  • Minimal, policy-driven contract.

• Bardiel is the Virtual-first product agent:

  • GAME/ACP Workers & Functions

  • Ecosystem UX, presets, and recipes

  • Still powered underneath by /delegate & /validate.

---

6. Alignment with Google DeepMind’s “Intelligent AI Delegation”

The Google DeepMind paper “Intelligent AI Delegation” argues that delegation is not just “call another model” but involves:

• Task decomposition

• Capability matching

• Transfer of authority & responsibility

• Clear specs and constraints

• Trust mechanisms and verifiable completion

Cortensor’s /delegate and /validate v2 surfaces are designed to match this direction:

1. Contract-first delegation

   • objective, input, execution, policy make delegation explicit, not hidden inside prompts.

2. Agent↔agent delegation

   • Corgent and Bardiel expose these primitives to other agents, not just humans.

3. Verifiability & trust baked in

   • /validate v2 standardizes verdicts and policies.

   • Underneath: PoI, PoUW, reputation, redundancy.

4. Capability & SLA tiers

   • policy.tier and execution hints let agents select fast vs safe vs oracle-grade profiles.

5. From heuristics to protocols

   • Stable, machine-readable contracts over REST/MCP/x402.

   • Same semantics whether you’re calling from a Virtual agent, an ERC-8004 agent, or a custom framework.

---

7. Where This Doc Fits in the Corgent/Bardiel Docs

This page is the conceptual + high-level API overview for /delegate and /validate as shared primitives for:

• Corgent (Cortensor’s infra-native agent)

• Bardiel (Virtual-native service agent)

Recommended subpages (to be added under Product → Agents → Corgent and under Bardiel’s section):

1. Delegate – REST & MCP Reference

   • Full v1/v2 schemas

   • Response formats

   • Error handling & timeouts

   • Trial vs normal vs x402

2. Validate – REST & MCP Reference

   • Claim schemas

   • Verdict schemas

   • Example policies per use case

3. Agent Recipes (Corgent & Bardiel)

   • “High-trust summary pipeline”

   • “Guardrail validation before payment”

   • “Dispute resolution via arbitration tier”

As the router evolves (v1.5 → v1.6 → Corgent v1.x and Bardiel releases), this doc remains the north star for what:

• /delegate is meant to do (execution fabric for agents)

• /validate is meant to do (trust checkpoint for agents)

while the subpages capture the exact, versioned details.