# 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.