Agentic Process Protocol · Draft specification

An open protocol for enterprise processes across AI agents, people, and business systems

Every vendor in the chain governs its own scope. No standard governs the process itself. The Agentic Process Protocol (APP) addresses that gap.

When a process crosses systems, each can record its own part. APP addresses what the enterprise still needs to prove across the whole process: who had authority, what the AI was allowed to do, whether required human review was substantive, what happened, and whether the governing rules changed.

Alongside MCP and A2A

MCP addresses how agents connect to tools. A2A addresses how agents communicate with other agents. The Agentic Process Protocol addresses how a cross-system enterprise process is specified, executed, evidenced, and improved.

Comparison of three coordination boundaries: MCP, A2A, and the Agentic Process Protocol Three side-by-side panels each showing a distinct coordination boundary. MCP addresses agent-to-tool connectivity. A2A addresses agent-to-agent communication. The Agentic Process Protocol addresses how a cross-system enterprise process is specified, executed, evidenced, and improved. THREE DISTINCT COORDINATION BOUNDARIES MCP Model Context Protocol agent tool agent ↔ tool tool connectivity A2A Agent-to-Agent agent agent agent ↔ agent peer communication Agentic Process Protocol this specification agent governed process agent ↔ governed process evidence & oversight contract MCP and A2A address connectivity and communication boundaries. The Agentic Process Protocol addresses how a cross-system enterprise process is specified, executed, evidenced, and improved.

The change in one view

Enterprises today assemble AI-augmented processes across five or six vendor systems. Each vendor governs its own scope. No participant owns the process itself. Below is what changes under the Agentic Process Protocol.

Dimension Today With the Agentic Process Protocol
Process definition Each project defines rules-vs-judgement, review evidence, and compliance obligations differently. A single Process Frame specifies each step, its executing system, and its rule-or-judgement classification, consistently across projects.
Process evidence No shared record of what actually happened across systems. A standardised Process Execution Record (PxER) assembles evidence across all participating systems, linked to the Frame version.
AI scope over time AI-executed steps remain AI-executed; every step keeps its AI cost and its AI risk indefinitely. AI scope shrinks by design. Stable judgement patterns are governed-promoted from AI to rules, so Month 6 cost is structurally lower than Month 1 cost. This is a mechanism the protocol specifies.
Governance Governance is defined and enforced differently in each vendor's scope. Governance is declared once in the Frame and enforced consistently across participating systems, whichever vendor executes the step.
Enterprise-grade posture Confidence in the process is inferred from each vendor's own account. The process itself carries a defensible record for audit, for regulators, and for the enterprise's own review.

The remainder of this site explains how the protocol constructs these outcomes, what it does and does not prescribe, and what each participant in the ecosystem contributes.

One payment exception, seen as one process

A supplier-payment exception can involve an ERP, an AI agent platform, a human approval surface, an identity system, and a payments system. Today, each system records its own action; no participant records the process itself. The Agentic Process Protocol changes that.

One supplier-payment exception under the Agentic Process Protocol Horizontal process view. A Process Frame band spans the top and specifies the governed process. Below it, five step columns, each with the step name, its executing system, and its rule-or-judgement classification. A Process Execution Record band assembles evidence across all five systems. A business-entity band traces the supplier, invoice, and cost centre through the chain. An improvement-loop band at the bottom captures the P-to-D promotion mechanism through which AI scope reduces over time. Illustrative process view · not an implementation claim · not a compliance determination PROCESS FRAME One process specification: every step classified rule vs judgement, controls declared upfront. Invoice ingestion ERP RULE Exception assessment AI agent platform JUDGEMENT Amount-threshold approval Human approval surface RULE Identity check Identity system RULE Payment release Payments system RULE PROCESS EXECUTION RECORD Every step recorded in its system, linked across systems; human judgement captured as evidence. BUSINESS ENTITIES MAPPED The same supplier, invoice, and cost centre traced through the chain; attribution survives migrations, renames, and multi-system references. supplier · one identity invoice · linked to PO cost centre · reconciled APP-4 IMPROVEMENT LOOP As judgement patterns stabilise across many executions, they can be promoted from AI to rules through governed approval. shrinking the AI surface, reducing inference cost, and making rule-based portions explicitly reviewable. RULE Deterministic step JUDG Judgement (AI-based) step Contribution to PxER (not data transfer; the PxER is assembled evidence, not a central hub) Steps illustrate one supplier-payment exception scenario. Actual step count, systems, and classifications are per-deployment.

The Frame is the specification. The PxER is the execution evidence. Entity mapping keeps the record attributable. The improvement loop is how the protocol systematically shrinks the AI surface as patterns stabilise. This is governed change, not automatic learning.

Choose your path

If you're an enterprise CIO, CISO, ERP or AI-platform vendor, regulator, systems integrator, or standards contributor. See /ecosystem, which routes each audience to the parts of the Agentic Process Protocol most relevant to them.

How to participate

The Agentic Process Protocol is a draft under open public review. The site explains the protocol; the repository is where detailed discussion, issue tracking, proposed changes, and decision records live.

Read the draft, discuss on GitHub, propose changes, and follow decision records — a familiar cycle for anyone who has taken part in Linux Foundation or IETF working-group review, adapted for a specification whose consumers are as much enterprise procurement and audit teams as engineers.

