Skip to content

What is Agentweaver? ​

Describe the work. Generate the team and workflow. Run it on your infrastructure.

Agentweaver is a platform for running teams of AI agents on infrastructure you control. Describe a software delivery, content, product, operations, or organization-specific process. Agentweaver can generate its roles, skills, and workflow. It then runs the team in isolated sandboxes.

The agents remain probabilistic. Agentweaver makes their path toward the outcome governed and repeatable through persisted workflow state, explicit gates, and human approvals. Use the web interface or connect an assistant, editor, or CLI through MCP.

Start in the Project Gallery for project work, or Sessions for a personal Assistant conversation. Project pages expose the board, team, workflows, and run history.

How it works ​

Coordinator orchestration ​

For a define-outcome submission with autopilot off, the coordinator:

  1. Drafts an OutcomeSpec — goal, desired outcome, scope, assumptions
  2. Selects the best-fit workflow for your task via an LLM pass over available workflows and team roles — surfacing the choice and rationale. You can override from the Start task dialog or by typing use {workflow-id} in the coordinator chat.
  3. Asks for your confirmation before any work starts
  4. Decomposes the confirmed spec into a WorkPlan — subtasks arranged in a dependency graph
  5. Dispatches child agents in parallel, each in their own sandbox
  6. Shows a live topology graph of every agent and its status
  7. Lets you steer mid-run — send a directive, redirect a child, amend the plan, or stop
  8. Assembles all results into one combined diff
  9. Runs the selected collective gates, including RAI and applicable Build & Test, then human review
  10. Runs a Scribe pass after merge to record what the team learned

Direct mode skips outcome drafting; explicit autopilot can confirm a define-outcome run without a manual pause. Neither is permission to bypass tool or human merge approvals.

Key concepts ​

Projects ​

A Project contains a git working directory, project orchestration, its team, and team memory, with an effective provider and model configuration. Create from scratch or clone from GitHub. Personal Assistant sessions are separate conversations, not project-owned runs.

→ Working with Projects

Blueprints and casting ​

A Blueprint is a reusable team definition: roles, workflows, review policy, and sandbox policy. Start from a predefined Blueprint or generate one from a description of the work. When you instantiate it into a project, the casting algorithm assigns named agents to each role.

→ Agent Teams & Blueprints

Workflows ​

Workflows are YAML-defined multi-role pipelines that define the scenario. Agentweaver ships seven built-in workflows:

WorkflowUse it for
software-deliveryCode changes, features, refactors
bug-fixTargeted bug investigations and fixes
infra-opsInfrastructure, CI/CD, monitoring, and alerting work
content-authoringDrafting docs, blog posts, articles
pm-discoveryProduct discovery, research, specs
incident-responseLive incidents and postmortems
agent-evaluationTesting and evaluating agent outputs

When you submit a task, an LLM pass automatically matches it to the best-fit workflow. You can also author your own or generate one from a description.

→ Workflows

The board ​

Every project has a Kanban board with six semantic buckets, presented as a main row and a separate attention section:

ColumnOwned by
BacklogYou — capture tasks here
ReadyYou — drag tasks here when ready to run
ProblemsCoordinator — failed runs land here with reason
Human ReviewCoordinator — runs awaiting your approval
ActiveCoordinator — currently running orchestrations
DoneCoordinator — completed, merged runs

A heartbeat periodically promotes Ready tasks and starts coordinator runs up to a configurable limit.

→ Board and Backlog

Runs ​

A Run is a unit of execution. Project implementation work uses isolated git worktrees and durable event streams; collective changes require your approval before merge. Personal Assistant conversations do not require a project checkout.

→ Submitting and Watching Runs

Review & Merge ​

Before merging, coordinator orchestrations evaluate the selected workflow's collective gates over the assembled output, not per child. Built-in software workflows include RAI, Build & Test, and human approval.

→ Reviewing and Merging

Team Memory ​

Agents build on prior work through four memory layers compiled into every agent's context:

  1. Active Decisions — hard constraints (architectural and scope decisions)
  2. Core context — project-level standing context
  3. Learnings and patterns — top high-importance entries from prior runs
  4. Open session — current run context

