| title | 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.
For a define-outcome submission with autopilot off, the coordinator:
- Drafts an OutcomeSpec — goal, desired outcome, scope, assumptions
- 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. - Asks for your confirmation before any work starts
- Decomposes the confirmed spec into a WorkPlan — subtasks arranged in a dependency graph
- Dispatches child agents in parallel, each in their own sandbox
- Shows a live topology graph of every agent and its status
- Lets you steer mid-run — send a directive, redirect a child, amend the plan, or stop
- Assembles all results into one combined diff
- Runs the selected collective gates, including RAI and applicable Build & Test, then human review
- 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.
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.
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.
Workflows are YAML-defined multi-role pipelines that define the scenario. Agentweaver ships seven built-in workflows:
| Workflow | Use it for |
|---|---|
software-delivery |
Code changes, features, refactors |
bug-fix |
Targeted bug investigations and fixes |
infra-ops |
Infrastructure, CI/CD, monitoring, and alerting work |
content-authoring |
Drafting docs, blog posts, articles |
pm-discovery |
Product discovery, research, specs |
incident-response |
Live incidents and postmortems |
agent-evaluation |
Testing 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.
Every project has a Kanban board with six semantic buckets, presented as a main row and a separate attention section:
| Column | Owned by |
|---|---|
| Backlog | You — capture tasks here |
| Ready | You — drag tasks here when ready to run |
| Problems | Coordinator — failed runs land here with reason |
| Human Review | Coordinator — runs awaiting your approval |
| Active | Coordinator — currently running orchestrations |
| Done | Coordinator — completed, merged runs |
A heartbeat periodically promotes Ready tasks and starts coordinator runs up to a configurable limit.
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
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.
Agents build on prior work through four memory layers compiled into every agent's context:
- Active Decisions — hard constraints (architectural and scope decisions)
- Core context — project-level standing context
- Learnings and patterns — top high-importance entries from prior runs
- 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
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.
| Other tools | Agentweaver |
|---|---|
| Orchestration primitives you wire up yourself | Generated or reusable teams, skills, and workflows in one platform |
| Optional HITL through workflow patterns | Define-outcome confirmation or direct launch; mandatory human approval before merge |
| State in opaque managed stores | Inspectable file mirrors backed by authoritative structured memory/decision trust records |
| One review gate per agent | Single collective review over all assembled work |
| Vendor-hosted control plane | Run the platform on infrastructure you control |
| Code-only scenarios | Any knowledge-work scenario via the workflow system |
- Sign in with Microsoft Entra ID to get started
- Create your first project
- Learn about workflows
- Submit your first run
- Connect an MCP client
Diagram details and constraints
| Element | Contract |
|---|---|
| title | One goal, one collective review |
| subtitle | Confirm intent, dispatch bounded work, then integrate and review the whole result. |
| group-title0 | Plan and execute |
| group-title1 | Integrate, review, finish |
| Confirm intent | Confirm intent |
| Confirm intent | Draft the OutcomeSpec |
| Confirm intent | human confirmation |
| Plan the work | Plan the work |
| Plan the work | Persist a WorkPlan DAG |
| Plan the work | subtasks + dependencies |
| Dispatch children | Dispatch children |
| Dispatch children | Run the eligible frontier |
| Dispatch children | per-child worktrees |
| Merge + Scribe | Merge + Scribe |
| Merge + Scribe | Approved integration path |
| Merge + Scribe | MergeWorktree → Scribe |
| Collective review | Collective review |
| Collective review | One human decision |
| Collective review | approve / revise / decline |
| Integrate + gates | Integrate + gates |
| Integrate + gates | Assemble child branches |
| Integrate + gates | configured checks / review |
| e1 | confirm |
| e2 | dispatch |
| e3 | settled work |
| e4 | request review |
| e5 | approve |
| assurance-title | DO NOT CONFUSE ASSEMBLY WITH PUBLICATION |
| assurance-line1 | The collective workflow reaches MergeWorktree and Scribe; this graphic does not promise PR creation. |
| assurance-line2 | A blocked assembly can be recovered. Review approval does not itself mark the run complete. |
| Confirm intent | Input |
| Confirm intent | Human goal |
| Confirm intent | Artifact |
| Confirm intent | OutcomeSpec |
| Confirm intent | Gate |
| Confirm intent | Confirm or revise |
| Confirm intent | Scope |
| Confirm intent | Explicit assumptions |
| Plan the work | Select |
| Plan the work | Workflow choice |
| Plan the work | WorkPlan DAG |
| Plan the work | Owners |
| Plan the work | Named subtasks |
| Plan the work | Store |
| Plan the work | Persist dependencies |
| Dispatch children | Ready |
| Dispatch children | Satisfied dependencies |
| Dispatch children | Files |
| Dispatch children | Child-owned worktree |
| Dispatch children | Observe |
| Dispatch children | Child status / results |
| Dispatch children | Failure |
| Dispatch children | Blocks dependents |
| Merge + Scribe | Merge |
| Merge + Scribe | Reviewed integration |
| Merge + Scribe | Then |
| Merge + Scribe | Collective Scribe |
| Merge + Scribe | Record |
| Merge + Scribe | Promote decisions |
| Merge + Scribe | Decline |
| Merge + Scribe | Skips Scribe |
| Collective review | Approve |
| Collective review | Proceed to merge |
| Collective review | Revise |
| Collective review | Steer / redispatch |
| Collective review | No Scribe path |
| Collective review | Blocked |
| Collective review | Recoverable state |
| Integrate + gates | Child branches |
| Integrate + gates | Target |
| Integrate + gates | Integration branch |
| Integrate + gates | Gates |
| Integrate + gates | Selected checks |
| Integrate + gates | Output |
| intent | Scope and assumptions are explicit; Revision reopens the intent gate |
| plan | Outcome-complete decomposition; Bounded work with named owners |
| dispatch | Observe child status and results; Failure / RAI blocks dependents |
| finish | Decline skips Scribe; No automatic PR claim here |
| review | Changes can redispatch work; Blocked is recoverable, not terminal |
| integrate | Collective—not per-child delivery; Merge failure may still run Scribe |
| notes | DO 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. |
| groups | Plan and execute; Integrate, review, finish |