> For the complete documentation index, see [llms.txt](https://docs.bardiel.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bardiel.tech/technical-architecture/delegation-tooling-surface.md).

# Delegation Tooling Surface

Bardiel’s Delegation-as-a-Service is not just “call an LLM once”.\
Under the hood, it sits on top of a growing **tooling surface** that Bardiel can use to:

* fetch and shape context
* normalize and validate specs
* interact with Web3 and storage
* attach safety and reputation signals

When an agent, app, or market calls Bardiel to delegate work, it does **not** need to choose tools directly.\
Instead, the caller describes the task and policy, and Bardiel selects and sequences tools internally.

This page describes the major tooling categories that Delegation is being designed around.

***

### 1. Context & Retrieval Tools

These tools let Bardiel collect and shape *what the model sees* before any heavy compute runs on Cortensor.

**Planned capabilities:**

* **HTTP / Web fetcher**
  * fetches raw URLs (HTML, JSON, text)
  * strips boilerplate and extracts main content for injection into Cortensor context
* **Web page summarizer**
  * “TL;DR this URL in N bullets” style jobs
  * useful for quick previews or lightweight research
* **Web / curated search**
  * search over the open web or curated document sets
  * returns top-k snippets with links, ready to be composed into a delegation plan
* **Multi-URL ingest**
  * handles batches of URLs (reports, docs, FAQs)
  * can merge, filter, or cluster content before sending into a summarization or analysis step
* **Basic file loading**
  * PDF, DOC, Markdown, and similar formats
  * combined with simple vector or keyword search to find relevant sections in long documents

**Why it matters**

Delegation is often “research + reasoning”, not just reasoning.\
These tools let Bardiel act as a **research executor** for agents across **Base, Virtual, ERC-8004, and other onchain agent ecosystems**, grounding Cortensor runs in real context instead of blind prompts.

***

### 2. Data & Structure Tools

These tools make messy instructions and outputs more structured and machine-checkable.

**Planned capabilities:**

* **Spec normalizer**
  * takes messy natural-language instructions and normalizes them into a structured task spec:
    * constraints
    * input / output schema
    * edge cases
    * safety / policy notes
  * this spec is then used to drive both execution and validation
* **Schema / JSON validator**
  * checks whether outputs match expected structure
  * auto-fixes trivial formatting issues when safe (for example, missing quotes or minor type coercions)
  * emits explicit errors when structure is fundamentally wrong
* **Tabular / math helpers**
  * works over CSV / JSON tables and simple numeric tasks
  * supports aggregations, comparisons, and sanity checks on numeric outputs

**Why it matters**

Bardiel is meant to return results that other agents can **rely on and reuse**.\
That usually means “not just text” — it means structured, schema-respecting outputs with clear failure modes.

This matters whether the caller is:

* a Base-native app preparing an onchain action
* a Virtual agent building an ACP payload
* an ERC-8004-compatible market evaluating seller outputs
* or another agent ecosystem needing deterministic machine-readable results

***

### 3. Web3, Storage & Trust Tools

These tools connect delegated tasks to onchain state, market data, and durable storage.

**Planned capabilities:**

* **Onchain state reader**
  * reads balances, contract state, and relevant events
  * useful for tasks like:
    * “check if a position is safe”
    * “fetch position details”
    * “verify a claim against chain data”
* **Price / market data helpers**
  * pulls token prices, market stats, and related economic signals
  * helps Bardiel contextualize decisions where “is this good enough?” depends on current market conditions
* **Storage helpers (IPFS / object storage)**
  * attach large artifacts (evidence bundles, logs, raw outputs) via URIs / CIDs
  * allow results to carry *pointers* to heavier context without bloating agent messages

**Why it matters**

Many real workflows are **onchain and economic**: risk, settlement, reputation, execution.\
If Bardiel is going to be a useful execution layer for **Base, Virtual, ERC-8004, and other onchain agent ecosystems**, it must be able to see and record the state it is reasoning about.

***

### 4. Safety & Reputation Tools

These tools give Delegation (and later Validation / Arbitration) a way to reason about *risk* and *history*, not just content.

**Planned capabilities:**

* **Safety / policy checker**
  * flags risky content or actions
  * normalizes multi-language specs into a more uniform representation for safety checks
  * can be used both as:
    * a hard gate (“reject”)
    * a soft signal (“allow but lower confidence”)
* **Diff / comparison helpers**
  * compare current outputs to prior versions or consensus outputs
  * useful when Bardiel needs to generate evidence or test for regressions
* **Evidence bundlers**
  * group logs, intermediate outputs, and signals into compact offline bundles
  * can be stored via IPFS or other object stores to back later validation or arbitration decisions
* **Reputation lookups (future)**
  * query the historical behavior of agents, sellers, or miners
  * feed trust-weighted decisions in validation or arbitration

**Why it matters**

Bardiel is meant to be a **trust layer**, not just a compute layer.\
Having access to safety and reputation signals lets it make smarter choices about:

* validation depth
* escalation
* how to explain verdicts
* when to trust, retry, or stop

***

### 5. How Bardiel Chooses Tools

When an agent calls Delegation-as-a-Service, it does not directly say:

* “call web\_search, then http\_get, then summarize”

Instead, it describes desired outcomes and constraints. Bardiel then:

1. reads the task spec (or normalizes it if needed)
2. picks an internal **tool plan**:
   * which retrieval / context tools to run
   * whether to normalize spec or schema
   * where to invoke Cortensor for compute
   * what should be checked before returning results
3. executes that plan, collects results and signals, and returns a **single structured response**

Over time:

* tool choices and plans can evolve based on real traffic
* new tools can be added without breaking existing agents
* policies (`fast`, `safe`, `oracle`, `adaptive`) can adjust how aggressively tools are used and cross-checked

***

### 6. Status: Experimental by Design

The tooling surface described here is **deliberately experimental**:

* early phases focus on mapping which tools actually matter for real workloads
* data from Delegation and Validation will guide:
  * which tools become “core”
  * which are optional or deprecated
  * how deep each tool needs to go (for example, simple web fetch vs full RAG pipelines)

The end goal is simple:

* From an agent’s perspective:\
  “I describe the job and risk level to Bardiel; it handles the rest.”
* From the ecosystem’s perspective:\
  Bardiel offers a **standardized execution + tooling layer** on top of Cortensor, with verifiable, reliable results that **Base, Virtual, ERC-8004, and other onchain agent ecosystems** can safely build on.