Open the repository →

Endorsement is not required. Neither is implementation.

Overview

What APP is and how it works

The Agentic Process Protocol is a protocol, not a product. It specifies what enterprise processes involving AI must be able to demonstrate: what happened, who authorised it, what evidence exists, whether human review was substantive, and whether the governing rules changed. It does not implement, execute, or replace anything.

The protocol concerns itself with a specific kind of process: one that crosses systems, one where at least some steps involve AI-based judgement, and one where the enterprise carries accountability for the outcome even though multiple vendors participated in the execution.

For a fuller framing of the problem, see the Home page or read APP-0 (Protocol Objectives).

The problem the protocol addresses

The problem is not that individual systems don't log what they do. They typically do. What is missing is the record of the composite human + AI process itself. ERPs record deterministic transactions well. AI platforms record their judgement steps. Approval surfaces record their human decisions. None of them records the process as one governed whole, spanning deterministic, judgement, and human-review steps together.

Each vendor has an account of what happened inside its own scope. None has an account of the process. And where vendors do govern the parts they own, they define governance-critical concepts differently. One platform's "human-in-the-loop" is a click-through confirmation; another's is a two-reviewer approval workflow; a third's is a purely automatic acknowledgement. Each is defensible in isolation. None compose into an enterprise-grade view.

The Agentic Process Protocol addresses this by defining a shared governance vocabulary and shared evidence obligations that every participating system honours, while leaving each vendor free to implement its own scope in its own way. The protocol coordinates; it does not replace.

The five governance outcomes

APP-0 specifies five enterprise-facing outcomes a governed process must demonstrate, each stated as a reader-facing question with its APP-0 outcome label alongside.

The five governance outcomes, expressed as reader-facing questions Five numbered cards. Each card carries a reader-facing question and, beneath it, the corresponding APP-0 outcome label. 1: Who was allowed to do this — Authorised Action. 2: How was a high-stakes judgement checked independently — Independent Verification. 3: What was the AI allowed to decide or do — Bounded Agency. 4: What evidence existed as the process ran — Execution-Time Evidence. 5: Who changed the rules, when, and under what approval — Governed Change. 01 Who was allowed to do this? Authorised Action who was permitted to do what, and did they 02 How was a judgement checked independently? Independent Verification evidence produced by a path independent of the actor 03 What was the AI allowed to decide? Bounded Agency what the AI was allowed to decide, and whether it stayed inside those bounds 04 What evidence existed as the process ran? Execution-Time Evidence evidence assembled during execution, not reconstructed after 05 Who changed the rules, when, and how? Governed Change how the rules governing the process evolved, with audit trail

These outcomes are constant across integration-maturity levels; what varies is evidence fidelity. See /adoption for the L1–L4 model.

On human review

A governed process may require human review at specific steps. The Agentic Process Protocol does not attempt to certify that a reviewer "genuinely engaged" (internal mental states are not observable), but it does require evidence designed to distinguish substantive review from a purely ceremonial checkpoint, within stated limits.

The specifics of what constitutes evidence of substantive review are defined in APP-2 and APP-3. Common patterns include behavioural signals (time-on-task within stated bounds), decision divergence (approvals and non-approvals both occur), and traceable rationale (reviewer notes linked to specific evidence surfaced at the point of decision).

AI scope reduces as patterns stabilise

The Agentic Process Protocol classifies each process step as deterministic (rule-based) or judgement (AI-based). As execution evidence accumulates, judgement steps whose outcomes stabilise are governed-promoted to deterministic rules. The AI surface shrinks over time as a structural consequence of using the protocol, not as a hoped-for outcome.

Promotion is not automatic. It requires an explicit promotion event with recorded provenance, whether the rule originated from documented practice or was earned through governed production evidence. For compliance-scoped steps, dual approval is required. The evidence supporting the promotion must itself be verified for integrity and cannot be reused for another promotion. See APP-2 and APP-3 for the full mechanism.

Three consequences follow directly from using this mechanism: fewer AI-executed steps in the process month over month, materially lower AI inference cost per instance by Month 6 than in Month 1, and a process whose rule-based portions become explicitly reviewable rather than opaque. In an industry where AI cost per process typically stays flat or grows with adoption, structural cost reduction is a distinguishing property of the protocol.

Specifications

The Agentic Process Protocol document suite

The Agentic Process Protocol is defined in eleven documents — six normative documents (APP-0 through APP-5) that constitute the protocol proper, and five informative implementation guides (APP-IG-01 through APP-IG-05) that show how the normative material is realised in practice, cross-referenced across the suite, and read by different audiences. All documents are in draft. All are versioned under a coordinated baseline: APP-2026-10-RC1.

