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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.cortensor.network/community-and-ecosystem/products-and-agents/corgent/delegate-and-validate-core-primitives-for-agent-scale-and-safety.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.