An open protocol for enterprise processes across AI agents, people, and business systems
Each participating system governs its own scope. The enterprise remains accountable for the whole process, but its evidence is fragmented across those systems. 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 actually 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. APP addresses how a cross-system enterprise process is specified, executed, evidenced, and improved.
APP is a draft protocol, not an agent runtime or workflow product. Existing systems continue to execute the work.
The change in one view
Enterprises today assemble AI-augmented processes across multiple vendor systems, each governing its own scope. The enterprise is accountable for the whole process, but the evidence sits in fragments across those systems. Below is what changes under APP.
| Dimension | Today | With APP |
|---|---|---|
| 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. |
| Process evidence | No shared record of what actually happened across systems. | A standardised Process Execution Record (PxER) assembles evidence across participating systems, linked to the Frame version. |
| AI scope over time | AI-executed steps remain AI-executed; each step continues to carry its AI cost and risk. | Stable judgement patterns can be converted to approved rules through reviewed change. For each converted step, the AI call is removed from the process. |
| Governance | Governance is defined and enforced differently in each vendor's scope. | Governance is declared once in the Frame and consistently applied across participating systems. |
| Enterprise-grade posture | Confidence in the process is inferred from each vendor's own account. | The process carries a defensible record for audit, for regulators, and for internal review. |
One payment exception, seen as one process
An ERP flags an invoice exception. An AI-assisted service assesses it. A person reviews the proposed decision where required. The payment system acts on the authorised outcome.
The Process Frame describes the intended steps and controls. The PxER records the actual run and links it to the relevant transactions. The question is not only whether the payment completed, but whether the process followed its approved rules and authority.
This is an illustrative scenario, not an implementation or compliance claim.
Find your starting point
See Who APP is for for your audience perspective, Getting started for an early-adopter route, or FAQ and glossary for common questions.
The draft is open for review. You do not need to endorse or implement it to contribute.
Overview
Define the process. Distinguish rules from judgement. Record the execution.
Getting an agent to complete a task does not, by itself, establish who authorised its decisions, whether required review occurred, or whether the surrounding business process remained within its controls.
APP connects the intended process with evidence of its execution. It leaves model choices, agent frameworks, and execution products to implementers.
Process Frame: what should happen
A Process Frame is the structured definition of a process. It identifies its steps, dependencies, executing systems, intended D/P classification, and accountable owners. Applicable controls and review requirements provide the governance context.
A Frame describes the process definition, not one transaction. Each actual run has its own execution record linked to the relevant Frame version.
D/P classification: rules versus judgement
Deterministic (D) work follows a known rule without inference. Probabilistic (P) work involves judgement, interpretation, or reasoning.
Checking an invoice against an approval threshold is rule-based work. Assessing whether an unusual invoice exception is justified requires judgement. Planning how to resolve a complex case may also be judgement-dependent; it is not limited to a single decision inside a fixed workflow.
The Frame declares the intended execution type. The PxER records the observed type where it can be established. If a step meant to follow a rule instead uses inference, the difference is a governance signal requiring review.
D/P is not simply a label for "AI product" versus "non-AI product." The relevant question is how the work executes.
Did the step run as intended?
Normal case.
| In the approved Frame | In the execution record |
|---|---|
| "Check the amount against the approved threshold." | A rules engine performed the check. |
| Intended: rule-based | Observed: rule-based |
Deviation.
| In the approved Frame | In the execution record |
|---|---|
| "Check the amount against the approved threshold." | An AI model interpreted whether approval was needed. |
| Intended: rule-based | Observed: judgement-dependent — governance signal for review |
A difference becomes a governance signal for review. Where execution cannot be established, that limitation is recorded explicitly, not treated as a match.
PxER: what actually happened
The Process Execution Record captures one process run: which steps executed, in which systems, when, under which process definition, and with what available evidence of authority, decisions, and oversight.
It links to source-system transactions rather than replacing the business records those systems maintain. Relevant business identifiers can be linked across steps through entity correlation.
The record is built during execution. Where internal activity cannot be verified, the limitation remains explicit.
Human review: more than an approval click
When review is required, recording "approved" may not establish what the reviewer considered. APP calls for evidence designed to distinguish substantive review from a ceremonial checkpoint, within observable limits.
It does not certify a person's internal mental state or prescribe one approval interface.
AI scope reduces as patterns stabilise
APP classifies each step as deterministic or judgement. As execution evidence accumulates, judgement steps whose outcomes stabilise can be converted to deterministic rules through reviewed change. The number of steps using AI falls over time as a consequence of using the protocol — not as automatic learning, and not on a timeline the protocol can promise.
Promotion is not silent. It requires an explicit 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 and cannot be reused for another promotion.
The practical consequence: fewer AI-executed steps in the process over time, and process portions that become explicitly reviewable rather than opaque. Whether this reduces AI inference cost in a specific deployment depends on the process, the evidence available, and the implementation.
Five questions a governed process should answer
- Authorised Action. Who was allowed to act?
- Independent Verification. How was consequential judgement independently checked where required?
- Bounded Agency. What was the AI allowed to decide or do?
- Execution-Time Evidence. What evidence existed as the process ran?
- Governed Change. Who changed the rules, and under what approval?
These are APP's governance objectives. The same five apply at every integration maturity level; what varies is what can be observed, enforced, and independently demonstrated.
Specifications
Choose your reading depth
Start with a plain-language guide, examine the specific requirements, or explore an illustrative artefact. The website introduces APP; the repository contains the detailed documents and the review record.
Current website reference baseline: APP-2026-10-RC1. All documents are drafts.
Normative documents
APP-0 — Protocol Objectives. States the five enterprise-facing outcomes a governed process must demonstrate.
APP-1 — Protocol Constitution. Governs the entire suite. Establishes definitions, priorities, and interpretive rules.
APP-2 — Core Technical Specification. Defines the twelve protocol capabilities, Process Frame, PxER, D/P classification, and the four integration maturity levels.
APP-3 — Security Architecture. The fourteen security domains a governed process must address, plus temporal activation ordering.
APP-4 — Entity Correlation Architecture. How real-world entities are tracked across systems during one process.
APP-5 — Conformance Profiles. The five participant roles and the rules for declaring conformance per role, per L-level, per scope.
Informative implementation guides
APP-IG-01 — Implementor's Guide. Practical patterns for implementing APP capabilities at each L-level.
APP-IG-02 — Cross-Reference Matrix. The traceability spine across the normative suite.
APP-IG-03 — Worked Example. End-to-end walkthrough of a governed process using APP artefacts.
APP-IG-04 — Frequently Asked Questions. The topic-based reference FAQ, currently covering multi-application execution. The website FAQ provides shorter, audience-specific introductory answers; the two have distinct scopes.
APP-IG-05 — Objectives Realisation and Assurance Guide. How each APP-0 outcome is realised across capabilities, roles, and L-levels.
Plain-language guides
Shorter companion guides to the normative suite, suitable for first reading. Browse the guides/ folder.
Illustrative reference artefacts
APP-R1 — Frame Schema. A reference JSON schema realisation of the Process Frame, with author's notes and a worked JSON example. Non-normative.
APP-R2 — MCP Binding Reference Design. A reference binding of the APP integration surface to the Model Context Protocol transport. Non-normative.
Normative documents establish requirements. Informative documents help implementers meet them. Illustrative reference artefacts show one concrete way to satisfy specific requirements; they carry no conformance obligation.
Ecosystem
Your agentic AI work, viewed as an accountable process
APP is intended to complement the agentic systems you build, buy, deploy, or assess. Select your audience to see where the draft fits. These audience groups are navigation aids, not technical conformance roles.
You may already be piloting agents, evaluating models, or enabling agents supplied by your ERP and application vendors. The immediate challenge is getting useful work done reliably.
As that work moves towards production, the questions broaden: what may the agent decide, who remains accountable, what requires review, and what evidence will be available when risk, audit, or legal teams examine the process? Today, each system can explain its own activity, but a consistent, defensible account of the whole process still has to be assembled across them. That gap is what APP addresses.
APP provides a draft structure for addressing those questions during project design rather than leaving the evidence requirements to a later reconstruction exercise.
For security teams, APP builds process-level protections into the design: agent identity and session scope, Frame and evidence integrity, approval-surface protection, and the integration surface itself. These complement, not replace, the enterprise security programme.
Can we start today? Yes. Pick one agentic project already in flight, define its Frame, map available evidence from your current systems, and declare what you cannot verify. Enterprise FAQ → · Early-adopter route →
Your agentic offering may combine a chat interface, agent tools, deterministic workflows, AI reasoning, and application-specific permissions. APP does not ask you to abandon those capabilities.
The additional question is how a customer can relate your agent's activity to an accountable business process, especially when that process touches other applications and agents.
APP defines a shared process-and-evidence contract. You retain your execution engine, domain model, user experience, and authoritative transaction records. Where your application contributes internal execution evidence, customers can assess more than an external completion signal.
What's the smallest step we can take? Evaluate one process your product participates in. Map what evidence your current interfaces expose and what would need a dedicated contribution interface. Application vendor FAQ →
Your stack may already plan tasks, call tools, coordinate agents, and trace execution. Those capabilities help explain the agent's activity. Enterprise review also needs to connect it to an approved process, its controls, and its business outcome.
APP supplies the shared specification and evidence obligations; your platform supplies or integrates the implementation. It does not replace your runtime, models, orchestration, or developer tools.
Does MCP connectivity equal APP conformance? No. MCP addresses tool access; APP addresses process governance and evidence. The two complement each other. AI platform FAQ →
Your agentic projects may centre on making models, vendor agents, tools, and transaction systems work together. A successful demonstration is an important milestone; a production process also needs defined authority, review, recovery, and evidence.
APP offers a common structure for those delivery concerns. It can inform process design and evidence requirements within a current engagement, before every participating vendor implements it natively.
What becomes a new service line? Frame authorship, governance implementation around available interfaces, PxER-based process review, and conformance assessment as the working group defines it. SI and practitioner FAQ → · Getting started →
When an agentic pilot comes to you for review, successful task completion is only part of the picture. The enterprise also needs to show who was accountable, how authority and oversight worked, and which evidence can support the claims made about the process.
APP offers a draft vocabulary and record structure to examine those questions. It distinguishes intended behaviour from execution evidence and makes limits of visibility part of the review.
Is this a compliance framework? No. APP is an evidence-and-vocabulary specification. Assessors and regulators may examine its artefacts as inputs to their own methodologies. Assurance FAQ →
Adoption
What you can do today, and what a broader future could enable
APP is a draft. A team can use its concepts to structure project design, or implement and assess specific requirements, in a current agentic project — without waiting for every vendor in the stack to adopt the protocol natively.
What you can do today
APP is a draft, but a team can start now, in a current project, with the agents and transaction systems already in flight. The exercise below is a practical first route.
A practical first exercise
- Choose one bounded agentic process with a named enterprise owner.
- Define its steps, D/P classification, accountability, and applicable controls in a Frame.
- Inventory the evidence available from agents, transaction systems, and review surfaces.
- Implement the required connections, record assembly, and controls for your intended scope.
- Test behaviour, evidence integrity, and what happens when systems or governance services become unavailable.
- Assess the applicable requirements and declare gaps before claiming conformance.
The components an early adopter brings together
Depending on the products and access available, the pieces an early team assembles typically include:
- Interfaces that make Frame definitions available to agentic systems and route changes through review.
- Connectors that capture execution events and transaction references from business systems for PxER assembly.
- Governance services for applicable approvals, authority checks, record integrity, and controlled change.
A Frame is not merely a prompt pasted into an agent. A PxER is not simply an export of model traces. Both need the structure, controls, and evidence applicable to the claimed scope.
Existing APIs, integration tools, and event feeds provide useful starting points. A custom connector surfaces evidence that the source system exposes; it does not create what the source does not emit, which shapes what a pilot can demonstrate.
Where the custom work sits today
| Source | What an early team typically assembles | Target |
|---|---|---|
| Process Frame | Frame adapter — makes Frame definitions readable to your agentic system | Existing agentic system |
| Agent + transaction events | Evidence adapters — map events into execution record format | PxER assembly |
| Approval surfaces, authority checks, integrity controls | Governance services — for applicable approvals and controlled change | Process boundary |
An illustrative integration view, not a canonical deployment architecture. If APP gains broad vendor implementation, more of these interfaces may be provided natively; today, teams typically assemble them.
Pilot work carries forward. The process definitions, evidence patterns, and delivery methodology an early team establishes remain useful as the ecosystem matures — the investment is not thrown away by later vendor adoption.
This is a suggested evaluation route, not a deployment guarantee or a substitute for the specification.
If APP gains standards recognition and broad implementation
The intended future is that participating products provide compatible process and evidence interfaces, reducing the need to reinvent those contracts project by project.
That future is conditional. APP is not an industry standard today, vendor adoption is not assured, and compatible interfaces would not remove process-specific configuration, access controls, testing, or assessment.
| Early adoption | As APP matures through broader implementation |
|---|---|
| Teams build or adapt interfaces to available agentic and transaction systems. | Products and reusable connectors provide more of the common interfaces. |
| Evidence mapping and limitations are established within the project. | Common contribution contracts may make integration and comparison easier. |
| The draft may change; teams plan for revision and migration. | A governed standard and release process provide a more stable shared baseline. |
Early adopters contribute evidence about what works, what needs refinement, and what the protocol needs to change. They are not promised automatic compatibility with a future standard.
Four integration maturity levels
The levels describe how closely governance connects to execution. This affects observation, verification, and enforcement — not just connectivity. The same five governance objectives apply at every level; integration depth affects the evidence available, the verification mechanisms, and what can be enforced within the declared scope.
| Level | Connection to execution | Practical consequence |
|---|---|---|
| L1 — Screen/RPA | External screen or automation interactions. | Governed routing and a basic record, with limited internal visibility. |
| L2 — API/MCP | Application interfaces and tool connections. | Orchestration-level governance; individual internal executions may remain unverifiable. |
| L3 — Application-enhanced | Applications contribute internal execution telemetry. | More direct checks and richer intra-application evidence where the relevant metadata exists. |
| L4 — AI-native | Governance embedded in the execution environment. | Governance and execution are unified by construction. |
Different systems can contribute at different levels in the same process. The L-level is not an overall assurance score or certification badge.
Conformance profiles separately describe when violations are addressed: before execution completes (Preventive), within a declared detection period (Detective), or through periodic analysis (Retrospective). Specification, Evidence, Governance, Security, and Learning conformance are reported separately where applicable.
The five participant roles
APP defines five technical participant roles. A product or organisation can perform more than one; obligations are assessed within each declared scope.
Governance Orchestrator. Holds the Frame version, assembles the PxER, enforces D/P classification, provides HITL approval surfaces, and produces learning outputs. Not a single-vendor category.
Telemetry Contributor. Contributes intra-application execution telemetry to PxER assembly. Typically ERP or enterprise platforms.
Agent Builder Platform. Builds and runs agents that consume Frame definitions and execute individual steps. Submits changes through the governance gate.
Enterprise Deployer. The organisation deploying governed processes. Configures tenant-level policies, compliance levels, and declared behaviour.
Field Deployment. The team or function that stands up a governed process: source documents, integrations, credentials, and activation.
Responsibilities and honest claims
Declare which roles, levels, and profiles are implemented, which requirements are met, and which are not. Partial conformance requires explicit disclosure; a general product-level badge is not a substitute.
Independent assessment and certification programme design remain matters for future working-group decisions.
Contribute
Bring the questions your agentic projects expose
Useful feedback includes a concrete scenario, an implementation limitation, an unclear requirement, or evidence that a proposed control cannot work as described.
You do not need to endorse APP, adopt it, or commit to a future working group to participate.
What we want to learn
| Audience | Especially useful feedback |
|---|---|
| Enterprise teams | Production-readiness concerns from current agentic projects: authority, oversight, accountability, evidence, and deployment constraints. |
| Application vendors | What your agentic and transaction interfaces can contribute, and where requirements conflict with actual application boundaries. |
| AI platform and agent-tool vendors | Frame consumption, process changes, agent authority, and evidence connections to business actions. |
| Systems integrators and practitioners | Adapter effort, missing interfaces, reusable definitions, and gaps discovered in pilot implementation. |
| Auditors, assessors, and regulators | Whether the evidence supports the claims made, how limitations should be declared, and what remains missing for qualified assessment. |
How to contribute
Use a Discussion for questions and scenarios, an Issue for a specific defect or ambiguity, and a Proposal for a concrete change. For document findings, identify the document and section where possible. Contribution requirements and terms are maintained in the repository.
Do not post confidential information or suspected security vulnerabilities in public discussions. See Governance for terms and private reporting routes.
About the interim custodian
Vach AI Limited, Dubai International Financial Centre, is the interim custodian during pre-working-group review. It authored the current draft and maintains the repository and decision records.
Substantive changes are decided by the interim custodian pending working-group formation, with public rationale recorded in the repository. The intended working-group charter will define future decision rights and review procedures. Neutral standards-body stewardship — presently anticipated as the Linux Foundation's Agentic AI Foundation (AAIF) or a comparable body — is an intention, subject to agreement and acceptance, not an endorsement already obtained.
We aim to respond to issues and general correspondence within five business days. This is an aim, not a service-level commitment.
Private contact routes
- Suspected security defects:
[email protected]— see/governance#security. - Personal-data and privacy requests:
[email protected]— see/governance#privacy. - Code of conduct reports:
[email protected]. - Accessibility and website issues:
[email protected]. - Legal correspondence and confidential participation questions:
[email protected].
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
APP 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.
IP posture
Contribution terms: Linux Foundation Community Specification License 1.0 (CSL 1.0), with an APP-specific preamble. Copyright licence for specification text: CC BY 4.0. Code of conduct: Contributor Covenant 2.1 verbatim.
Full contribution terms, versioning discipline, baseline cadence, and changelog live in the repository (IP-POLICY.md, CONTRIBUTING.md, CHANGELOG.md, CODE_OF_CONDUCT.md). If stewardship transfers 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 APP 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 [email protected]. 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: [email protected].
Full text of the consultation privacy notice, the contribution terms, and the working-group data handling charter is in the legal/ folder of the baseline. Public consultation is open on GitHub Discussions; submissions made there are public and processed under the published privacy notice.
FAQ
Questions from the agentic AI ecosystem
Choose your audience. General questions apply across all groups. The glossary explains the main terms; the detailed specifications remain authoritative.
Is APP an industry standard today? No. It is a draft open specification under pre-working-group review. Standards recognition and broad vendor adoption are not assumed or promised.
Is APP a product we can install? No. It specifies the process definition, controls, and evidence a governed process needs. Software products implement those requirements. The published schema and binding design are illustrative references, not a deployable platform.
Does APP replace MCP, A2A, or our workflow engine? No. Those continue to handle connectivity, communication, and execution. APP addresses the governance and evidence of the process those interactions serve.
Is APP only for cross-system processes? Cross-system processes are the primary design target. The model also works within a single application; adopting it there does not create visibility into other systems.
Does using APP establish regulatory compliance? No. It may structure evidence for assessment against applicable requirements. Legal and regulatory determinations remain with qualified reviewers and competent authorities.
Our pilot works. Why address governance now? Task success does not answer every production question. Define permitted actions, review requirements, accountable owners, and evidence while the process is being designed. A later review may otherwise depend on records the pilot never captured.
Must our ERP and agent vendors adopt APP before we can begin? No. You can evaluate the draft and implement around the interfaces you already have. Your team or delivery partner may need to build adapters and governance services. Vendor support becomes important where internal execution evidence or required controls are not externally available.
We've already invested in AI governance tools. How does APP relate? AI governance platforms typically focus on the organisational layer: model inventory, risk assessment, vendor assurance, policy management. APP addresses the running-process layer: what the agent was allowed to do at each step, which rules were applied, whether required review happened, and what evidence can be produced for a specific run. The two complement each other. Your existing governance tool sets the expectations across the organisation; APP shows that a specific governed process produced evidence those expectations were met.
What can a first project realistically demonstrate? A defined process, the evidence your participating systems can provide, and the controls you implemented within the chosen scope. It should also name what remains unverified. A working first project is not a blanket conformance or compliance claim.
If we switch our ERP or agent platform later, do we need to redefine the process? You should not need to redefine the process from scratch. The Frame holds the process definition — steps, D/P classification, authority, controls — independently of any vendor's runtime, preserving the governance intent. Switching an ERP, an AI platform, or an agent builder still requires rebinding the Frame to the new system, revising adapters and bindings, and reassessing conformance for the affected role.
How does APP support our CISO's agenda? APP defines security requirements for the governed process itself. The CISO can examine four areas APP addresses structurally: agent identity and session scope (requirements for which agent is permitted to act, and under what authority), Frame and evidence integrity (requirements for protecting process definitions and the execution record from tampering), approval-surface protection (requirements for ensuring reviewers see verified context rather than content an AI could manipulate), and the integration surface itself (how APP participants are expected to connect and authenticate). APP-3 details the architecture. Security teams assess how a given implementation meets these requirements and what limitations remain. APP complements the enterprise security programme; it does not replace identity infrastructure, incident response, or endpoint security.
Will APP reduce our AI cost over time? APP provides a structural route to lower inference cost. Each step is classified as rule-based or judgement-dependent. Where repeated judgement work can be safely converted to an approved rule through governed change, that step no longer calls an AI model, and its inference cost is removed. The scale of the reduction depends on how much work can be converted, how often those steps run, and the implementation.
We already have chat, agents, deterministic workflows, and controls. Why APP? Those capabilities govern what happens inside your application. APP addresses how the intended process and its evidence can be understood consistently across the customer's full process — including other applications and agent platforms your product touches.
Must we replace our agent stack or process engine? No. APP specifies outcomes and interoperability obligations, not one runtime architecture. The implementation choices remain yours. Where adaptation is needed: your agent stack should be able to receive a Process Frame in APP's format and route governed changes through review; your process engine should emit execution evidence in a PxER-compatible form so the record can be assembled across the full process.
What is the difference between API access and L3 participation? API access exposes application-boundary interactions — where most enterprise applications and agentic platforms sit today. L3 participation requires internal instrumentation that applications typically do not provide yet: emitting structured intra-application execution telemetry so per-step governance checks become possible. The expectation is that vendors will progressively enhance their applications toward L3, closing the gap between application-boundary evidence and intra-application verification.
Does PxER replace our transaction records? No. The PxER links to your transaction records; it does not replicate them. Your database remains the authoritative business record.
Can one product play several APP roles? Yes. A product might, for example, build agents and also run governance functions. Each declared role is assessed on its own; a product-wide badge is not a substitute for per-role conformance.
We already orchestrate agents and trace tool calls. What is missing? Those records explain technical execution. Enterprise governance also needs the approved business process, the authority permitted at each step, the review required, the source transactions touched, and traceable changes to the rules. APP provides the shared contract that connects those.
Is putting a Frame in an agent prompt enough? No. A text description alone does not establish correct consumption, controlled changes, applicable enforcement, or trustworthy execution evidence. Conformance depends on the implementation meeting the requirements for its declared scope.
Can we support APP without ERP-native telemetry? Yes, at the application boundary, where current interfaces allow. You cannot claim independently verified internal execution when the ERP provides only a completion signal. The limits of what you can show must be named.
Must one platform lead the process? No. APP fits a process led by an existing platform and one that spans several platforms with no natural lead. The implementation still provides execution and coordination; the Frame itself is not software that routes work.
Can we use a transport other than MCP? Yes. The published MCP binding is illustrative, and MCP is a recommended pattern. Alternative transports are permitted provided they satisfy the applicable integration and security outcomes.
We already do agentic AI projects. What does APP change for us? Three things become consistent across engagements: how you define the process (one versioned Frame), what evidence you commit to deliver (PxER structure declared upfront), and how your implementation connects to the rest of the stack (common interface mechanics). Today each engagement reinvents these; APP gives you a reusable baseline.
How does APP fit our current agentic delivery work? Use it to structure process intent, D/P classification, authority, review, evidence, and change. Add these concerns to engagement design and acceptance criteria, then assess the implementation against the applicable requirements.
What custom work should early adopters expect? Frame-consumption adapters, source-system event mapping, transaction-reference capture, PxER assembly, approval surfaces, and integrity controls. Effort depends on available interfaces and the intended scope.
What becomes reusable? Process definitions and components for similar steps and controls — after adaptation and review. Authentication, data mappings, permissions, and application bindings stay deployment-specific.
Can retrospective analysis be a starting point? Yes — APP includes a Retrospective profile. But analysing logs after the fact is not the same as producing a conformant execution record. The Frame, evidence integrity, and record-assembly obligations still apply.
When vendors release APP-compliant products, what happens to the adapters we built during the pilot? Native product interfaces may replace some adapters where functionality overlaps — notably Frame consumption, telemetry contribution, and standard governance hooks. Deployment-specific work typically does not transfer: authentication, data mappings, permissions, process-specific configuration, and testing stay yours. Teams that invested early also retain the knowledge of what works and what does not — which carries into later engagements.
How does APP change what we examine? Today, compliance evidence for an AI-involved process is typically assembled by hand across multiple system logs, often weeks after the fact. Significant effort goes into reconstruction before assessment can begin. An APP-governed process produces its evidence record during execution, linked to source transactions. The record names what was declared, what ran, what was reviewed, and what changed — under one versioned Frame. Assessment effort shifts from reconstruction to verification.
What should we look for in an agentic pilot? Compare the intended process with available execution evidence. Examine authority, review, accountability, changes, and declared blind spots. Do not treat task completion or abundant logs as proof of all those properties.
How do we distinguish a reported outcome from a verified one? Examine where the evidence came from, what was observable, and what independent checks were performed. A source-system completion assertion is not the same as independently verified internal execution.
Does APP cover everything a regulator or auditor needs? APP covers the governance structure of the process itself: authority, D/P classification, execution evidence, oversight integrity, and change control. It does not cover the organisational control environment, risk assessment methodology, management oversight, or the regulatory determinations themselves. APP evidence is an input to a broader assessment, not a replacement for it. Within its applicable scope — the process-level governance of AI-involved steps — APP is designed to cover what matters for review.
Does an L4 claim establish stronger overall assurance? Not by itself. Integration maturity is one part of scope. Applicable requirements, security, evidence integrity, test results, and separately reported conformance dimensions still matter.
Is there an APP certification programme? The draft defines conformance declarations. Independent assessment, certification, accreditation, and marks are matters for future working-group decisions; the website does not offer a certification scheme.
How does APP relate to ISO/IEC 42001, NIST AI RMF, or the EU AI Act? A dedicated crosswalk guide (APP-IG-06) is in development. It will map APP outcomes to each framework's control requirements as an input to qualified review — not as an endorsed mapping or legal conclusion. Until published, no formal correspondence should be relied upon.
Glossary
| Term | Meaning |
|---|---|
| Process Frame | The structured, versioned definition of how a process is intended to run, including its steps, classifications, dependencies, and accountability. |
| Process instance | One actual run of a process, such as resolving one invoice exception. |
| PxER | Process Execution Record: the durable record of one process run, with governance evidence and references to source transactions. |
| Deterministic (D) | Work that follows a known rule without inference. |
| Probabilistic (P) | Work involving judgement, interpretation, or reasoning, including planning where applicable. |
| D/P classification | The declared distinction between rule-based and judgement-dependent work, compared with actual execution where observable. |
| HITL | Human-in-the-loop: human review or decision-making within a process. Recording an approval is not the same as demonstrating substantive review. |
| Evidence | Information supporting accountability, governance review, or assessment. |
| Telemetry | Information about system activity; not all telemetry is sufficient governance evidence. |
| Entity correlation | Linking related business identifiers across process evidence, such as an employee record and an IT account. |
| Integration maturity | L1–L4: how governance connects to execution, affecting visibility, verification, and enforcement. |
| Conformance profile | When violations are blocked or identified: Preventive, Detective, or Retrospective. |
| Partial conformance | Some applicable requirements are unmet and explicitly disclosed; not an unqualified conformant claim. |
| Governance Orchestrator | The role managing Frame lifecycle, record assembly, and its applicable governance functions. |
| Telemetry Contributor | The role supplying applicable execution evidence to record assembly. |
| Agent Builder Platform | The role consuming process definitions and contributing changes through the governance gate. |
| Enterprise Deployer | The organisation configuring policies and deploying governed processes. |
| Field Deployment | The team or function preparing integrations, credentials, source material, and activation for deployment. |
These definitions are informative. The detailed specifications govern interpretation and conformance.