Agentic Workflow Protocol · v1alpha1 (draft)

Define. Govern. Execute.

AWP is an open standard for portable, auditable and policy-controlled agentic workflows.

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
    - id: test
      type: command
      command: npm test
      dependsOn: [fix]
  permissions:
    default: deny
    tools:
      shell.execute:
        allow: true
      production.deploy:
        allow: false
  policies:
    merge:
      allow: false
    production:
      allow: false

The declarative standard for agentic workflows.

AWP describes what an agentic workflow does, within which limits it may run, under which governance it runs and what it leaves behind. Agents are not plain LLM calls; they are controlled workflows with defined capabilities, limits and responsibilities.

Define

Agents, tools, steps, triggers and inputs in one manifest.

Govern

Policies, approvals and budgets that a runtime enforces.

Execute

Portable across runtimes that implement the specification.

Audit

Standard events and decision traces for every execution.

MCP connects agents to tools. A2A connects agents to agents. AWP defines how agents work.

Scope of MCP, A2A and AWP
	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

AWP does not replace MCP or A2A. A manifest references MCP servers as tool sources and A2A endpoints as remote agents.

One file describes the workflow, its limits and its rules.

# Example: an agentic workflow that investigates and fixes a CVE in a repository.
# Profiles exercised: core, governance, audit, mcp.
apiVersion: awp.agenticworkflowprotocol.org/v1alpha1
kind: Workflow

metadata:
  name: vulnerability-fixer
  version: 0.1.0
  description: Investigate a CVE in a repository, prepare a fix and open a pull request.
  owner:
    team: security-team
    contact: [email protected]
  classification: internal
  purpose: Reduce time to remediate known vulnerabilities in internal repositories.
  risk:
    level: medium
    category:
      - security

spec:

  triggers:
    - type: manual

  inputs:
    - name: repository
      type: string
      required: true
      description: Repository in the form owner/name.

    - name: cve
      type: string
      required: true
      pattern: "^CVE-[0-9]{4}-[0-9]{4,}$"

  budget:
    maxCostUsd: 2.00
    maxSteps: 30
    maxDuration: 15m
    resources:
      maxTokens: 400000
      maxToolCalls: 60
      maxRetries: 2
      maxConcurrency: 1

  secrets:
    - name: GITHUB_TOKEN
      source: secret-manager
      scope:
        - github

  mcpServers:
    - name: github
      transport: streamable-http
      url: https://mcp.example.com/github
      auth:
        secretRef: GITHUB_TOKEN

  actionGroups:
    github.read:
      - github.search_code
      - github.get_file_contents
    github.write:
      - github.create_branch
      - github.push_files
      - github.create_pull_request
      - github.merge_pull_request
    git.push:
      - github.push_files
    pullRequest.create:
      - github.create_pull_request
    git.merge:
      - github.merge_pull_request

  agents:

    - id: researcher
      model:
        provider: anthropic
        name: claude
      instructions: |
        Find where the vulnerable dependency or code path is used and summarize
        the affected files and the recommended fix.
      tools:
        - type: mcp
          server: github
          tools:
            - search_code
            - get_file_contents

    - id: fixer
      model:
        provider: ollama
        name: qwen3
      instructions: |
        Apply the recommended fix with the smallest possible change.
      tools:
        - type: mcp
          server: github

  workflow:

    - id: investigate
      agent: researcher
      task: "Investigate ${{ inputs.cve }} in ${{ inputs.repository }}."
      outputs:
        - name: report
          classification: internal

    - id: fix
      agent: fixer
      task: "Fix the issue described in the report: ${{ steps.investigate.outputs.report }}"
      dependsOn:
        - investigate

    - id: test
      type: command
      command: npm test
      image: registry.example.com/build/node@sha256:3f1d5c0a9e2b7c4d6e8f0a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f
      timeout: 10m
      dependsOn:
        - fix

  permissions:
    default: deny
    tools:
      github.read:
        allow: true
      github.write:
        allow: true
        resources:
          - "${{ inputs.repository }}"
      shell.execute:
        allow: true
      production.deploy:
        allow: false
    network:
      egress: deny
      allowHosts:
        - mcp.example.com
        - registry.npmjs.org

  policies:
    git:
      allowPush: true
      allowForcePush: false
    pullRequest:
      allowCreate: true
    merge:
      allow: false
    production:
      allow: false

  audit:
    enabled: true

