> ## Documentation Index > Fetch the complete documentation index at: https://clawmind.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # How It Works > ClawMind routes every due diligence task through an 8-step multi-agent pipeline. Each agent has a fixed role, and no step can be skipped. # How It Works Every task submitted to ClawMind travels through the same 8-step pipeline. Most stages are ordered so context accumulates as the analysis deepens. After the Researcher finishes, the Risk agent and Architect can run in parallel; the Critic then reviews Researcher, Risk, and Architect output together. *** ## The 8-Step Pipeline ``` User task │ ▼ 1. Memory retrieval ← pulls relevant past analyses from 0G Storage │ ▼ 2. Planner ← breaks the task into a structured research plan │ ▼ 3. Researcher ← gathers protocol facts, team info, on-chain data │ ├──▶ 4. Risk agent ← identifies attack vectors, custody risks, oracle risks │ └──▶ 5. Architect ← evaluates technical design and upgrade patterns │ ▼ 6. Critic ◄───── receives output from Researcher + Risk + Architect │ ▼ 7. Final agent ← applies score anchors, Critic penalties, verdict │ ├──▶ 0G Storage (report JSON + 0g:// URI) ├──▶ 0G Chain (hash + score + EIP-712 signature) └──▶ 8. Memory writer ──▶ 0G Storage (memory index) ``` *** ## Agent Roles Before any analysis begins, ClawMind queries the persistent memory index stored on 0G Storage. It performs semantic search over past analyses and injects the most relevant context into the Planner's input. This means the second time a similar protocol is reviewed, the pipeline already has prior risk patterns, known failure modes, and comparable verdicts available. **Output:** a ranked list of relevant memory chunks passed to the Planner. The Planner receives the raw user task and the memory context. It produces a structured research plan: what to look for, which risk categories are most relevant, and what the Researcher and Risk agent should prioritize. The Planner does not produce analysis — only a plan. This keeps downstream agents focused and reduces hallucination from open-ended prompts. **Output:** a structured research brief. The Researcher executes the plan. It extracts facts about the protocol: team background, audit history, TVL, governance structure, token design, upgrade patterns, and any available public documentation. The Researcher operates on public task text. It does not access live on-chain data or external APIs in the current version — that is a Q2 roadmap item (Forta, GoPlus, Chainalysis integration). **Output:** a structured protocol fact sheet. The Risk agent ingests the Researcher's fact sheet and evaluates it against a fixed set of risk categories: * **Custody risk** — who controls funds, are there withdrawal guards * **Oracle risk** — price feed manipulation, TWAP assumptions * **Upgrade risk** — admin keys, proxy patterns, timelock presence * **Smart contract risk** — audit coverage, known vulnerability patterns * **Operational risk** — team anonymity, deployment maturity, incident history Each risk area gets a severity rating that feeds into the final score. **Output:** a structured risk report with severity ratings per category. The Architect evaluates the technical design of the protocol — independent of the risk agent. It focuses on system architecture: how components interact, where single points of failure exist, and whether the design matches the stated security model. This separation matters. A protocol can have low-severity risk flags but a fundamentally flawed architecture, or vice versa. **Output:** a technical design evaluation. The Critic is the adversarial layer. It receives the full output of the Researcher, Risk agent, and Architect simultaneously, and its sole job is to find problems. The Critic raises **challenges** — specific claims that contradict, overstate, or underexamine the upstream agents' conclusions. Each challenge is tagged with a severity: | Severity | Score penalty | Example | | -------- | ------------- | -------------------------------------------------------------------------------- | | High | −15 | "Risk agent marked custody as low-risk but the contract has no withdrawal limit" | | Medium | −7 | "Researcher cited 2 audits but only 1 covers the current contract version" | | Low | −3 | "Architect did not address the oracle fallback behaviour under low liquidity" | Challenges can be **resolved** if the Final agent finds sufficient counter-evidence in the original inputs. Unresolved challenges accumulate and are reflected in the final score and the Adversarial Panel in the UI. **Output:** a list of challenges with severity ratings and resolution status. The Final agent synthesizes everything — the Planner's brief, the Researcher's facts, the Risk agent's ratings, the Architect's evaluation, and the Critic's unresolved challenges — into a single structured report. It applies **explicit score anchors** to ensure calibrated, non-collapsing verdicts: | Condition | Score anchor | | --------------------------------------------- | ---------------------------- | | Audited 2+ times, high TVL, active governance | 75 – 90 (`GO`) | | Single audit, moderate TVL, some unknowns | 40 – 60 (`INVESTIGATE_MORE`) | | No audit, custody risk, private key in env | 10 – 25 (`NO_GO`) | | Nonsense input | Refusal or score \< 10 | After anchoring, Critic penalties are subtracted from unresolved challenges. **Output:** final report JSON with score, recommendation, summary, and per-agent findings. After the report is finalized and stored, the Memory writer creates a compressed memory entry — a structured summary of the task, key findings, score, and recommendation — and appends it to the memory index on 0G Storage. This entry will be retrieved in Step 1 of future runs on similar protocols. **Output:** updated memory index on 0G Storage, with a new receipt. *** ## What the UI Shows After a run completes, the interface surfaces four panels: **Agent Pipeline** — a live step-by-step view of which agent is active, with per-agent output visible after completion. **Adversarial Panel** — shows every challenge the Critic raised, whether it was resolved, and the score impact of unresolved ones. **Report View** — the full structured report: score, recommendation, per-category findings, and the final summary. **Integrity Panel** — the on-chain receipt: 0G Storage URI, root hash, transaction hash, and the EIP-712 operator signature for verification. *** ## Verification Every run produces two receipts that can be checked independently: ```bash theme={null} # Check the report is stored on 0G Storage curl -X POST https://clawmind-puce.vercel.app/api/report/retrieve \ -H "Content-Type: application/json" \ -d '{"storageUriOrRootHash": "0g://your-root-hash"}' # Check the hash is anchored on 0G Chain # Open the transaction from the on-chain receipt in the 0G explorer # https://chainscan.0g.ai/address/0x24bAAC6720ae5B01A1CC90eCC1C15AFcb903E121 ``` The report hash in the UI should match the hash stored on-chain. If it does not, the report has been altered.