Execution Governance for AI Agent Architectures

Document identifier	bpmstack.org/spec/2026-04-01
Status	Public Draft Specification, Version 1.1
Date	April 1, 2026
Author	Rob Kline, PracticalStrategy.AI
License	Creative Commons Attribution 4.0 International (CC BY 4.0)
Companion Specification	Intent Stack Governance Architecture v1.2 (intentstack.org/spec/2026-04-01)
Supersedes	BPM/Agent Stack Specification v1.0 (2026-03-25)

---

Foreword

(Informative)

This specification is the second pillar of a governance architecture for autonomous AI agent deployment. The first pillar — the Intent Stack Governance Architecture (intentstack.org) — specifies what governance content must be present at every delegation interface: why the delegation exists, how to approach the work, what must never happen, what counts as success, and what work is authorized. The Intent Stack answers the question of governance context.

This specification answers the complementary question: once authorized work is defined, how does it get executed with structure, roles, decisions, exceptions, and accountability? This is the execution governance problem. It is not new. The discipline of Business Process Management (BPM) — as codified in the ABPMP BPM Common Body of Knowledge (CBOK v4.0), standardized through BPMN 2.0, DMN 1.0, and CMMN 1.0 (all published by the Object Management Group), and validated through decades of enterprise-scale operation across banking, healthcare, manufacturing, government, and insurance — solved it long ago.

The novel contribution of this specification is not the invention of execution governance patterns. It is the formalization of the bridge between proven BPM discipline and AI agent architectures that desperately need those patterns but whose builders do not know the source discipline exists. Every major agent framework — regardless of vendor, philosophy, or complexity — shares a common structural deficiency: the absence of an execution governance layer. This specification fills that gap.

This specification formally claims three execution governance concerns that the Intent Stack explicitly excludes from its scope: Orchestration (how multiple agents are coordinated to execute specifications), Integration (how governed agents connect to the systems they need), and Execution (how actual work gets done within governing constraints). These three concerns were originally identified within the Intent Stack’s seven-layer architecture (as L3, L2, and L1 respectively in v1.1) but are properly the domain of execution governance, not governance context. The Intent Stack v1.2 reclassified them accordingly, and this specification claims them as its formal scope.

The relationship between the two pillars is orthogonal by design. The Intent Stack governs why and under what authority. The BPM/Agent Stack governs how — with what process, roles, logic, and controls. Neither duplicates nor complicates the other. They meet at a clean stitching point where governance intent becomes actionable execution specification. This orthogonality is a design quality to be preserved: when extending either specification, the test is whether the extension creates overlap with the other. If it does, the extension belongs in the stitching mechanism, not in either specification independently.

Both pillars rest on a foundation they did not create: the Constitutional AI substrate (Anthropic). Training-time governance shapes the model’s character universally. The Intent Stack governs the model’s operation within specific organizational contexts. The BPM/Agent Stack governs the execution structure within which that operation is carried out. All three are necessary. None substitutes for either of the others.

Intellectual property. This specification is published under the Creative Commons Attribution 4.0 International License. You are free to share and adapt this material for any purpose, provided appropriate attribution is given. The full license is available at creativecommons.org/licenses/by/4.0/.

Relationship to standards. This specification draws on established international standards and professional bodies of knowledge. Where those standards apply directly, this specification references them rather than reinventing their content. Where this specification extends or adapts established patterns for agent-specific application, the extension is marked as such.

Terminology note. The keywords defined in Clause 2.2 carry precise obligation meanings throughout the normative clauses of this specification. Their use in the Foreword and Introduction is informal.

Nature of the work. The Intent Stack required months of foundational research — generating principles, formal decomposition, mathematical validation, and independent convergence testing across seven theoretical traditions. The BPM/Agent Stack is fundamentally different. The source discipline is already codified, standardized, and validated. The intellectual contribution is the mapping (formalizing how proven patterns apply to agent execution), the gap analysis (demonstrating what current frameworks lack relative to established process governance), the stitching (connecting this specification to the Intent Stack), and the novel application claim (nobody has bridged BPM discipline into agent architectures). There are zero citations for the application — the bridge itself has no prior art.

