v0.1 Draft

Open Execution Protocol

A coordination layer for AI-driven operations in grocery and QSR. Defining how agents and systems communicate to execute in the physical world.

The Problem
Framework Overview
Specification
Examples
Implementation
Connect

The Problem

AI agents are moving from recommendation engines to coordination systems. They'll soon orchestrate orders, negotiate fulfillment, handle substitutions, and recover from failures across systems that were never designed to work together.

We have standards for product data, transactions, and inventory. But those standards were built for batch updates and human-mediated workflows. They assumed a person would bridge gaps between systems.

AI agents don't work that way. They need to understand real-time operational state, express intent with constraints, negotiate with systems that might say no, and learn from outcomes.

Current standards describe things. Agentic commerce needs standards that describe movement.

No common event language

Systems can't communicate what's happening in real-time operations.

No shared state model

Agents can't reason about where things are in their lifecycle.

No intent negotiation

Agents query and command. They can't negotiate with systems.

No outcome feedback

Without standardized results, agents can't learn or improve.

Framework Overview

The Open Execution Protocol defines a coordination layer that sits above existing operational systems. It provides the common language those systems use to communicate with external participants—AI agents, delivery networks, marketing platforms, and third-party applications.

Design Principles

Event-driven: Communication through events, not polling
Intent-based: Agents express goals with constraints
State-aware: Systems share execution lifecycle status
Outcome-oriented: Every action produces measurable feedback
Vendor-neutral: No platform owns the standard
Incrementally adoptable: Implement components independently

Five Core Components

Canonical Execution Events

A shared vocabulary of operational occurrences. Not "data changed" but "order at risk" or "customer arrived." Verbs, not nouns.

Execution State Model

A shared understanding of where things are in their operational lifecycle. Enables agents to reason about status and coordinate handoffs.

Intent & Action Contracts

Agents express what they want to accomplish. Systems respond with commitments, modifications, or counter-proposals. Negotiation, not just transactions.

Semantic Product Models

Product intelligence beyond SKU numbers. Substitution logic, dietary attributes, freshness windows, and promotional constraints.

Feedback & Outcome Signals

Standardized results that enable learning. Success, partial success, failed—with reason codes and performance data.

Specification

1. Canonical Execution Events

Execution events describe operational occurrences that matter for real-time coordination.

Event Structure

Event Schema

{
  "event_id": "evt_7f3d8a2b",
  "event_type": "ORDER_AT_RISK",
  "timestamp": "2026-02-23T14:32:17.234Z",
  "valid_until": "2026-02-23T14:37:17.234Z",
  "confidence": 0.87,
  "source": {
    "system": "inventory_360",
    "location_id": "store_4521",
    "actor_type": "system"
  },
  "context": {
    "order_id": "ord_9x8y7z",
    "risk_type": "item_availability",
    "affected_items": ["sku_12345"]
  }
}
                    

Order Lifecycle Events

Event Type	Description	Source
`ORDER_CREATED`	New order entered	Commerce/POS
`ORDER_CONFIRMED`	Order accepted and queued	OMS
`ORDER_AT_RISK`	Fulfillment timeline threatened	Inventory
`ORDER_READY`	Order prepared for handoff	Fulfillment
`ORDER_COMPLETED`	Successfully delivered	Fulfillment

Customer & Fulfillment Events

Event Type	Description	Source
`CUSTOMER_ARRIVED`	Customer at pickup location	Geofence/App
`VEHICLE_DETECTED`	Vehicle in pickup zone	Camera/Sensor
`HANDOFF_INITIATED`	Staff beginning delivery	Mobile
`HANDOFF_COMPLETED`	Order transferred	Mobile

Inventory & Operations Events

Event Type	Description	Source
`ITEM_UNAVAILABLE`	Product out of stock	Inventory
`SUBSTITUTION_REQUIRED`	Original needs replacement	Fulfillment
`SUBSTITUTION_PROPOSED`	Alternative suggested	AI/System
`MARKDOWN_TRIGGERED`	Price reduction activated	Waste/Pricing
`STAFF_ASSIGNED`	Associate allocated	Labor

2. Execution State Model

A shared understanding of where things are in their operational lifecycle.

Core States

PLANNED → QUEUED → IN_PROGRESS → COMPLETED

State	Definition	Transitions
`PLANNED`	Intent captured, not actionable	→ QUEUED
`QUEUED`	Waiting for resources	→ IN_PROGRESS
`IN_PROGRESS`	Actively being worked	→ BLOCKED, COMPLETED
`BLOCKED`	Cannot proceed	→ IN_PROGRESS, ESCALATED
`DEGRADED`	Reduced capability	→ COMPLETED
`COMPLETED`	Successfully finished	Terminal
`ABANDONED`	Terminated	Terminal

State Object

State Schema

