Agent Surfaces

Bardiel is a service agent that other agents call through Virtual-native interfaces, with optional exposure into ERC-8004 validator / oracle flows. This page describes the high-level request and response shapes Bardiel expects, independent of any specific SDK or language.

---

Where Bardiel Is Exposed

For 2026, Bardiel is reachable through:

• Virtual GAME Workers / Functions Bardiel appears as a Worker/Function target. Typical bindings: delegate_to_bardiel, validate_with_bardiel, arb_with_bardiel.

• ACP (Agent Commerce Protocol) Bardiel can be registered as:

  • a high-trust execution provider (delegation),

  • a validation oracle (pre-settlement checks),

  • an optional arbitration oracle for disputes where markets opt in.

• ERC-8004 Agents and Registries (Planned) Bardiel can be exposed as:

  • a validator / oracle service in the ERC-8004 registry,

  • a target for ERC-8004 agents to delegate tasks and request validation or arbitration,

  • an endpoint reachable over MCP/x402-style service calls.

Internally, Bardiel talks to Cortensor Router. Virtual and ERC-8004 developers only talk to Bardiel.

---

Common Request Envelope

All Bardiel calls share a common logical envelope.

Example (delegation):

{
  "mode": "delegation",
  "task": {
    "type": "summarize",
    "input": {
      "text": "long report text here"
    },
    "spec": {
      "max_summary_words": 200
    }
  },
  "policy": "safe",
  "context": {
    "caller": "agent_or_market_id",
    "surface": "GAME"
  },
  "metadata": {
    "client_trace_id": "optional-string"
  }
}

Fields

• mode

  • "delegation" – Bardiel runs the task on Cortensor and returns a result.

  • "validation" – Bardiel checks a claimed result or planned action.

  • "arbitration" – Bardiel resolves a dispute between two parties (used mainly by ACP and ERC-8004 style markets).

• task Structured description of what should be done or checked (see Task Object below).

• policy One of: "fast", "safe", "oracle", "adaptive". This controls how cautious Bardiel should be. Details are defined in Policy Engine & Tiers.

• context Optional caller context (agent ID, market ID, environment, surface such as GAME, ACP, or ERC8004).

• metadata Optional tags for tracing, logging, analytics (for example client_trace_id, job IDs, or correlation keys).

---

Task Object

The task object contains the actual work description.

Conceptually it contains:

• type – task category (for example summarize, classify, json_tool_call, text_generation, research).

• input – the content or parameters for the task.

• spec – constraints, schema, or rules Bardiel should enforce.

• claimed_result – result produced by another agent (used for validation and arbitration).

• dispute_context – extra information for arbitration (roles, market, SLA, etc.).

Shapes can vary slightly per surface (GAME vs ACP vs ERC-8004), but the structure is similar.

Delegation Example

{
  "type": "summarize",
  "input": {
    "text": "long report text here"
  },
  "spec": {
    "max_summary_words": 200
  }
}

Validation Example

{
  "type": "json_tool_call",
  "input": {
    "tool_name": "create_event"
  },
  "spec": {
    "required_fields": ["title", "start", "end"],
    "datetime_format": "ISO-8601"
  },
  "claimed_result": {
    "title": "demo",
    "end": "tomorrow"
  }
}

Arbitration Example

{
  "type": "text_generation",
  "input": {
    "prompt": "Generate 10 product names with constraints X/Y/Z."
  },
  "spec": {
    "must_include_keyword": "X",
    "max_length": 30
  },
  "claimed_result": {
    "names": ["... seller output ..."]
  },
  "dispute_context": {
    "buyer_id": "buyer_123",
    "seller_id": "seller_456",
    "market_id": "acp_market_1"
  }
}

Exact shapes can be refined per integration (GAME, ACP, ERC-8004), but this is the conceptual model.

---

Policy Field (Quick View)

The policy string is a hint to Bardiel’s internal policy engine:

• "fast" – low cost, single miner, light checks.

• "safe" – default high-trust path, 3 miners, PoI + basic scoring.

• "oracle" – high redundancy, strict thresholds, for high-stakes workloads.

• "adaptive" – start cheap, escalate only if confidence is low.

Full details are in Policy Engine & Tiers, but from an agent’s perspective it’s a simple string per call.

---

Response Envelope

All Bardiel responses return a structured envelope.

Example (delegation):

{
  "status": "VALID",
  "result": {
    "summary": "concise summary here"
  },
  "confidence": 0.91,
  "evidence": {
    "redundancy": 3,
    "poi_cluster_agreement": 0.87
  },
  "retry_instructions": null,
  "trace_id": "bardiel-trace-123",
  "bardiel_version": "v0.1.0"
}

Fields

• status

  • Delegation: usually VALID, RETRY, or NEEDS_SPEC.

  • Validation: VALID, INVALID, RETRY, or NEEDS_SPEC.

  • Arbitration: SELLER_VALID, SELLER_INVALID, or INCONCLUSIVE.

• result

  • For delegation: the chosen output (text, JSON, etc.).

  • For arbitration: optional canonical result (for example the consensus output).

  • For pure validation: often omitted or minimal.

• confidence Float in [0, 1] representing Bardiel’s belief in the verdict.

• evidence Summarized trust signals such as redundancy, agreement, usefulness scores, schema errors, or high-level notes about tools used. The exact structure can evolve over time.

• retry_instructions Optional guidance on how to fix the task or output when RETRY or NEEDS_SPEC is returned.

• trace_id Identifier for correlating Bardiel logs and Cortensor logs.

• bardiel_version Semantic version of Bardiel that produced this response.

These envelopes are the foundation that GAME, ACP, ERC-8004 agents, and future SDKs will map onto their own type systems. From the caller’s perspective, Bardiel always looks like a single, consistent “trust and execution” endpoint, even though under the hood it is orchestrating tools, miners, and validation logic across Cortensor.