Agents submit entries to a Decision Inbox typed as learning, pattern, update, architectural, or scope. Every memory and decision carries provenance and trust metadata. The Scribe only auto-merges low-risk learning, pattern, and update entries attributed to that completed run. Architectural and scope proposals stay pending unless a project owner or a verified Coordinator run accepts them (including the Coordinator's own finalization backstop). Existing memory and decision records migrated as legacy are excluded from prompt compilation until explicitly approved.

→ Agent Teams & Blueprints — Memory

MCP server ​

The full Agentweaver feature set is available programmatically through an MCP server. Claude Desktop, VS Code, GitHub Copilot CLI, and GitHub Copilot desktop can connect to the hosted /mcp endpoint and complete OAuth sign-in without a manually copied bearer token. GitHub Copilot users can install the Agentweaver Driver definition from the public docs URL and select it for tool-aware operation.

→ Connect an MCP client

Why Agentweaver ​

Other toolsAgentweaver
Orchestration primitives you wire up yourselfGenerated or reusable teams, skills, and workflows in one platform
Optional HITL through workflow patternsDefine-outcome confirmation or direct launch; mandatory human approval before merge
State in opaque managed storesInspectable file mirrors backed by authoritative structured memory/decision trust records
One review gate per agentSingle collective review over all assembled work
Vendor-hosted control planeRun the platform on infrastructure you control
Code-only scenariosAny knowledge-work scenario via the workflow system

Next steps ​

Diagram details and constraints
ElementContract
titleOne goal, one collective review
subtitleConfirm intent, dispatch bounded work, then integrate and review the whole result.
group-title0Plan and execute
group-title1Integrate, review, finish
Confirm intentConfirm intent
Confirm intentDraft the OutcomeSpec
Confirm intenthuman confirmation
Plan the workPlan the work
Plan the workPersist a WorkPlan DAG
Plan the worksubtasks + dependencies
Dispatch childrenDispatch children
Dispatch childrenRun the eligible frontier
Dispatch childrenper-child worktrees
Merge + ScribeMerge + Scribe
Merge + ScribeApproved integration path
Merge + ScribeMergeWorktree → Scribe
Collective reviewCollective review
Collective reviewOne human decision
Collective reviewapprove / revise / decline
Integrate + gatesIntegrate + gates
Integrate + gatesAssemble child branches
Integrate + gatesconfigured checks / review
e1confirm
e2dispatch
e3settled work
e4request review
e5approve
assurance-titleDO NOT CONFUSE ASSEMBLY WITH PUBLICATION
assurance-line1The collective workflow reaches MergeWorktree and Scribe; this graphic does not promise PR creation.
assurance-line2A blocked assembly can be recovered. Review approval does not itself mark the run complete.
Confirm intentInput
Confirm intentHuman goal
Confirm intentArtifact
Confirm intentOutcomeSpec
Confirm intentGate
Confirm intentConfirm or revise
Confirm intentScope
Confirm intentExplicit assumptions
Plan the workSelect
Plan the workWorkflow choice
Plan the workWorkPlan DAG
Plan the workOwners
Plan the workNamed subtasks
Plan the workStore
Plan the workPersist dependencies
Dispatch childrenReady
Dispatch childrenSatisfied dependencies
Dispatch childrenFiles
Dispatch childrenChild-owned worktree
Dispatch childrenObserve
Dispatch childrenChild status / results
Dispatch childrenFailure
Dispatch childrenBlocks dependents
Merge + ScribeMerge
Merge + ScribeReviewed integration
Merge + ScribeThen
Merge + ScribeCollective Scribe
Merge + ScribeRecord
Merge + ScribePromote decisions
Merge + ScribeDecline
Merge + ScribeSkips Scribe
Collective reviewApprove
Collective reviewProceed to merge
Collective reviewRevise
Collective reviewSteer / redispatch
Collective reviewNo Scribe path
Collective reviewBlocked
Collective reviewRecoverable state
Integrate + gatesChild branches
Integrate + gatesTarget
Integrate + gatesIntegration branch
Integrate + gatesGates
Integrate + gatesSelected checks
Integrate + gatesOutput
intentScope and assumptions are explicit; Revision reopens the intent gate
planOutcome-complete decomposition; Bounded work with named owners
dispatchObserve child status and results; Failure / RAI blocks dependents
finishDecline skips Scribe; No automatic PR claim here
reviewChanges can redispatch work; Blocked is recoverable, not terminal
integrateCollective—not per-child delivery; Merge failure may still run Scribe
notesDO NOT CONFUSE ASSEMBLY WITH PUBLICATION; The collective workflow reaches MergeWorktree and Scribe; this graphic does not promise PR creation.; A blocked assembly can be recovered. Review approval does not itself mark the run complete.
groupsPlan and execute; Integrate, review, finish