metadata: name, version, owner, classification and risk level.
spec.budget: cost, steps, duration, tokens, tool calls, retries, concurrency.
spec.agents and spec.mcpServers: who acts and with which tools.
spec.workflow: steps with dependsOn, including a command step.
spec.permissions and spec.policies: what is allowed, what is not.

Annotated walkthrough

Agentic systems need more than intelligence. They need boundaries.

Governance rules are declared in the manifest and enforced by the runtime.

Identity & ownership

Every workflow names the team accountable for it.

metadata:
  name: invoice-processing
  version: 1.2.0
  owner:
    team: finance-ai
    contact: [email protected]

Data classification

Inputs and outputs carry a class; external transfer can be denied.

dataPolicy:
  classification: confidential
  restrictions:
    externalTransfer: deny

Data residency

Restrict where data is processed and by which providers. Undeterminable regions fail closed.

dataPolicy:
  residency:
    allowed: [EU]
  processing:
    forbiddenProviders:
      - public-cloud-us

Model governance

Only approved providers and models, checked before the run starts.

modelPolicy:
  allowedProviders: [azure-openai, ollama]
  requirements:
    approvalStatus: approved
    encryption: true

Tool governance

Permissions per action, with default deny and network limits.

permissions:
  default: deny
  tools:
    github.read:
      allow: true
    production.deploy:
      allow: false

Budgets & resources

Cost, steps, time, tokens, tool calls, retries and concurrency are bounded.

budget:
  maxCostUsd: 5.00
  maxSteps: 50
  maxDuration: 30m
  resources:
    maxToolCalls: 100

Risk levels

A possible governance model, not a regulatory classification.

metadata:
  risk:
    level: high
    category: [security, financial]

Environments

The same workflow runs with different autonomy per environment.

environments:
  development:
    autonomy: unrestricted
  production:
    autonomy: approval-required

Separation of duties

Whoever initiates an action cannot approve it.

approval:
  separationOfDuties:
    enabled: true
    rules:
      - actorCannotApproveOwnAction: true

AWP provides machine-readable governance primitives that can help organizations implement and enforce their own compliance requirements. Compliance depends on the implementation, organizational controls and applicable regulatory requirements.

Trusted agent supply chain. Know what runs before you let it run.

Secrets by reference

Manifests name secrets and reference them with secretRef. A literal token in a manifest is rejected.

Integrity

Immutable versions, manifest digests, signatures, provenance, trusted registries and dependency declarations.

Fail closed

Unknown fields in governance sections and policies that cannot be evaluated deny instead of allow.

secrets:
  - name: GITHUB_TOKEN
    source: secret-manager
    scope:
      - github

mcpServers:
  - name: github
    transport: streamable-http
    url: https://mcp.example.com/github
    auth:
      secretRef: GITHUB_TOKEN

Read more: secrets, supply chain, threat model.

Execution needs auditability.

Execution ID: awp-exec-01JABC7Q4M2W9X0Y1Z2A3B4C5D
Workflow:     [email protected]
Started:      2026-10-05T13:42:11Z

  01  trigger
  02  researcher
  03  github.search
  04  fixer
  05  shell.execute
  06  npm.test
  07  policy.check
  08  pull-request

Result:       SUCCESS

Event families:

workflow.*
agent.*
tool.*
policy.*
approval.*
artifact.*

AWP defines the semantics of audit events; implementations may provide tamper-evident storage. Executions can be reproduced from a record of versions, models, tools and policies. Decision traces record actions, evidence and policy checks, not private model reasoning.

Audit events · Decision trace

Some actions need a human decision.

The runtime pauses before the action and does not continue until the required approvals are granted by authenticated humans. Agents cannot approve.

Text version

Agent
|
Analyze
|
Implement
|
Test
|
+----------------------+
| Human Approval       |
|                      |
| [x] Security Review  |
| [x] Policy Check     |
+----------+-----------+
         |
      Deploy