The eleven-document Agentic Process Protocol suite Hierarchy of the eleven documents. APP-1 Constitution sits at the top as the constitutional document and overrides all others. APP-0 Protocol Objectives sits below it as normative. APP-2 Core Specification, APP-3 Security, and APP-4 Entity Correlation are three parallel normative documents below APP-0. APP-5 Conformance Profiles sits below them as normative, spanning the width. A separator introduces the informative implementation guides: APP-IG-01 Implementor's Guide, APP-IG-02 Cross-Reference Matrix, APP-IG-03 Worked Example, APP-IG-04 FAQ, APP-IG-05 Objectives Realisation and Assurance. APP-1 · Constitution Governs the entire suite. Overrides all other documents. APP-0 · Protocol Objectives Five enterprise-facing outcomes APP-2 · Core Specification Twelve capabilities. Frame, PxER, L1–L4. APP-3 · Security 14 security domains. Cross-cutting principles. APP-4 · Entity Correlation Tracking real-world entities across systems in the process. APP-5 · Conformance Profiles Declared per role, per integration-maturity level. Partial conformance is explicit, never silent. INFORMATIVE IMPLEMENTATION GUIDES APP-IG-01 Implementor's Guide APP-IG-02 Cross-Reference Matrix APP-IG-03 Worked Example APP-IG-04 FAQ APP-IG-05 Objectives Realisation and Assurance Constitutional Normative Informative

Read the specification on GitHub →

Coordinated baseline APP-2026-10-RC1 release page — available after public baseline release.

The repository is the working source of truth. It contains every document listed below, plus decision records, discussion history, and issue tracking. The section below is a plain-language guide to what each document does; the repository is where you read them.

Normative documents

APP-1 · Constitution. Governs the entire suite. Establishes definitions, priorities, and interpretive rules. Overrides all other documents on interpretive conflict.

APP-0 · Protocol Objectives. States the five enterprise-facing outcomes a governed process must demonstrate: authorised action, independent verification, bounded agency, execution-time evidence, and governed change. Every other normative document exists to make these outcomes achievable and verifiable.

APP-2 · Core Technical Specification. The heart of the protocol. Defines the twelve capabilities APP requires, the two core artefacts (Process Frame and Process Execution Record), and the four integration-maturity levels (L1 through L4) at which participating systems can operate.

APP-3 · Security Architecture. The security domains a governed process must address: identity, authorisation, data protection, incident response, cryptographic controls, and more, spanning fourteen domains in total plus cross-cutting security principles. Not a re-statement of existing security standards; a specification of what a governed process must show at each domain.

APP-4 · Entity Correlation Architecture. How real-world entities (a supplier, a customer, a purchase order) are tracked across the different systems that see them during one process. Without correlation, no shared record can attribute an action to the entity that caused it.

Illustrative example: A supplier ID changes after an ERP migration. APP-4 links the old and new records so payment-exception evidence remains attributable to one supplier across the migration.

APP-5 · Conformance Profiles. The five participant roles (Governance Orchestrator, Telemetry Contributor, Agent Builder Platform, Enterprise Deployer, Field Deployment) and the rules for declaring conformance. Conformance is declared per role, per integration-maturity level. Partial conformance is explicit, never silent.

Informative implementation guides

APP-IG-01 · Implementor's Guide. Practical patterns for implementing the twelve APP-2 capabilities at each L-level. Covers common architectures, boundary decisions, and pitfalls.

APP-IG-02 · Cross-Reference Matrix. The traceability spine. Maps capabilities to roles, roles to L-levels, security domains to capabilities, and objectives to enforcement mechanisms.

APP-IG-03 · Worked Example. End-to-end walkthrough of a governed process (a supplier-payment exception) using APP artefacts. Shows the Frame, the PxER, and the evidence each participant produces.

APP-IG-04 · Frequently Asked Questions. Reference FAQ. The site FAQ at /faq is a subset.

APP-IG-05 · Objectives Realisation and Assurance Guide. How each of the five APP-0 outcomes is realised across the twelve capabilities, and how it is assured across roles and L-levels.

Normative documents establish requirements. Informative documents help implementers meet them but do not add or override requirements.

Every document carries the coordinated baseline label. Cross-document references cite the coordinated baseline, not individual document versions, to eliminate stale-pointer defects across updates.

Ecosystem

What the Agentic Process Protocol means for you

Orientation for each stakeholder type. What the protocol adds, what stays yours, and where to go for depth.

The Agentic Process Protocol adds a composable evidence contract; participants keep the roles, investments, and differentiation they already have. No participant category is anointed as the required control point.

The matrix below summarises what each stakeholder keeps and what the protocol adds. Select a role tab beneath it for depth, including the questions each role commonly raises.

Stakeholder What you keep (not threatened) What the protocol adds
ERP / application vendor Proprietary knowledge graph, agent builder, domain model, intra-system governance, transaction-record authority Cross-system governance composition; your governance data becomes more valuable in an end-to-end context
AI platform / hyperscaler Infrastructure, identity, data platform, agent runtime A process-governance layer you do not need to build; complements MCP and A2A with process semantics
Enterprise (CIO) Vendor choices, existing investments, technology strategy Vendor-neutral governance; audit readiness; vendor-negotiation leverage via conformance transparency
Enterprise (CISO) Security architecture, identity policies, perimeter controls Process-level governance containment, not just infrastructure-level monitoring
Assurer / regulator Every regulatory determination and certification programme; every legal duty A draft vocabulary and evidence model that may become an input to guidance and assessment methodology
Systems integrator / practitioner Delivery methodology, client relationships, domain expertise Reusable Frame libraries; repeatable governance-assessment methodology; recurring governance revenue

Source: APP-IG-01 Roles are illustrative; a single vendor product may play more than one participant role in an APP deployment. Conformance is always declared per role, per L-level, per deployment (APP-5).