{
  "entity_type": "order",
  "entity_id": "ord_9x8y7z",
  "current_state": "IN_PROGRESS",
  "state_entered_at": "2026-02-23T14:28:00Z",
  "confidence": 0.92,
  "sub_states": {
    "picking": "COMPLETED",
    "packing": "IN_PROGRESS",
    "staging": "PLANNED"
  },
  "constraints": {
    "deadline": "2026-02-23T15:00:00Z"
  }
}
                    

3. Intent & Action Contracts

Agents express what they want to accomplish. Systems respond with what they can actually do.

Intent Request

Intent Request

{
  "intent_id": "int_abc123",
  "intent_type": "FULFILL_ORDER",
  "requestor": {
    "agent_id": "agent_shopping_assistant",
    "agent_type": "customer_ai"
  },
  "target": {
    "order_id": "ord_9x8y7z",
    "location_id": "store_4521"
  },
  "constraints": {
    "deadline": "2026-02-23T15:00:00Z",
    "acceptable_handoff_modes": ["curbside", "locker"],
    "substitution_policy": "similar_approved",
    "max_substitutions": 2
  },
  "fallbacks": [
    {
      "trigger": "deadline_at_risk",
      "action": "NOTIFY_CUSTOMER"
    }
  ]
}
                    

System Response

System Response

{
  "intent_id": "int_abc123",
  "response_type": "ACCEPTED_WITH_MODIFICATIONS",
  "commitment": {
    "estimated_completion": "2026-02-23T14:52:00Z",
    "confidence": 0.88,
    "handoff_mode": "curbside"
  },
  "modifications": [{
    "type": "substitution",
    "original_item": "sku_12345",
    "substituted_item": "sku_12346",
    "reason": "out_of_stock"
  }]
}
                    

Response Types

Response	Meaning	Agent Action
`ACCEPTED`	Fulfill as requested	Proceed
`ACCEPTED_WITH_MODIFICATIONS`	Fulfill with changes	Review, confirm
`DECLINED`	Cannot fulfill	Try alternative
`COUNTER_PROPOSAL`	Different approach	Evaluate
`PENDING`	Need more time	Wait

4. Semantic Product Models

Product intelligence beyond SKUs—substitution logic, dietary attributes, freshness windows.

Product Schema

{
  "sku": "sku_12345",
  "name": "Organic Whole Milk, 1 Gallon",
  "dietary_attributes": {
    "contains": ["dairy", "lactose"],
    "free_from": ["gluten", "nuts"],
    "suitable_for": ["vegetarian"],
    "not_suitable_for": ["vegan", "lactose_intolerant"]
  },
  "freshness": {
    "shelf_life_days": 14,
    "markdown_trigger_days": 3
  },
  "substitution_rules": {
    "equivalent_products": ["sku_12346"],
    "acceptable_alternatives": [
      {
        "sku": "sku_12350",
        "similarity_score": 0.85,
        "requires_approval": false
      }
    ]
  }
}
                    

5. Feedback & Outcome Signals

Standardized results that enable learning.

Outcome Schema

{
  "intent_id": "int_abc123",
  "outcome_type": "PARTIAL_SUCCESS",
  "results": {
    "items_fulfilled": 8,
    "items_substituted": 1,
    "items_unavailable": 1
  },
  "performance": {
    "estimated_completion": "2026-02-23T14:52:00Z",
    "actual_completion": "2026-02-23T14:58:32Z",
    "variance_seconds": 392,
    "variance_reason": "customer_late_arrival"
  },
  "learning_tags": ["substitution_required", "curbside_successful"]
}
                    

Outcome	Definition
`SUCCESS`	Completed as committed
`PARTIAL_SUCCESS`	Completed with modifications
`FAILED`	Could not complete
`OVERRIDDEN_BY_HUMAN`	Human took control

Use Cases

AI Agent Order Fulfillment

Agent sends FULFILL_ORDER intent with constraints
System returns ACCEPTED_WITH_MODIFICATIONS
Agent confirms, receives commitment
System emits state updates during fulfillment
ORDER_READY triggers customer notification
CUSTOMER_ARRIVED initiates handoff
Outcome signal captures performance metrics

Third-Party Delivery Integration

Delivery platform subscribes to order events
Receives state updates: QUEUED → IN_PROGRESS
Picking completion triggers driver dispatch
ORDER_READY finalizes driver assignment
Coordinated handoff minimizes wait time

Implementation

Transport Options

Webhooks: HTTPS callbacks for events
SSE: Real-time streaming for state
WebSockets: Bidirectional for negotiation
Message queues: Kafka, RabbitMQ for volume

Incremental Adoption

Level	Components	Capability
1 - Observable	Events	See what's happening
2 - Queryable	Events + State	Check current status
3 - Negotiable	+ Intent	Request and negotiate
4 - Intelligent	Full OEP	Coordination with learning

Let's Build This Together

This is early-stage thinking. If you're building in grocery tech, restaurant systems, or retail AI, your input shapes what this becomes.

Get in Touch LinkedIn