---

Introduction

(Informative)

I.1 The Execution Governance Gap

Every AI agent framework solves mechanism: how models access tools, how agents coordinate, how state persists. None solves execution governance: who is responsible for each step, what structured logic governs decisions, what happens when things go wrong, what constraints apply at each activity, what vocabulary is authorized, and what audit trail exists.

This gap is not theoretical. Organizations deploying agents encounter it immediately. An agent that can use tools but has no structured exception handling will retry indefinitely or fail silently. An agent that can coordinate with other agents but has no responsibility model will produce work that nobody is accountable for. An agent that makes decisions but has no separation between deterministic rules and probabilistic judgment will use LLM inference for compliance checks that should be deterministic.

The BPM discipline has addressed every one of these concerns for over two decades. The activity model in Clause 8 carries 21 governed attributes derived from RACI, SIPOC, Value Stream Mapping, and ISO 31000. The process structure elements in Clause 9 provide typed gateways, structured exception handling, governed decomposition, and explicit execution ordering — all specified in BPMN 2.0. The governance infrastructure in Clause 10 provides controlled vocabularies, policy linkage, decision models, and audit trails.

The AI agent community is reinventing these patterns from scratch, informally, and incompletely. Framework builders add “guardrails” without structured policy linkage. They implement “tasks” without activity attributes. They describe “handoffs” without governed delegation interfaces. They are solving a solved problem, badly.

I.2 Why Agent Species Differ

Recent operational analysis of production agent deployments (notably Jones, 2026) identifies at least four distinct agent deployment patterns — termed “species” — that practitioners routinely confuse: individual coding harnesses, project-scale coding harnesses, dark factories, auto-research loops, and orchestration frameworks. Jones observes that using the wrong species for the wrong work produces failure, and that species differ in where humans sit, what quality gates apply, and how intent is communicated.

This specification provides the structural explanation for why species differ: each species is a different governance configuration at the delegation interface. The same agents, the same tools, the same models — arranged with different governance infrastructure. The species taxonomy is descriptive; the governance architecture is generative. It explains existing species and tells you how to configure governance for deployment patterns that haven’t emerged yet.

Clause 6 formalizes this mapping. Each species is characterized by its governance configuration across the five Intent Primitives, its positioning within the governance architecture, and the BPM/Agent Stack’s contribution to its execution governance needs.

I.3 The Three-Layer Claim

This specification claims that safe, accountable, autonomous AI agent deployment requires three layers of governance, each independently necessary:

1. Constitutional AI (the substrate) — training-time governance that shapes the model’s character universally. Provides the behavioral floor beneath which no agent can operate.
2. Intent Stack (governance context) — runtime governance that specifies what is delegated, by whom, under what authority, with what constraints. Provides the organizational context within which agents operate.
3. BPM/Agent Stack (execution structure) — execution governance that specifies how authorized work gets done with structure, roles, decisions, exceptions, and accountability. Provides the process infrastructure within which agents execute.

Each layer answers a question the others cannot. Constitutional AI cannot know this organization’s specific constraints. The Intent Stack cannot specify how to coordinate three agents through a gateway. The BPM/Agent Stack cannot determine whether a delegation was authorized. The layers are orthogonal and complementary.

I.4 Execution Governance as Formal Scope

The Intent Stack v1.2 explicitly excludes execution governance from its scope, identifying three execution governance concerns that are the domain of this specification:

• Orchestration — how multiple agents are coordinated to execute specifications. How intent translates across delegation levels. How knowledge is provisioned as a governance act.
• Integration — how governed agents connect to external systems. How access scope is determined by governing intent. How governance context is carried through integrations.
• Execution — how actual work is performed within the full governance context. How hard constraints remain non-negotiable. How execution produces high-quality evidence as its primary governance output.