Your position. You own the process. You bear the accountability. You choose the vendors. Under the Agentic Process Protocol, you also own the Frame (the governed specification of what should happen) and the PxER (the record of what did happen). The protocol does not change your vendor choices or your architecture; it changes what you can require of them collectively.

What changes for you. A cross-system record of the process, assembled during execution. A shared vocabulary for contracts, procurement, and audit. A per-role, per-L-level conformance model your procurement team can evaluate.

What stays yours. Every process decision. Every vendor selection. Every implementation choice. The protocol is a specification, not a runtime; it does not execute anything, hold anything, or make anything happen.

Questions enterprises commonly raise. (fuller answers on /faq and in APP-IG-01 and APP-IG-04)

  • Does adopting the protocol lock me into a particular vendor?
  • What is the minimum viable deployment?
  • How does this compose with our existing ISO/IEC 42001, NIST AI RMF, or EU AI Act work?
  • What does my CISO need to see before signing off?

Where to go next. For a plain-language overview, /overview. For the five outcomes a conformant deployment is designed to deliver by leader (CAE, CFO, COO, CIO, Head of AI Governance), /adoption. To submit feedback as an enterprise, /contribute.

Your position. You build application products that run enterprise processes end to end: the ERP, the CRM, the HR platform, the industry vertical. Your platform is where the transaction sits and where the record of authority lives. Under APP-5, your product typically plays the Telemetry Contributor role at L3, contributing intra-application execution telemetry to the shared record. Enterprise platforms with broader governance capability may also implement Governance Orchestrator features.

What changes for you. A standard vocabulary customers can procure against, without dictating your architecture. Per-role, per-L-level conformance claims that replace global "we do governance" statements. Support for the dominant-anchor deployment pattern, where your platform coordinates governance across the systems it touches. Governance data becomes more valuable when it composes into an end-to-end record instead of stopping at your application boundary.

What stays yours. Your proprietary implementation, your differentiation, your roadmap. Your transaction record is the authoritative source for business data; the protocol does not replicate it.

Questions ERP and application vendors commonly raise. (fuller answers on /faq and in APP-IG-01)

  • Why would I adopt a protocol that makes my governance data portable?
  • What does Telemetry Contributor at L3 actually require from my engineering team?
  • What's the relationship to my knowledge graph and my agent builder?
  • Can we start with Retrospective conformance and progress from there?

Where to go next. For a plain-language overview, /overview. For the five participant roles and integration maturity model, /adoption. To submit feedback as an ERP or application vendor, /contribute.

Your position. You build infrastructure: cloud, identity, data platform, agent runtime, orchestration. Under APP-5, your product typically plays the Agent Builder Platform role, building and running agents that consume Frame definitions and execute individual steps. Platforms with broader governance capability may implement Governance Orchestrator features, holding the Frame, assembling the PxER, and enforcing D/P classification.

What changes for you. A process-governance layer you do not have to build. Standard hooks for tenant-level policies, HITL approval surfaces, and evidence contribution — integration points for your agent runtime, not a replacement of it. Support for the no-anchor deployment pattern, where the Frame coordinates and multiple agent builders participate as peers. Per-role, per-L-level conformance claims customers can evaluate against specific deployments.

What stays yours. Your infrastructure, your agent runtime, your model choices, your identity system, your data platform. The protocol does not prescribe how you build agents or how you serve them.

Questions AI platform vendors commonly raise. (fuller answers on /faq and in APP-IG-01)

  • How does the protocol compose with MCP for tool connectivity and A2A for agent-to-agent communication?
  • What does the Agent Builder Platform role require?
  • Can a single product play both Agent Builder Platform and Governance Orchestrator?
  • How does this relate to my agent runtime and my agent registry?

Where to go next. For a plain-language overview, /overview. For the five participant roles and integration maturity model, /adoption. To submit feedback as an AI platform or hyperscaler, /contribute.

Your position. You assess whether enterprise processes involving AI meet applicable standards, frameworks, or regulations. The protocol is not itself a regulatory framework and does not issue determinations.

What changes for you. - A draft vocabulary and evidence model regulators and assessors may examine as a potential input to future guidance or assessment methodology. - A structured way to compare what different vendors demonstrate at each L-level, with vendor claims explicitly separated from independently verifiable evidence. - Informative crosswalks in APP-IG-05 between APP outcomes and ISO/IEC 42001, NIST AI RMF, and the EU AI Act, presented as an input for qualified review, not as an endorsed mapping.

What does not change. Any regulatory obligation. Any legal duty. Any certification programme you run today.

Questions assurers and regulators commonly raise. (fuller answers on /faq)

  • What is the current status of conformance and independent assessment?
  • Who governs the specification over time?
  • What is the intellectual-property posture, and can the specification be relied on?
  • How are crosswalks to ISO/NIST/EU AI Act intended to be used?

Where to go next. For a plain-language overview, /overview. For stewardship posture and IP terms, /governance. To submit feedback as an assurer, regulator, or security researcher, /contribute.

Your position. You deliver enterprise process work: Frame development, implementation, telemetry contribution, deployment methodology. The protocol gives you a standard artefact set to work with, not a licensing programme to opt into.