approval:
  requiredFor:
    - production.deploy
    - git.merge
    - external.communication
  approvers:
    - role: security-reviewer
  timeout: 24h
  separationOfDuties:
    enabled: true
    rules:
      - actorCannotApproveOwnAction: true

Human approval · Separation of duties

Policy-as-Code for agentic systems.

Policies are declarative, evaluated by the runtime before an action, and every evaluation produces a policy.evaluated event.

# Example: a reusable policy that requires a release manager for production deployments.
apiVersion: awp.agenticworkflowprotocol.org/v1alpha1
kind: Policy

metadata:
  name: no-production-autonomy
  version: 1.0.0
  owner:
    team: platform-governance
    contact: [email protected]

spec:
  rules:
    - id: deploy-needs-release-manager
      when:
        action: production.deploy
      effect: requireApproval
      approval:
        approvers:
          - role: release-manager

    - id: no-merge-in-production
      when:
        action: git.merge
        environment.name: production
      effect: requireApproval
      approval:
        approvers:
          - role: release-manager
          - role: security-reviewer
        minApprovals: 2

# Example: a reusable policy that keeps personal data inside the EU.
apiVersion: awp.agenticworkflowprotocol.org/v1alpha1
kind: Policy

metadata:
  name: eu-data-residency
  version: 1.0.0
  owner:
    team: data-protection
    contact: [email protected]

spec:
  rules:
    - id: personal-data-stays-in-eu
      when:
        data.classification:
          in:
            - personal
            - sensitive
        destination.region:
          notIn:
            - EU
      effect: deny
      message: Personal and sensitive data must not leave the EU.

Policy-as-Code

Built on an open agentic stack.

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

tools:
  - type: mcp
    server: github

agents:
  - id: security-agent
    protocol: a2a
    endpoint: https://agents.example.com/a2a/security-review

MCP · A2A

Know the plan before it runs.

A common command vocabulary is specified: awp validate, awp lint, awp simulate, awp plan, awp run, awp audit. The CLI is a specified interface (output formats), not a product; any implementation may provide it.

$ awp plan workflow.yaml

AWP Execution Plan

Workflow: vulnerability-fixer
Version: 0.1.0

Agents:
  researcher → claude
  fixer      → qwen3

Tools:
  github.read
  github.write
  shell.execute

Policies:
  ✓ cost limit
  ✓ tool permissions
  ✓ network policy
  ✓ production restriction

Human approval:
  required before merge

Estimated maximum:
  30 steps
  $2.00
  15 minutes

CLI output formats

Build your own AWP runtime.

AWP is not tied to OpenAgentix. A runtime declares which conformance profiles it implements and which optional features it does not support. A public conformance test suite for manifests is in the repository.

core: Parse and validate manifests, execute the step graph, enforce budgets and permissions.
governance: Ownership, data policy, model policy, approvals, risk levels, environments, policies.
audit: Event envelope, all event types, decision and reproducibility records.
security: Digests, signatures, image pinning, isolation, secret redaction.
mcp: MCP servers as tool sources, action identifiers per tool call.
a2a: Remote agents with verified agent cards.

implementation:
  name: example-runtime
  version: 0.4.0
  url: https://runtime.example.org
conformance:
  awp: v1alpha1
  profiles:
    - core
    - governance
    - audit
  limitations:
    - "audit: integrity mode signed is not supported; hash-chain only"

Conformance profiles · Build your own runtime

AWP is an open specification.

Specification
Open governance
Reference implementation
Conformance tests
Ecosystem

Platforms which support AWP

OpenAgentix: reference implementation, in progress. It does not yet conform to any profile.

Call for implementations

If you build a runtime, validator or tool for AWP, tell us. Listing requires a public statement of the supported conformance profiles. How to be listed

Licenses

Specification text: CC BY 4.0. Code, schemas and conformance tests: Apache-2.0.

AWP is a specification, not a platform. OpenAgentix is one implementation.

Help define the contract.

Read the specification Open an issue Join the discussion

Contact: [email protected]