These three concerns were originally identified as layers within the Intent Stack (L3, L2, L1 in v1.1). The orthogonality audit that led to the Intent Stack v1.2 revision confirmed that they are structurally independent from the four governance context concerns the Intent Stack addresses. Their proper home is here — in the specification grounded in the discipline (BPM) that has governed execution for decades.

Together, the Intent Stack and BPM/Agent Stack address seven governance concerns: four governance context concerns (Intent Discovery, Intent Formalization, Specification, Runtime Alignment) and three execution governance concerns (Orchestration, Integration, Execution).

I.5 What This Specification Is Not

Not a BPM platform. This specification does not propose building a traditional BPM suite. It formalizes governance patterns from the BPM discipline into a specification that agent frameworks can implement.

Not vendor-specific. No single BPM tool is the required implementation. The specification is grounded in open standards, the professional body of knowledge, and established public-domain frameworks.

Not anti-framework. The BPM/Agent Stack does not replace LangGraph, CrewAI, or any other agent framework. It provides the governance layer they are missing.

Not anti-LLM-judgment. The specification does not propose replacing all LLM decision-making with deterministic rules. It proposes distinguishing between decisions that require LLM judgment and decisions that require deterministic logic — and providing the infrastructure for both.

Not a theoretical exercise. Every element in this specification has been operational in enterprise BPM for over a decade. The novel claim is the application to agent architectures, not the invention of governance patterns.

---

Table of Contents

Foreword	Informative — see above
Introduction	Informative — see above
Clause 1 — Scope	Normative
Clause 2 — Conformance	Normative
Clause 3 — Normative References	Normative
Clause 4 — Terms and Definitions	Normative
Clause 5 — Three-Layer Governance Architecture	Normative
Clause 6 — Agent Deployment Patterns	Normative
Clause 7 — The Stitching Mechanism	Normative
Clause 8 — The Activity Model	Normative
Clause 9 — Process Structure Elements	Normative
Clause 10 — Governance Infrastructure	Normative
Clause 11 — Context, Memory, and Intent	Normative
Clause 12 — Validation Mechanisms	Normative
Clause 13 — Self-Referential Governance	Informative
Clause 14 — Open Questions	Informative
Annex A — Agent Species Quick Reference	Informative
Annex B — Informative References	Informative

---

BPM/Agent Stack Specification v1.1 | Public Draft Specification | 2026-04-01 Creative Commons Attribution 4.0 International (CC BY 4.0) bpmstack.org Companion to Intent Stack Governance Architecture v1.2 (intentstack.org/spec/2026-04-01)

Version history:

Version	Date	Changes
0.1	2026-03-22	Initial draft
0.2	2026-03-22	Regrounded in ABPMP CBOK, OMG standards, and public-domain frameworks. Removed vendor-specific fingerprints.
0.3	2026-03-22	CRITICAL FIX: Correctly distinguished Intent Stack’s Five Primitives (Clause 5) from Seven Layers (Clause 8). §6 rewritten with correct architecture. Constitutional AI substrate connection added.
1.0	2026-03-25	Major revision: Three-layer governance architecture formalized (Clause 3). Agent deployment patterns mapped as governance configurations (Clause 4). Stitching mechanism analysis deepened with five potential intersection points (Clause 5). Context/Memory/Intent disambiguation added (Clause 9). Auto-research validation pattern added (Clause 10). IP boundary architecture as self-referential governance instance (Clause 11). Framework gap analysis expanded (Clause 8). Promoted from “Working Draft” to “Working Specification.”
1.1	2026-04-01	Format alignment with companion Intent Stack v1.2. Formally claims Orchestration, Integration, and Execution as scope (previously implicit). Conformance clause added (Clause 2). Terms and Definitions promoted to normative clause (Clause 4). Obligation keywords (SHALL/SHOULD/MAY per RFC 2119) applied throughout normative clauses. Normative/Informative annotations on all sections. Stitching mechanism updated for bidirectional interface with four-layer Intent Stack. All Intent Stack layer references updated to v1.2 numbering (L4/L3/L2/L1). License: CC BY 4.0. Promoted from “Working Specification” to “Public Draft Specification.”