What changes for you. - A shared vocabulary for Frame authorship and a library-friendly artefact model. Frames can be templated and reused. - A conformance model that lets you declare the L-level and role your engagement contributes to, honestly, without marketing overclaim. - New service lines the protocol makes structurally possible (APP-IG-01): governance-as-a-service on live conformance deltas; AI-cost optimisation identifying promotable judgement steps; PxER analytics as a data-driven, not opinion-based, practice; C2 compliance-template authorship for industry- or region-specific overlays.

What stays yours. Your methodology. Your engagement model. Your client relationships.

Questions SIs and practitioners commonly raise. (fuller answers on /faq and in APP-IG-01)

  • How does this change my delivery model?
  • What new service lines does the protocol enable?
  • How do I position governance work distinct from build work?
  • What do I need to demonstrate to declare conformance credibly?

Where to go next. For a plain-language overview, /overview. For the worked example and implementor's guide, /specifications. To submit feedback as a systems integrator or practitioner, /contribute.

Adoption

Implementation and conformance

Implementation depth: integration maturity, participant roles, conformance model, and what a conformant deployment is designed to deliver by leader.

The Agentic Process Protocol is a draft. Conformance is defined in APP-5 as self-declared, per role, per L-level, per deployment. Independent-assessment and certification programme design is a working-group decision (see below).

The four integration-maturity levels

A governed process interfaces with applications that have very different governance capabilities. The four integration-maturity levels (L1 through L4) account for this diversity. In a single process, we expect systems at multiple levels to co-exist; conformance is declared per role, per L-level, per system.

Integration maturity: same outcomes, varying evidence fidelity Governance outcomes are constant across L1 through L4. Evidence fidelity increases with integration depth. L1 (Legacy) supports external observation at screen or RPA level for applications that cannot emit governance evidence. L2 (Standard) integrates at the application boundary via APIs or webhooks. L3 (Instrumented) provides intra-application telemetry so per-invocation conformance is observable. L4 (Governance-native) applications emit governance artefacts structurally as part of their execution. GOVERNANCE OUTCOMES — CONSTANT AT EVERY LEVEL Authorised Action · Independent Verification · Bounded Agency · Execution-Time Evidence · Governed Change L1 Legacy external observation Observed from outside the systems being governed. Per-invocation status: typically unverifiable — declared in scope. L2 Standard application boundary Governance and agents may both orchestrate. ERP-anchored, CRM- anchored, and similar application-boundary architectures. L3 Instrumented intra-app telemetry Per-invocation conformance determination. MATCH / MISMATCH status observable per step. L4 Governance-native Governance evidence produced structurally. Systems being governed emit governance artefacts natively as part of their execution. Evidence fidelity Lowest Highest Higher fidelity does not mean better for every deployment. L-level applicability is a per-deployment decision based on architecture and evidence needs.

L1 · Legacy · external observation. The governed process is observed from outside the systems being governed, at screen or RPA level. Evidence is assembled from external observation. Per-invocation conformance is typically not verifiable and must be declared in scope. This level covers legacy applications that cannot emit governance evidence.

L2 · Standard · application boundary. Governance and agents may both orchestrate. Evidence is assembled at application interaction points (APIs, webhooks). L2 is a design-target pattern consistent with many application-boundary architectures (ERP-anchored, CRM-anchored, or similar) where an existing enterprise platform is a natural pivot point for both execution and evidence.

L3 · Instrumented · intra-application telemetry. Per-invocation conformance determination becomes possible using instrumentation inside participating applications. MATCH / MISMATCH status is observable per step.

L4 · Governance-native. The systems being governed emit governance artefacts as part of their execution. Evidence fidelity is highest; the governance record is produced structurally rather than assembled post-hoc.

Higher L does not mean "better" in every deployment. L-level applicability is a per-deployment decision based on architecture, evidence needs, and the systems that participate. L4 requires application changes many enterprise applications will not make in the near term. That is fine. The same five outcomes apply at every level; what varies is evidence fidelity and the scope that can be independently demonstrated.

The five participant roles

APP-5 defines five participant roles. Conformance is declared per role, per L-level. A single vendor product may play more than one role.

The five participant roles defined in APP-5 Five participant-role boxes arranged around a central Governance Orchestrator hub. Enterprise Deployer authorises from above. Agent Builder Platform submits agents from the left. Telemetry Contributor feeds execution evidence from the right. Field Deployment prepares source documents, integration, credentials, and activation ordering from below. The Governance Orchestrator hub holds the Process Frame and assembles the Process Execution Record. FIVE PARTICIPANT ROLES (APP-5) ENTERPRISE DEPLOYER The organisation deploying the governed process. Configures tenant policies · compliance levels · degradation behaviour authorises · sets policy AGENT BUILDER PLATFORM Builds and runs agents that consume the Frame and execute steps. Submits changes via governance gate agents GOVERNANCE ORCHESTRATOR The central hub Holds the Process Frame Assembles the PxER D/P enforcement · HITL surfaces telemetry TELEMETRY CONTRIBUTOR Contributes intra-application execution telemetry. Contributes evidence; does not orchestrate activates & provisions FIELD DEPLOYMENT Team or function performing initial deployment setup: source preparation · L1 integration · credential provisioning · activation ordering

