Agents

Weave ships with eight specialised agents. Each one has a distinct role; together they cover the planning, research, execution, and review phases of a development task. Agents appear in the Fabric @ mention menu under their lowercase names — those same names are the keys you use in weave-fabric.jsonc.

At a glance

Agent modes

• primary — uses the user-selected model from the Fabric UI. Loom and Tapestry.
• subagent — defaults to whatever model Loom is using unless you explicitly override it in config.
• all — available in both contexts. Shuttle.

Loom — main orchestrator

@loom is the default entry point for every conversation. It assesses the request, decides whether the work needs the full Plan → Review → Execute cycle or can be answered directly, and delegates to the right specialist.

Loom never writes code itself — it plans and delegates. For trivial requests it answers immediately or routes to a single subagent; for anything substantial it kicks off the structured workflow.

Loom tracks progress obsessively via todo lists so long-running work stays auditable.

Tapestry — execution orchestrator

@tapestry is the heads-down executor. Activated by /start-work, it reads a plan from .weave/plans/, walks through each - [ ] task in order, implements it, verifies completion, ticks the box, and moves on.

Key constraints:

• Tapestry cannot spawn subagents. It focuses on sequential implementation.
• If interrupted, running /start-work again resumes from the first unchecked task — state lives in .weave/state.json.
• It coordinates execution by delegating each step to Shuttle via the Task tool rather than implementing inline.

Shuttle — category specialist

@shuttle is the domain worker. When Loom dispatches into a category (e.g. visual-engineering, backend, frontend), Shuttle executes with the model and tool overrides from that category block.

Shuttle has full tool access by default — bash, write, edit, web tools. Lock it down per-project via the tools field if needed.

Pattern — strategic planner

@pattern produces structured implementation plans. When a task takes 5+ steps or touches architecture, Loom hands the request to Pattern, which:

1. Researches the codebase (typically delegating to Thread).
2. Looks up external docs (typically delegating to Spindle).
3. Writes a plan to .weave/plans/{name}.md with - [ ] checkboxes for every actionable step.

Pattern is read-only. It never writes code — only plans. Plans are designed to be reviewed by Weft before execution.

Thread — codebase explorer

@thread is the fast, factual code-reading agent. Loom delegates to Thread whenever it needs to:

• Find a file by pattern.
• Grep for a symbol or string.
• Answer "where is X defined" / "which files reference Y".
• Summarise a directory or module.

Thread runs at temperature 0.0 with grep, glob, and read only — no edits, no shell, no creativity. Output includes precise file paths and line numbers.

Spindle — external researcher

@spindle handles everything outside the repo: library docs, API references, RFC text, blog posts, anything reachable via webfetch. It synthesises findings and cites sources.

Spindle is read-only (no write/edit/bash) and is dispatched whenever Loom or Pattern needs ground-truth documentation rather than codebase context.

Weft — reviewer / auditor

@weft validates work — both plans (before execution) and implementations (after). It's approval-biased: rejection requires a true blocker, capped at 3 issues per review.

What Weft checks:

• Referenced files actually exist.
• Tasks have enough context to execute.
• No contradictions between plan steps.
• Implementations match requirements.
• No leftover TODOs, stubs, or half-finished sections.

Weft is read-only. It does not propose code; it returns APPROVE or REJECT with specific reasoning.

Warp — security auditor

@warp reviews code changes for security issues and standards compliance. Unlike Weft it is skeptical-biased — when it sees auth, crypto, token handling, or input validation, it rejects by default and requires evidence of correctness.

What Warp watches for:

• Injection (SQL, command, prompt, template).
• Auth bypass and broken access control.
• Token storage, rotation, and lifetime issues.
• Crypto weaknesses (weak primitives, bad randomness, missing IVs).
• Compliance with OAuth2, OIDC, WebAuthn, JWT specs (it can webfetch RFCs to verify).

Warp self-triages — on changes that clearly aren't security-relevant it fast-exits without commentary, so wiring it into every PR is cheap. Warp is read-only.

How Loom decides who handles what

You can always invoke an agent yourself by mentioning it — Loom only auto-delegates when it's the natural team lead for the request.

Next: Workflow walks through the Plan → Review → Execute cycle, plus the supporting features (hooks, skills, background agents, tool permissions).