What is AWP?

The Agentic Workflow Protocol (AWP) is an open specification for portable, auditable and policy-controlled agentic workflows. A workflow is described in a declarative manifest: which agents and tools take part, which steps run in which order, within which limits, under which governance rules, and which audit events it leaves behind.

AWP is a specification, not a platform. A runtime reads a manifest, validates it, enforces its limits and governance rules while executing it, and emits audit events with standardized semantics. Any runtime may implement AWP; OpenAgentix is one implementation in progress.

How AWP relates to MCP and A2A

AWP does not replace the Model Context Protocol (MCP) or the Agent2Agent protocol (A2A). It sits above them: a manifest references MCP servers as tool sources and A2A endpoints as remote agents.

AWP references MCP and A2A. It does not replace them.

	MCP	A2A	AWP
Scope	Agents ↔ tools and resources	Agent ↔ agent communication	Definition, governance, execution and audit of workflows
Question answered	How does an agent call this tool?	How do two agents talk to each other?	What may this workflow do, who owns it and what happened?
Example artifact	Tool and resource definitions	Agent card, task messages	Workflow, Agent and Policy manifests, audit events

What can AWP enable?

Portable workflows. One manifest describing agents, tools, steps, triggers and inputs that different runtimes can read.
Enforced boundaries. Budgets, permissions, approvals and policies that a runtime applies before an action, with default deny.
Human decisions where they matter. Approval gates for actions such as production deployment, with separation of duties.
Reproducible audit trails. Standard audit events, decision traces and execution records for every run.
A trusted supply chain. Secrets by reference, versioned and signed manifests, pinned images and dependency declarations.

Why does AWP matter?

For workflow authors

Write a workflow once, in one reviewable file, and validate it before it runs.

For platform builders

Implement a shared contract instead of inventing your own format. Conformance profiles say what a runtime does and does not support.

For security and governance teams

Review ownership, data policy, tool permissions and approvals as data, not as prose.

A manifest at a glance

A workflow is one YAML file. This compact example has an owner, a budget, one agent, one step and a deny rule. It follows the Vulnerability fixer example, shortened.

apiVersion: awp.agenticworkflowprotocol.org/v1alpha1
kind: Workflow
metadata:
  name: vulnerability-fixer
  version: 0.1.0
  owner:
    team: security-team
  classification: internal
  risk:
    level: medium
spec:
  triggers:
    - type: manual
  budget:
    maxCostUsd: 2.00
    maxSteps: 30
    maxDuration: 15m
  agents:
    - id: fixer
      model:
        provider: ollama
        name: qwen3
  workflow:
    - id: fix
      agent: fixer
  permissions:
    default: deny
    tools:
      production.deploy:
        allow: false

Open the full annotated example or continue with the Quickstart to validate a manifest yourself.

Where to go next