Governance Orchestrator. A new capability the protocol introduces. Holds the Frame version, assembles the PxER, enforces D/P classification, provides HITL approval surfaces, and produces learning outputs. Not a single-vendor category: existing ERP vendors, AI platforms, hyperscalers, and new dedicated vendors may all build APP-compliant orchestrators. Telemetry Contributor. Contributes intra-application execution telemetry to PxER assembly. Typically ERP or enterprise platforms. Contributes evidence but does not orchestrate governance. Agent Builder Platform. Builds and runs agents that consume Frame definitions and execute individual steps. Submits changes through the governance gate. Invokes governed processes but does not manage the governance layer. Enterprise Deployer. The organisation deploying governed processes. Configures tenant-level policies, compliance levels, jurisdictional privacy tiers, and degradation behaviour declarations. Field Deployment. The team or function that stands up a governed process: preparing source documents, wiring integrations, provisioning credentials, and sequencing activation. Typically performed by systems integrators, application vendors, or an enterprise's own deployment team.

Conformance and independent assessment

Self-declared conformance is defined in APP-5. A conformance statement carries the implementation name and version, declared role(s), declared L-level per scope, per-dimension status, and, where partial, the list of unmet MUST-level requirements. Partial is fine. A "Conformant" aggregate that masks a non-conformant dimension is itself a conformance violation.

Independent assessment and any certification, accreditation, or conformance-mark programme are decisions for the working group when it forms. APP-IG-04 is the planned home for the substantive discussion. Vendors may describe their products today as implementing specific capabilities at specific L-levels for specific roles; that is a factual product statement.

Five outcomes a conformant deployment is designed to deliver, by leader

One defensible record. CAE / CCO / CRO / General Counsel. Every process run leaves one record across every participating system: who authorised what, what the AI decided or executed, which human reviewed and on what evidence. Assembled during execution, not reconstructed from vendor logs after the fact. Designed for audit, subject to the working group defining what counts as independent assessment.

AI cost designed to fall. CFO / CIO. Every step is declared deterministic or judgement. Stable judgement patterns are governed-promoted from AI to rules, so Month 6 inference cost is structurally lower than Month 1. This is not a bet on efficiency gains but a mechanism the protocol specifies. See /overview for how the promotion works.

Vendor-neutral process ownership. CIO / Sourcing / Procurement. The process is specified in an open, vendor-neutral format the enterprise owns, separate from any vendor's runtime. Vendors implement roles; the specification of what the process must do lives with the enterprise. Vendor substitution does not require re-specifying governance. Realising this in a live deployment requires multi-vendor conformance, which is not yet in production anywhere.

Predictable operational behaviour. COO / Operations lead. Rules execute as rules. AI intervenes only in steps declared as judgement. Deviations from the Frame surface for review at the moment they occur. Outage and degradation behaviour is declared upfront, not left to emerge under load. What the process should do is separable from what happens when a participating system fails.

Governance settled per process, not per project. CIO / Head of AI Governance. One Frame per process, versioned and reused across projects. Change goes through the Frame's own governance, not through per-project redefinition. Frame reuse across processes with similar shape is a design goal, not a delivery date.

Intended outcomes of a conformant deployment, not guarantees or certification. The protocol does not change model accuracy or vendor pricing. Enterprises keep ownership of their processes, controls, and systems.

Contribute

Help shape the draft in public

Engagement: what the draft is asking for now, from whom, and how to submit it.

The Agentic Process Protocol is a draft protocol suite under pre-working-group review. The website explains the protocol; the repository is where detailed discussion, issue tracking, proposed changes, and decision records live.

For a broader orientation on what the protocol may add for your stakeholder type before diving into the asks below, see /ecosystem.

You do not need to endorse the protocol, implement it, or join a future working group to contribute feedback.

Open the repository →

GitHub Discussions — opens with the public baseline release.

What the draft is asking for now

Feedback is welcome from anyone. The asks below are sharpened by stakeholder because different participants surface different weaknesses in the draft. Categories are not exclusive, and any form of substantive input is useful.

Enterprises (CIO, CISO, Head of AI Governance, Head of Process)

ERP / application vendors (SAP, Oracle, Workday, and comparable enterprise-platform providers)

AI-platform and agent-framework vendors (hyperscalers, agent runtimes, orchestration platforms)

Systems integrators and practitioners

Assurers, regulators, and security researchers

Suggested deliverable form. A GitHub Discussion for open questions and scenarios. An Issue for a specific defect, ambiguity, or concern. A Proposal for a concrete change. A Frame template or worked-example contribution if you have one. Any of the above in your own format if none of the templates fit. The repository is a public forum, not a submission funnel.

No endorsement is required to contribute. Participation does not imply adoption.

How review works

Three levels of engagement, each with its own template:

  1. Discussion. Questions, use cases, or interpretation challenges. No proposed normative change required. Use the Discussion category on the repository.

  2. Issue. An identified contradiction, ambiguity, missing requirement, impracticality, or security/assurance concern. Must cite the document and section. Use the Issue template.

  3. Proposal. A concrete change request. Must state the normative impact, the documents affected, backward-compatibility effect, implementation impact, and one alternative considered. Use the Proposal template.

Every substantive change is captured in the DECISIONS/ folder with date, issue link, alternatives considered, and rationale.

