# EnterpriseAgentStack.com Full Architecture Specification (llms-full.txt) Category-Defining Reference Architecture, Interactive Assessment, and Production Readiness Authority. ## Core Architectural Principle "The model proposes. The runtime decides. The evidence proves." ## Maturity Model Stage 0 — Experimenting: Prompts, models, tools, and local demos. (Risk: Capability grows faster than ownership and control.) Stage 1 — Connected: Enterprise data and shared deployment. (Risk: Agents gain enterprise reach without complete visibility.) Stage 2 — Observable: Traces, logs, evaluations, and cost visibility. (Risk: The organization can see failures but may not stop them before execution.) Stage 3 — Governed: Identity, ownership, permissions, and approvals. (Risk: Governance may remain static while runtime conditions change.) Stage 4 — Controlled: Pre-action enforcement, budgets, revocation, and safe degradation. (Risk: Controls require evidence, testing, and operational maturity.) Stage 5 — Assured: Decision-grade evidence, replay, continuous evaluation, and outcome verification. (Risk: Requires ongoing maintenance and strict compliance synchronization.) ## Complete 15 Stack Layers ### Layer 1: Agent Applications and Workflows (agent-applications) Headline: Start With the Business Objective, Not the Model Enterprise Owner: Business owner and product team Definition: The application layer defines what the agent is expected to accomplish, who owns the outcome, how much autonomy is permitted, and which consequences are acceptable. Purpose: Defines business intent, success criteria, and user interaction surfaces for autonomous workflows. Why it exists: Without explicit application boundaries, agents drift into unconstrained tasks with unclear ownership and undefined success criteria. Minimum Requirements: - Business objective & unique Objective ID - Quantifiable success criteria - Named accountable business owner - User population & identity context - Defined permitted autonomy level - Risk classification rating - Required human involvement triggers - Permitted financial & operational consequences - Outcome verification mechanism - Named incident responder Common Failures: - Teams start with a model and tools but cannot clearly state what success or acceptable autonomy means. - Unclear ownership leaves incident response without an accountable executive when agent actions fail. - Inability to measure outcome quality vs completed API calls. Evidence Produced: - Objective Record - Ownership Attestation Record - Risk Classification Manifest - Success Criteria Definition - Outcome Verification Record --- ### Layer 2: Agent Framework and Runtime (agent-framework-runtime) Headline: Control How the Agent Plans, Retries, Recovers, and Delegates Enterprise Owner: AI platform team Definition: The runtime environment that orchestrates planning, step decomposition, execution loops, state management, error handling, and delegation. Purpose: Manages step execution, memory hydration, tool execution loops, retry strategies, and sub-agent delegation. Why it exists: Agents enter infinite retries, goal drift, replanning loops, and lost approval state without bounded runtime controls. Minimum Requirements: - Unique Objective IDs passed through all execution spans - Bounded loop iterations & max retry counts - Maximum planning depth constraints - Explicit termination conditions (success/fail/timeout) - Recoverable state checkpoints - Deterministic boundary handlers - Graceful failure & fallback paths - Safe fallback modes - Delegation tracking records Common Failures: - Infinite retry loops consuming massive API costs on broken tools. - Goal drift where sub-plans diverge from the original business objective. - Loss of approval state when resuming execution after a human pause. Evidence Produced: - Agent Episode Log - Plan Revision History - Retry Event Record - Delegation Event Manifest - Termination & Recovery Record --- ### Layer 3: Models and Intelligence (models-intelligence) Headline: Use the Right Model for the Objective, Data, Risk, Cost, and Environment Enterprise Owner: Model governance and AI platform team Definition: The layer providing reasoning, language generation, embeddings, reranking, and multimodal perception capabilities across commercial and open-weight models. Purpose: Routes prompts and context to appropriate models based on task complexity, data sensitivity, latency, and cost rules. Why it exists: Sending sensitive enterprise data to unapproved external endpoints or using high-cost models for simple formatting tasks destroys security and margin. Minimum Requirements: - Enterprise model registry with version pinning - Dynamic model routing engine - Private VPC & on-premise model hosting options - Embedding & reranker model governance - Multimodal capabilities control - Automatic failover & fallback routing - License & compliance auditing - Model revocation switch Common Failures: - Data leakage by sending PII to public, non-compliant third-party models. - Service outage when a single provider API experiences degradation with no fallback. - Silent prompt injection exploiting model vulnerabilities. Evidence Produced: - Model Selection Record - Model Version & Weights Manifest - Routing Decision Log - Model Evaluation Reference - Token & Cost Record --- ### Layer 4: Tools and Capabilities (tools-mcp-capabilities) Headline: Define What Every Tool Can Do Before an Agent Uses It Enterprise Owner: Platform engineering and application owners Definition: The capability interface layer (APIs, SaaS connectors, Model Context Protocol MCP tools, SQL queries, system commands) that allows agents to take actions. Purpose: Schema validation, read/write classification, resource scoping, transaction limits, idempotency enforcement, and side-effect controls. Why it exists: A tool is not merely a function call; it is a path to an enterprise consequence. Uncontrolled tool access leads to accidental deletions, unauthorized transfers, and infrastructure damage. Minimum Requirements: - Unique Tool Identity & ownership registry - Strict input/output JSON schema validation - Read vs Write vs Destructive classification - Resource scope & transaction rate limits - Idempotency keys & transaction boundaries - Reversibility & rollback capability classification - Human approval requirement triggers - Verification method definition Common Failures: - Agent calling a write endpoint with unvalidated parameters causing database corruption. - Tool execution failing silently while reporting success to the LLM. - Unbounded API rate limit exhaustion during tool retries. Evidence Produced: - Tool Manifest & Schema Definition - Tool Capability Grant - Tool Call Request Log - Execution Receipt - Side-Effect Verification Log --- ### Layer 5: Context and Knowledge (context-knowledge) Headline: Give Agents the Right Context, Under the Right Permissions, at the Right Time Enterprise Owner: Data, knowledge, and security teams Definition: The data retrieval, RAG, vector, graph, and document context layer that feeds relevant knowledge to the agent runtime. Purpose: Enforces permission-correct retrieval, source identity verification, freshness limits, provenance tracking, and effective-time boundaries. Why it exists: Relevant context is not automatically authorized context. Agents frequently leak confidential HR, legal, or financial documents because vector search bypasses traditional ACLs. Minimum Requirements: - Source Identity & Access Control ACL preservation in search - Data classification tagging (Public, Internal, Confidential, Restricted) - Freshness & TTL effective-date validation - Provenance tracking for all retrieved chunks - Permission checks evaluated against the original requesting user - Purpose-limited retrieval scopes - Context snapshot generation for reproducible audits Common Failures: - Agent retrieves salary records because vector search indexed files without ACL metadata. - Outdated policy documents retrieved due to missing effective-date filters. - Inability to prove what documents the agent saw before making a critical decision. Evidence Produced: - Context Bundle Record - Source References & Lineage Map - Permission Verification Decision - Retrieval Rationale Log - Context Snapshot Hash --- ### Layer 6: Agent Memory (agent-memory) Headline: Control What Agents Remember, Reuse, Share, and Forget Enterprise Owner: AI platform and data governance team Definition: The persistent state, working memory, session memory, and shared organizational memory systems used by agents across conversations and tasks. Purpose: Manages memory types, origin tagging, validation state, decay, expiration, deletion, and cross-agent memory contamination controls. Why it exists: A generated conclusion should not silently become trusted enterprise memory. Hallucinated facts stored in long-term memory permanently corrupt future agent runs. Minimum Requirements: - Explicit memory type classification (Session, User, Workflow, Shared) - Memory origin & provenance tracking - Human or algorithmic validation state before memory promotion - Expiration TTL and memory decay schedules - Explicit reuse & cross-agent sharing permissions - Instant memory deletion & revocation capabilities - Contamination controls preventing hallucinated memory drift Common Failures: - An agent hallucinates a customer discount, stores it in long-term memory, and honors it for months. - Unsanitized user inputs in session memory cause cross-session prompt injection. - Inability to delete user PII from agent memory upon GDPR/CCPA request. Evidence Produced: - Memory Record Manifest - Memory Validation Attestation - Retrieval Rationale Log - Memory Expiration Event - Purge & Deletion Event Receipt --- ### Layer 7: Agent Identity and Ownership (agent-identity-ownership) Headline: Give Every Production Agent an Identity, Purpose, and Owner Enterprise Owner: IAM and security team Definition: The workload identity, machine identity, registration, and organizational ownership layer for all autonomous agents. Purpose: Assigns verifiable SPIFFE/OAuth workload identity, logical IDs, environmental scopes, approved purpose definitions, and named business/technical/security owners. Why it exists: An agent should not reach production without a defined identity, accountable owner, approved purpose, risk classification, approved environment, and revocation path. Minimum Requirements: - Centralized Enterprise Agent Registry - Logical ID, Workload Identity (mTLS/SPIFFE/OIDC), & Instance ID - Version identity and code deployment tracking - Environmental isolation scoping (Dev, Staging, Prod) - Named Business Owner, Technical Owner, and Security Owner - Approved Purpose Definition contract - Risk classification rating (Low, Med, High, Critical) - Instant agent revocation path Common Failures: - Rogue agents created by shadow IT running under developer personal credentials. - Security teams cannot identify which team owns an agent causing suspicious API spikes. - Inability to disable a compromise-suspected agent without bringing down entire cloud services. Evidence Produced: - Agent Passport - Ownership Attestation Record - Approved Purpose Record - Risk Rating Certificate - Lifecycle & Revocation Event --- ### Layer 8: Authority and Delegation (authority-delegation) Headline: Define What Each Agent May Do—and What It May Delegate Enterprise Owner: Security, risk, and business owners Definition: The permission model governing what actions, resources, spending, and delegations an agent is authorized to execute. Purpose: Enforces authority scoping across 12 dimensions: capability, resource, purpose, environment, time, amount, customer, region, risk, approval, delegation, and budget. Why it exists: Credentials become a substitute for permission when systems confuse raw technical capability with explicit business authorization. Minimum Requirements: - Explicit Capability Grants (least privilege principle) - Resource-level scoping & customer/tenant boundary limits - Time-bound & amount-bounded authority leases - Strict delegation rules for sub-agent worker spawning - Mathematical Delegation Formula: Effective Delegated Authority = Delegator ∩ Recipient ∩ Objective ∩ Policy ∩ Runtime - Cascading revocation propagation across delegated agent chains Common Failures: - An agent with database read credentials delegates unrestricted write commands to a child worker. - Authority remains valid indefinitely after an underlying business project ends. - Inability to trace authority grants back to human delegation events. Evidence Produced: - Authority Grant Certificate - Capability Grant Manifest - Delegation Chain Record - Signed Authority Manifest - Runtime Lease Expiration Receipt --- ### Layer 9: Policy and Runtime Enforcement (runtime-policy-enforcement) Headline: Evaluate Policy Before Consequential Actions Occur Enterprise Owner: Security, compliance, and architecture teams Definition: The real-time Policy Decision Point (PDP) and Policy Enforcement Point (PEP) executing pre-action authorization rules before tool calls or external effects execute. Purpose: Evaluates policy-as-code against current identity, authority, context, tool, model, budget, and approval state to issue Allow, Deny, Require Approval, Degrade, Throttle, Replan, Escalate, or Terminate decisions. Why it exists: Policies describe what should happen but cannot stop what is happening if they run only after execution or exist solely as static PDF compliance documents. Minimum Requirements: - Policy-as-code engine (OPA/Rego/Cedar) - Pre-action Policy Enforcement Point PEP - Policy Decision Point PDP evaluating contextual state - Multi-input evaluation (Identity + Authority + Context + Tool + Model + Budget + Approval) - Real-time decision spectrum (Allow, Deny, Approval, Degrade, Throttle, Replan, Terminate) - Sub-10ms decision latency - Signed Policy Decision Records for every evaluation Common Failures: - Post-action logging alerts security 2 hours AFTER an unauthorized wire transfer occurred. - Policy rules hardcoded into python files unable to be updated during an active security breach. - Inconsistent policy decisions across different cloud regions or agent frameworks. Evidence Produced: - Policy Decision Record - Enforcement Action Receipt - Decision Rationale Log - Runtime Context Snapshot - Policy Version Manifest --- ### Layer 10: Human Escalation and Approval (human-approval) Headline: Put People in the Decisions That Need Them Enterprise Owner: Business and risk owners Definition: The human-in-the-loop workflow, escalation protocol, and approval management system for high-risk or irreversible agent actions. Purpose: Routes risk-based approval requests with structured evidence objects, expected effects, reversibility options, and budget impacts to human reviewers. Why it exists: Universal human approval slows agents to zero utility, while no human approval leads to catastrophic automated errors. Involvement must be risk-proportional. Minimum Requirements: - Risk-proportional approval trigger matrix - Structured Approval Request Object (Action, Agent, Objective, Evidence, Risk, Budget, Effect) - Multi-channel reviewer routing (Slack, Teams, Mobile App, Web Portal) - Approval expiration TTL & fallback escalation paths - Post-approval state change verification (preventing TOCTOU attacks) - Signed Human Approval Receipts Common Failures: - Approval spam causing human reviewers to blind-approve all requests without reading evidence. - Time-of-check to time-of-use (TOCTOU) vulnerability where agent state changes between approval and execution. - Approval queues stalling time-critical workflows due to missing escalation rotas. Evidence Produced: - Approval Request Manifest - Evidence Viewed Log - Human Approval Decision Receipt - Approval Condition Record - Post-Approval Execution Verification --- ### Layer 11: Runtime Budget Governance (runtime-budget-governance) Headline: Control Agent Cost While the Work Is Still Running Enterprise Owner: FinOps, platform, and business owner Definition: The financial guardrails, cost reservation, token cap, API spend, and compute budget management system active during agent execution. Purpose: Monitors spend across 11 dimensions: objective budget, model cost, tokens, tool cost, retrieval cost, compute, duration, rows scanned, retries, replanning, and delegation depth. Why it exists: An unmonitored agent entering an unconstrained loop can burn tens of thousands of dollars in LLM tokens and API fees in minutes. Minimum Requirements: - Pre-execution cost reservation & soft/hard spending caps - Multi-dimension tracking (Tokens, Model $, Tool $, Compute, Time, Retries) - Real-time runtime responses (Continue, Degrade Model, Reduce Context, Limit Scope, Require Approval, Terminate) - Objective-level & Agent-level budget allocation - FinOps cost allocation tagging by business unit and objective ID - Reconciliation & prevented spend reporting Common Failures: - Surprise $50k cloud bill caused by recursive sub-agent planning loop over a weekend. - Agent running out of budget mid-transaction leaving external systems in an inconsistent state. - FinOps unable to attribute AI costs to specific business units or customer projects. Evidence Produced: - Budget Allocation Record - Cost Reservation Receipt - Token & Spend Consumption Log - Budget Threshold Alert - Prevented Spend Audit Report --- ### Layer 12: Agent Observability (agent-observability) Headline: Observe Complete Agent Episodes, Not Isolated API Calls Enterprise Owner: SRE and AI platform team Definition: The telemetry, tracing, trajectory monitoring, and episode recording infrastructure designed specifically for multi-step agent reasoning and tool usage. Purpose: Captures full agent trajectories (objective, requester, agent identity, user identity, context, plans, model calls, tool calls, delegations, policy decisions, budget events, approvals, side-effects, outcomes). Why it exists: Agent failures often emerge across a sequence of choices. Traditional APM tools showing isolated HTTP requests miss the reasoning trajectory and root cause of goal drift. Minimum Requirements: - OpenTelemetry-compliant Agent Trajectory Tracing (Traces, Spans, Events) - Complete Agent Episode recording linking all sub-agent spans - Context, plan, model, tool, policy, budget, and outcome telemetry link - Real-time trajectory anomaly detection & latency profiling - Side-effect execution tracking - Searchable episode trajectory index Common Failures: - Security incidents cannot be investigated because logs show LLM responses but not tool parameters. - SREs unable to debug why an agent got stuck in a 10-step loop. - High latency impossible to diagnose between model generation, vector search, and API calls. Evidence Produced: - Agent Episode Record - Trajectory Trace Graph - Span Event Timeline - Tool Execution Telemetry - Cost & Latency Breakdown Report --- ### Layer 13: Evaluation (agent-evaluation) Headline: Evaluate the Entire Path From Objective to Outcome Enterprise Owner: AI quality and domain owners Definition: The continuous testing, benchmark, trajectory evaluation, and quality assurance framework running across development, pre-deployment, shadow, and production environments. Purpose: Measures objective interpretation, context selection, plan quality, model behavior, tool arguments, recovery efficiency, policy adherence, cost efficiency, and outcome correctness. Why it exists: A successful LLM HTTP 200 run is easily mistaken for a correct business outcome. Without continuous evaluation, regression errors compound silently across system updates. Minimum Requirements: - 14 Evaluation Types (Objective, Context, Plan, Model, Tool, Arguments, Recovery, Delegation, Policy, Cost, Output, Side-effect, Outcome, Control-effectiveness) - 7 Evaluation Stages (Dev, Pre-deploy, Shadow, Limited Prod, Continuous Prod, Post-incident, Post-component change) - Curated golden dataset benchmarks - Automated regression testing pipelines - Control-effectiveness testing - Release decision gate integration Common Failures: - Updating a system prompt breaks 30% of downstream tool call parameters unnoticed. - Agent passes unit tests on simple synthetic data but fails catastrophically on messy enterprise inputs. - Evaluating only final text output while ignoring incorrect database writes caused along the way. Evidence Produced: - Evaluation Dataset Record - Test Suite Scorecard - Control-Effectiveness Report - Regression Failure Analysis - Release Decision Certificate --- ### Layer 14: Audit and Decision-Grade Evidence (evidence-audit) Headline: Preserve Evidence That Explains What Happened and Why Enterprise Owner: Risk, compliance, and security team Definition: The immutable audit, Decision Receipt, Evidence Manifest, and cryptographic record-keeping layer for regulatory, legal, and compliance accountability. Purpose: Answers 12 material audit questions: What happened? Which identity acted? Which authority applied? Which objective? Which context? Which model? Which tool? Which policy? Which approval? What runtime decision? What side-effect? Was outcome verified? Why it exists: Logs show events, but Decision-Grade Evidence connects identity, authority, context, policy, approval, execution, side-effects, and outcome into an indisputable legal proof. Minimum Requirements: - Cryptographically signed Decision Receipts for all consequential decisions - Evidence Event & Evidence Manifest generation - Complete Execution Record linking Context Bundle + Policy Decision + Outcome Verification - Tamper-evident, immutable storage (WORM / Ledger) - Trace-linked evidence correlation - Audit export formats (JSON-LD, PDF, CSV) - Legal & regulatory compliance mapping (EU AI Act, SOC2, HIPAA, ISO 42001) Common Failures: - Inability to defend an agent decision during a regulatory inquiry because raw logs were rotated out after 30 days. - Logs missing the exact prompt context or user permissions present when a disputed action took place. - Audit logs stored in editable text files vulnerable to internal tampering. Evidence Produced: - Evidence Event - Evidence Manifest - Decision Receipt - Execution Record - Outcome Verification Record --- ### Layer 15: Deployment and Operations (deployment-operations) Headline: Run the Same Controls Across Cloud, Private, On-Prem, Edge, and Physical Systems Enterprise Owner: Cloud, platform, and SRE teams Definition: The deployment, environment isolation, containerization, SRE, kill-switch, and lifecycle infrastructure across SaaS, Public Cloud, Customer VPC, On-Premises, Air-Gapped, Edge, Kubernetes, and Physical/Robotic runtimes. Purpose: Enforces environment isolation, signed deployments, version pinning, shadow mode, canary rollouts, rollback, instant kill-switches, credential rotation, and disaster recovery. Why it exists: Agent code deployed directly to cloud environments without deployment boundaries or instant kill-switches risks un-revokable runaway background jobs. Minimum Requirements: - Multi-environment support (SaaS, VPC, On-prem, Air-gapped, Edge, Kubernetes) - Environment isolation boundaries (Dev vs Staging vs Prod) - Cryptographically signed code & container deployments - Version pinning for code, prompts, models, and dependencies - Shadow mode execution testing & canary deployment gates - Global Instant Kill Switch & Revocation Propagation - Automated rollback capabilities - Credential rotation & secret management Common Failures: - Deploying an updated prompt directly to production without canary testing breaks live customer sessions. - SREs unable to kill a malfunctioning background agent worker without killing the entire Kubernetes cluster. - Secrets hardcoded in agent environment variables exposed in crash dumps. Evidence Produced: - Deployment Manifest - Environment Approval Record - Version Pinning Certificate - Rollback Execution Log - Kill-Switch Activation Receipt ## Core Vocabulary Glossary (40+ Terms) - **Enterprise Agent Stack**: The complete set of capabilities, controls, interfaces, and infrastructure required to move AI agents from prototype to governed production. Plain English: "Everything an enterprise needs to run AI agents safely — not just prompts and models, but identity, permission, policy, budgets, evidence, and deployment." - **AI Agent Stack**: The full technical stack spanning applications, runtimes, models, tools, context, memory, governance, and infrastructure for autonomous agents. Plain English: "The collection of software tools and control layers required to build and run AI agents." - **Agentic AI Stack**: An architectural terminology referring to software layers built explicitly to support autonomous reasoning and action. Plain English: "The technology stack designed for AI systems that can plan and take actions on their own." - **Enterprise Agent Reference Architecture**: A vendor-neutral blueprint detailing the 15 standard layers, required interfaces, and control boundaries necessary for production AI agents. Plain English: "The master architecture guide for enterprise architects to design and audit AI agent platforms." - **Production Agent Architecture**: An architecture hardened for production workloads including SLA, fault tolerance, pre-action enforcement, evidence trails, and incident handling. Plain English: "An agent system ready to handle real enterprise customer data and financial actions safely." - **Governed Agent Stack**: An agent stack where every model call, tool execution, context retrieval, and state update is subject to real-time policy evaluation. Plain English: "An agent stack where security and business rules run before every action." - **Agent Runtime**: The execution container and state machine that manages agent planning loops, memory hydration, tool execution, and error recovery. Plain English: "The engine that runs the agent's step-by-step thinking and tool execution." - **Agent Application**: The top-level business workflow framing the agent objective, permitted autonomy, and user interface. Plain English: "The actual software program or tool that users interact with to complete a business task." - **Agent Framework**: Software libraries (e.g. LangChain, CrewAI, AutoGen) used to structure agent reasoning loops and tool bindings. Plain English: "The code framework used by developers to program agent behavior." - **Model Gateway**: A managed proxy layer routing LLM requests, enforcing rate limits, managing API keys, and handling fallbacks. Plain English: "The central switchboard through which all model requests pass." - **Model Routing**: Dynamic selection of LLMs based on task complexity, data sensitivity classification, cost, latency, and availability. Plain English: "Sending simple tasks to cheap models and complex tasks to frontier models automatically." - **Capability Gateway**: A security mediator controlling agent access to tools, APIs, database queries, and system commands. Plain English: "The guard at the door controlling what external tools an agent is allowed to invoke." - **Agent Tool Registry**: A centralized inventory of registered tools with validated JSON schemas, ownership, and read/write classifications. Plain English: "The official catalog of all APIs and functions available to agents." - **MCP Governance**: Policy and security controls wrapped around Model Context Protocol (MCP) servers and clients. Plain English: "Keeping tool plugins using the MCP standard secure and permissioned." - **Agent Context Layer**: The data retrieval and RAG pipeline delivering permission-aware, time-correct document context to the agent. Plain English: "The system that finds and provides relevant documents to the agent when it needs information." - **Context Bundle**: The exact snapshot of retrieved documents, source references, and metadata supplied to an agent for a specific step. Plain English: "The package of information given to the agent for a single turn." - **Agent Memory**: Persistent storage of session history, user preferences, workflow state, and verified organizational findings. Plain English: "What the agent remembers across turns and future conversations." - **Agent Registry**: The authoritative central directory listing every registered agent, code version, environment, and accountable owner. Plain English: "The master list of all AI agents running in the company." - **Agent Identity**: The unique workload and logical identity (e.g. SPIFFE ID, OAuth client) representing an autonomous agent. Plain English: "The digital ID card that identifies an agent to other systems." - **Agent Ownership**: Explicit mapping of named business, technical, and security leaders accountable for an agent's operation. Plain English: "Knowing exactly who to call when an agent makes a mistake." - **Agent Authority**: The explicit scope of actions, resources, budgets, and delegations an agent is permitted to execute. Plain English: "What an agent is allowed to do, spend, or modify." - **Authority Manifest**: A signed policy object defining an agent's capability grants, resource boundaries, and expiration conditions. Plain English: "The written permission document that sets an agent's limits." - **Runtime Authority Lease**: A short-lived cryptographic token granting temporary permission for a specific sub-task or execution loop. Plain English: "A temporary pass that gives an agent permission for a few minutes." - **Agent Delegation**: The process of a parent agent spawning or assigning sub-tasks and authority to child agents. Plain English: "When one agent hires or tasks another agent to help with work." - **Runtime Policy**: Policy-as-code rules evaluated dynamically before every tool call or external effect. Plain English: "Security and business rules that run right before an action takes place." - **Governed Execution**: The runtime process of evaluating identity, authority, context, policy, budget, and approval before allowing an action. Plain English: "The core process of checking all rules before letting an agent execute a step." - **Pre-Action Authorization**: Evaluating policy and permissions BEFORE a tool call or external API request executes. Plain English: "Checking permissions BEFORE doing something, not after." - **Human Escalation**: Routing high-risk or ambiguous agent requests to human reviewers with structured evidence. Plain English: "Asking a human for permission when the risk is high or confidence is low." - **Runtime Budget Guardrail**: Pre-execution reservations and hard limits on model tokens, API costs, and compute duration. Plain English: "A financial cap that stops an agent if it spends too much money." - **Agent Episode**: The complete end-to-end trajectory of an agent run from initial objective trigger to final outcome. Plain English: "The full story and record of one complete job done by an agent." - **Agent Evaluation**: Systematic testing of trajectory quality, tool arguments, policy adherence, and outcome correctness. Plain English: "Testing agents continuously to make sure they do good work." - **Evidence Event**: An immutable log entry recording a material decision, policy check, tool execution, or outcome. Plain English: "A single tamper-proof receipt of something important an agent did." - **Evidence Manifest**: A compiled cryptographic package gathering all Decision Receipts and context snapshots for an episode. Plain English: "The complete audit folder for an agent job." - **Decision Receipt**: A cryptographically signed record proving identity, authority, context, policy decision, and action taken. Plain English: "A digital receipt proving who approved an action and why." - **Execution Record**: The technical log documenting inputs, outputs, side-effects, and duration of a tool call. Plain English: "The detailed technical receipt of a tool call." - **Policy Decision Record**: A recorded proof showing which policy rules ran, inputs evaluated, and the resulting Allow/Deny decision. Plain English: "Proof of why a security policy allowed or blocked an action." - **Outcome Verification Record**: A post-execution audit record verifying whether the intended real-world side effect actually succeeded. Plain English: "Proof that the real-world job actually succeeded as intended." - **Agent Revocation**: The administrative or automated process of revoking an agent's identity, authority, and running tasks. Plain English: "The kill-switch that instantly stops a compromised or malfunctioning agent." - **Agent Production Readiness**: Verification that an agent meets all 18 production acceptance controls before live deployment. Plain English: "Checking off all safety boxes before letting an agent go live." - **Evidence and Control Plane**: The cross-stack governance layer connecting identity, authority, policy, approvals, budgets, observability, evidence, and revocation across all 15 layers. Plain English: "The master control system surrounding the entire agent stack that enforces rules and collects evidence." ## Contact & Architecture Review Request an Enterprise Architecture Review at /architecture-review or access the interactive assessment tool at /agent-stack-assessment.