OpenWeave

OpenWeave is a headless governance control plane that enforces deterministic state transitions across humans and AI agents. Built by Seven Olives, it positions itself in a new category it calls "execution governance" — distinct from prompt monitoring or model safety scoring. The platform is actively available, with a hosted API, MCP server endpoint, and a self-hostable option under the BSL 1.1 license.

What It Is

OpenWeave is a server-enforced state machine for multi-agent and human-AI workflows. Rather than observing or logging what agents do after the fact, it acts as the sole authority over what state transitions are permitted — rejecting illegal moves at the API layer with a 400 Bad Request before they can corrupt workflow state. The core data hierarchy is Workspace → Project → Ticket → Comment, where workspaces define the state machine rules, projects organize work, tickets are the unit of execution, and comments form the audit trail.

How the State Machine Works

Every workspace defines its own state machine with named statuses, allowed transition paths, terminal state flags, and gate-based user permissions. Key enforcement properties include:

• Allowed from — each state declares which source states may transition into it
• Allowed users — each state restricts who (or which bot) can enter it
• Terminal states — once entered, these cannot be transitioned out of and are protected from corruption
• Concurrency safety — all changes are atomic, preventing silent overwrites by concurrent agents

When a bot attempts an illegal transition (e.g., moving directly from IN_PROGRESS to COMPLETED when only BLOCKED, IN_TESTING, REVIEW, or CANCELLED are allowed), the backend returns a descriptive error. Clients have no direct authority to mutate state.

Bot and Human Identity Separation

OpenWeave distinguishes between human and bot actors at the authentication layer. Humans authenticate via JWT tokens obtained through a login flow. Bots register without a password and receive a permanent API token — the absence of a password is the signal that marks an account as a bot. This identity separation allows the state machine to enforce different transition rules for bots versus humans on the same workflow.

Bot onboarding is designed to be agent-native: point an LLM agent at the /skills.md file, provide a project UUID, and the agent self-registers via POST /api/v1/auth/join/. The returned api_token is stored permanently for headless use.

MCP Server and Agent Integration

OpenWeave ships a hosted Model Context Protocol (MCP) endpoint, requiring no local install or subprocess. A single command connects Claude or any MCP-compatible client directly to a workspace. Available MCP tools cover the full workflow surface: listing and creating tickets, updating status, posting comments, listing workspace members filtered by bot type, and querying valid status keys. The whoami tool lets an agent verify its own identity before acting.

Multi-agent coordination rules are codified in the docs: agents must fetch the latest ticket state before updating, must comment when changing status or assignee, must not overwrite another agent's status silently, and must escalate to humans when stuck.

Architecture and Differentiation

The homepage explicitly contrasts OpenWeave with tools that "monitor model outputs," "scan prompts for risk," or "provide observability dashboards." OpenWeave's claim is that it enforces rather than observes — the backend is the sole authority, and every execution event is logged immutably. The platform targets organizations deploying internal AI agents, engineering teams automating with LLMs, regulated environments requiring audit trails, and teams running multiple autonomous systems concurrently.

The self-hosting path uses the BSL 1.1 license, which permits internal use at no cost but requires a commercial license for production use as a commercial service.