On process formalisation. The three-mode flow above is aligned with Linux Foundation-hosted-project norms and is appropriate for pre-working-group public review. As the working group forms, the substantive-change process is expected to formalise into an enhancement-proposal mechanism (in the pattern of the MCP SEP or Kubernetes KEP processes) with defined review, comment, and approval stages. That transition will be published before it takes effect.

Response expectations

We aim to respond to repository issues within five business days and to email within five business days. This is an aim, not a service-level commitment; a working-group process would be expected to publish a firmer response policy at formation.

About the interim custodian

The Agentic Process Protocol is currently stewarded by Vach AI Limited during the pre-working-group review phase.

Decision-making, today. Substantive changes are decided by the interim custodian pending working-group formation, with public rationale recorded in DECISIONS/. Review inputs are logged in the repository.

Decision-making, after WG formation. A formal working group will be convened following the pre-working-group review period. The charter — to be published before formation — will establish decision-making rights, voting or consensus procedures, and appeal mechanisms. Interim-custodian decision-making rights end at working-group formation.

Vach AI Limited authored the current draft. Working-group formation transfers authorship to the participant community under the published charter.

See /governance for IP posture, non-endorsement, security, and privacy.

Contact

GitHub is the primary channel for every question, comment, disagreement, and contribution about the Agentic Process Protocol. Public technical review belongs in the repository; email is an exception path.

For matters that cannot go through a public issue, use the role address for the purpose:

Governance

Stewardship, IP posture, and disclosures

IP terms, non-endorsement rule, and the two exception channels that cannot go through a public issue. Interim-custodian posture and decision-making status live on /contribute.

Current stewardship

The Agentic Process Protocol is currently stewarded by Vach AI Limited (Interim Custodian), Dubai International Financial Centre, during the pre-working-group review phase. Long-term intent: neutral standards-body governance, presently anticipated as the Linux Foundation's Agentic AI Foundation (AAIF) or a comparable body, subject to working-group agreement and receiving-body acceptance. Full posture on /contribute.

IP posture

Full contribution terms, versioning discipline, baseline cadence, and changelog live in the repository (IP-POLICY.md, CONTRIBUTING.md, CHANGELOG.md, CODE_OF_CONDUCT.md). On matriculation to a successor foundation, these terms are replaced by the foundation's equivalent instruments; contributions made under these terms remain valid, with rights transferring intact.

Non-endorsement rule

Participation in review of the Agentic Process Protocol does not imply endorsement of the draft by any participant's employer, and does not create a commercial relationship between the participant, the interim custodian, or any subsequent standards body. Participants speak in their own capacity unless they explicitly note otherwise.

Security disclosure

For suspected security defects in the specification, in a reference implementation, or in the website: write to security@agenticprocess.org. Do not open a public GitHub issue for suspected security defects.

We aim to acknowledge receipt within two business days and to respond with an initial assessment within ten business days. This is an aim, not a service-level commitment.

If a report affects a specific participating vendor's implementation, not the specification itself, we will help route it to the vendor's security team and keep the reporter informed.

Consultation privacy notice

The site collects only the information necessary to operate it. The public consultation is a separate data-processing activity; the consultation privacy notice governs how personal data submitted through issues, discussions, and pull requests is handled.

Data controller: Vach AI Limited (Interim Custodian), Dubai International Financial Centre.
Data-subject requests and privacy inquiries: privacy@agenticprocess.org.

Full text of the consultation privacy notice is in the repository (APP_Consultation_Privacy_Notice) and will render here as a linked page before public consultation opens.

FAQ

The APP-IG-04 Frequently Asked Questions is the topic-based long-form reference, grouped into topics such as multi-application execution, conformance and certification, adoption pathways, and cross-system evidence assembly. This page carries the highest-friction cross-cutting questions and a set of role-specific ones underneath, chosen because they surface repeatedly in early conversations with enterprises, vendors, assurers, and practitioners and are best answered once, in public, rather than five times in private.

Is the Agentic Process Protocol a standard? No. It is a draft open specification under pre-working-group review. It is not endorsed or recognised by any standards body.

Who wrote it? The current draft was authored by Vach AI Limited acting as interim custodian. Working-group formation will transfer authorship to the participant community under a published charter. See /governance.

What is the status of conformance and certification? Self-declared conformance is defined in APP-5 today. Independent-assessment, certification, accreditation, and any vendor-mark or badge programme are decisions for the working group when it forms. APP-IG-04 is the planned home for the substantive discussion.

How does the Agentic Process Protocol relate to MCP, A2A, and other agent protocols? MCP addresses agent-to-tool connectivity. A2A addresses agent-to-agent communication. The Agentic Process Protocol addresses process-governance evidence across the participating systems. It does not replace transport, tool, or agent-communication protocols; it specifies what evidence a governed process must produce regardless of which of them are used underneath.

How does it relate to ISO/IEC 42001, NIST AI RMF, and the EU AI Act? The Agentic Process Protocol is designed to produce evidence artefacts that enterprises and assessors may map to applicable frameworks; it is not itself a compliance framework. Crosswalks in APP-IG-05 are informative and subject to qualified legal review; they are not endorsed by the referenced framework authors.

Does it require a specific model, workflow engine, or vendor? No. It defines the evidence and controls a governed process must demonstrate. Products remain free to choose how they execute it. Multiple vendors can play the same role in a deployment; a single vendor product can play multiple roles.

