Introducing the Agentic Workflow Protocol (AWP)

The workflow lock-in problem

Multi-agent AI is moving fast. Frameworks like LangGraph, CrewAI, AutoGen, and Swarm each give you powerful primitives for orchestrating agents — and each one is excellent at what it does. But they all speak a different language. A LangGraph StateGraph is not a CrewAI Crew. A CrewAI crew is not an AutoGen GroupChat. If you build and tune a multi-agent workflow on one framework, you are locked in.

This isn't a criticism of any framework. It's the natural state of a young ecosystem. We've been here before: before Docker, every deployment environment was a snowflake. Before OpenAPI, every REST API needed its own client SDK. Before MCP, every tool integration was a one-off build. In each case, the solution wasn't to pick one framework and mandate it — it was to agree on a portable standard that sits above all of them.

That is what AWP is.

What the industry already has

Two important standards have already emerged for the agentic layer:

Both are genuinely useful and worth adopting. But neither addresses the question of workflow portability: how do you define a multi-agent workflow once, share it, version it, evaluate it, and run it on any framework? That slot is empty.

Introducing AWP

The Agentic Workflow Protocol (AWP) is an open standard for describing, sharing, and executing multi-agent workflows. An AWP workflow is defined in a .awf file — a YAML document specifying agents, their roles and tool access, the execution topology, shared state, and evaluation criteria. Runtime adapters translate .awf files into LangGraph, CrewAI, AutoGen, or any other target. The "P" matters: AWP defines not just a file schema but a contract that runtimes implement to be AWP-compatible.

Here is a minimal AWP workflow for a retail customer-support agent:

name: retail-customer-support
version: "0.1.0"
description: Handles tier-1 customer support for a retail store

agents:
  - id: classifier
    role: "Identify the customer and classify their request type"
    meta_type: profiler
    tools: [get_customer, get_order, find_order_by_id]
    temperature: 0.0

  - id: resolver
    role: "Execute the requested action and confirm resolution"
    meta_type: agent
    tools: [cancel_order, exchange_item, modify_order, return_delivered_item]
    temperature: 0.3

edges:
  - classifier -> resolver

topology: fixed_pipeline

state:
  customer_id: string
  order_id: string
  resolved: boolean

eval:
  type: tau_bench
  benchmark: retail
  weights:
    quality: 0.7
    cost: 0.2
    latency: 0.1

That is the entire workflow definition. Two agents, one edge, a state schema, and evaluation criteria. A runtime adapter reads this file and produces the framework-specific boilerplate — you never write it by hand.

Key design decisions

Runtime adapters

An AWP runtime adapter reads a .awf file and generates executable code (or a runtime configuration) for a specific framework. The adapter is responsible for the mapping — AWP never prescribes how a framework should implement orchestration, only what the workflow intends.

We are building these adapters in the open and actively looking for contributors familiar with each framework. The adapter interface is minimal — a single function that takes an AWP document and returns framework-specific output.

AutoAW as the AWP optimizer

This is where our work at AutoAW connects to AWP. AutoAW applies Genetic Programming to evolve multi-agent workflows — and internally, every gene in the evolutionary population is a valid AWP document stored as a .awf file.

The relationship between AWP and AutoAW is simple:

1. Import. Load any .awf file as the seed gene for a new experiment. AutoAW uses it as the starting point for evolution.
2. Optimize. AutoAW runs hundreds of mutations and evaluations across generations — adjusting prompts, delegation patterns, tool assignments, temperatures — guided by the eval criteria embedded in the .awf file.
3. Export. The best-performing gene is returned as a validated .awf file. No AutoAW dependency at runtime — deploy it on LangGraph, CrewAI, or any other AWP-compatible runtime.

The AWP registry

Portable protocols become truly powerful when paired with a discovery layer. The AWP registry (coming soon at awf.sh) will be a public index of community-contributed .awf files, searchable by domain, benchmark, and fitness score.

Every entry in the registry will include the full workflow spec, the benchmark it was optimized against, and its measured fitness metrics — quality, cost, and latency. Sharing an AWP workflow means sharing not just the topology but the evidence of how well it performs.

What's next

Get involved

AWP is an open proposal. We are publishing the spec and building the first adapters, but we want this to be a community standard — not an AutoAW product. That means:

• If you use LangGraph, CrewAI, or AutoGen and want to help design the adapter interface, reach out.
• If you have opinions on the spec design — types that are missing, fields that are wrong — open a discussion.
• If you have an existing multi-agent workflow you'd like to describe in AWP, try it and tell us where the protocol falls short.