Does it require enterprises to hand data to a central hub? No. It defines a shared governance contract, not a central data hub. Evidence is assembled by the Governance Orchestrator in the Field Deployment scope. Nothing requires evidence to leave the enterprise's control.

Is it a compliance guarantee? No. This is a draft. Nothing on this site is a compliance statement. Compliance with any regulation or framework is a determination for qualified counsel and, where applicable, competent authorities. Read that twice.

Does adopting the protocol lock me into a particular vendor? No. The five participant roles (APP-5) can be played by different vendors and different combinations of vendors. Multiple vendors can play the same role in a deployment. Your vendor choices remain yours.

What is the minimum viable deployment? The protocol supports partial adoption. An enterprise can start at L1 or L2 with a single process, declare partial conformance explicitly (APP-5), and progress. APP-IG-01 walks through the typical enterprise trajectory.

How does this compose with our existing ISO/IEC 42001, NIST AI RMF, or EU AI Act work? As a source of evidence artefacts, not a replacement. APP-IG-05 provides informative crosswalks intended as input to your existing framework work under qualified legal review, not as a compliance mapping.

What does my CISO need to see before signing off? the security architecture spec covers the fourteen security domains a governed process must address. APP-IG-01 is the CISO-focused walkthrough. Nothing in the protocol requires enterprise data to leave the enterprise's control.

How does AI-scope reduction actually work? Stable judgement patterns can be promoted to deterministic rules with recorded provenance (APP-2). For compliance-scoped steps, dual approval is required. Promotion is governed, evidence-backed, and reversible, not automatic learning. Over time, the AI surface shrinks where patterns warrant.

Will the protocol make my application data portable? No. The protocol standardises the governance wrapper (D/P classification, compliance constraints, HITL requirements, accountability), not your business data. Your application remains the authoritative source for complete transaction records. Your knowledge graph, transaction model, and domain model remain proprietary.

Is Governance Orchestrator a single-vendor category?
No. The protocol defines what a Governance Orchestrator must do; it does not name any vendor as the required one. Existing ERP vendors, AI platforms, hyperscalers, and new dedicated vendors may all build APP-compliant orchestrators.

Can I use the protocol for processes inside a single application?
Yes. The primary purpose is cross-system governance, but nothing prevents intra-application use. A vendor may standardise on the protocol internally so that the same orchestrator framework serves both single-app and multi-app deployments. One governance layer for both.

Can't I extend my own framework to govern cross-system processes via A2A / MCP? You can orchestrate cross-system. You cannot govern cross-system unilaterally: governance authority stops at your application boundary, PxER assembly requires telemetry from systems you do not control, and inter-system compliance constraints cannot be owned by any single vendor. APP-IG-01 walks through the four ceilings in detail.

What does L3 adoption actually require? For a Telemetry Contributor at L3, APP-5 Appendix A defines a specific per-role requirement set covering contribution-format compliance, contributor authentication, evidence-tier declaration, and LITL defence on your own approval surfaces. You do not become responsible for PxER assembly, Frame lifecycle, or learning outputs.

Can we start with Retrospective conformance and progress from there? Yes. The protocol defines multiple conformance profiles declared per scope. Multi-profile per scope is permitted. Partial conformance is valid but must be declared. See APP-5.

How does the protocol relate to my agent runtime and my agent registry? Your agent runtime manages agent lifecycle: registry, monitoring, scaling. The protocol adds process governance semantics on top: which process, which step, under which Frame, with what evidence. It complements the runtime; it does not replace it.

Is the protocol itself a compliance framework? No. It is an evidence-and-vocabulary specification. It produces artefacts that assessors and regulators may examine as inputs to their own methodologies.

What is the intellectual-property posture? Contribution terms adopt the Linux Foundation Community Specification License 1.0 (CSL 1.0) with an APP-specific preamble. Copyright licence for the specification text is CC BY 4.0. See /governance.

Who decides what enters future versions? The interim custodian during pre-working-group review; the working group after formation, under a published charter. Decisions are recorded publicly in the DECISIONS/ folder in the repository.

Are the crosswalks to ISO/IEC 42001, NIST AI RMF, and the EU AI Act endorsed? No. They are informative guidance in APP-IG-05, subject to qualified legal review, and are not endorsed by any of the referenced framework authors.

How does this change my delivery model? Delivery shifts from construction to configuration. Reusable Frame libraries replace per-engagement process capture. The governance assessment (gap analysis → Frame design → L2 deployment) becomes a repeatable methodology. APP-IG-01 covers this in depth.

What new service lines does the protocol enable? Five distinct categories (APP-IG-01): governance-as-a-service on live conformance deltas; independent conformance-assessment methodology (as the working group defines what counts); AI-cost optimisation identifying promotable judgement steps; PxER-based process analytics and mining; and C2 compliance-template authorship for industry- or region-specific overlays.

What is the current status of a conformance-assessment programme? Self-declared conformance is defined in APP-5 today. Independent assessment and certification programme design is a working-group decision. APP-IG-04 will be the substantive discussion venue.

How should I position governance work distinct from build work? The protocol makes the distinction structural. Frame authorship, conformance assessment, and PxER analytics are governance work, priced and staffed differently from integration build. The conformance model (per role, per L-level, per scope) gives you a defensible way to describe each engagement.