AaaS - Agent as a Service

The open standard for governed autonomous stewardship: every serious software application gets a built-in, policy-governed, fully auditable digital operator.

Term Provenance

Agents as a Service (AaaS) in its stewardship-first meaning — one governed steward agent embedded per application — was authored by Kirk LaSalle, with dated artifacts in this repository from October 15, 2024 (AGENTIC_PRIME_DIRECTIVE.md: "a governance-native Agents-as-a-Service runtime") and March 8, 2025 (Permanent_Active_Directives.txt). This predates the broader industry adoption of the phrase in 2026. The industry usage ("agents as digital employees") and this standard's usage are distinct: AaaS here is an architecture and conformance standard, not a labor-replacement pitch.

What AaaS Actually Is

AaaS (Agent as a Service) is a software architecture and operating model where each application has a dedicated steward agent that continuously protects, operates, improves, and explains that application.

AaaS is not just chatbot integration. It is:

• A productized runtime role for agents inside software systems.
• A reliability and governance layer for AI-driven operations.
• A measurable service with SLAs, policy controls, and economic efficiency metrics.

In plain terms: every serious software application gets a built-in digital operator.

AaaS at a Glance

flowchart LR
    OP["Human Operator"]
    subgraph APP["Your Application"]
        G1["Guardian One<br/>Steward Agent"]
        SVC["Application<br/>Services"]
    end
    GOV["Governance Plane<br/>10 Laws · Policy · Approvals"]
    LED["Evidence<br/>Append-only Ledger"]

    OP -->|"goals · approvals · kill switch"| G1
    G1 -->|"protects · operates · improves · explains"| SVC
    G1 -->|"every governed action"| GOV
    GOV -->|"allow · deny · require approval"| G1
    G1 -->|"full trace"| LED
    LED -->|"transparent evidence"| OP

    classDef operator fill:#7c3aed,stroke:#4c1d95,color:#ffffff
    classDef steward fill:#4f46e5,stroke:#312e81,color:#ffffff
    classDef app fill:#6b7280,stroke:#374151,color:#ffffff
    classDef governance fill:#059669,stroke:#064e3b,color:#ffffff
    classDef evidence fill:#d97706,stroke:#92400e,color:#ffffff
    class OP operator
    class G1 steward
    class SVC app
    class GOV governance
    class LED evidence

Loading

Core Thesis

As software systems become more dynamic, uptime and quality can no longer rely only on human operators and static automation. AaaS introduces a persistent agent layer that can:

• Maintain system state.
• Detect and resolve issues.
• Route and validate work.
• Enforce governance and safety boundaries.
• Report transparent operational evidence to human operators.

Why Now

Market pressure is converging around four demands:

• Reliability: teams need autonomous support without hidden behavior.
• Governance: organizations need policy enforcement and auditability.
• Cost control: AI usage must produce measurable engineering value.
• Deployment flexibility: local, remote, and cloud options are all required.

AaaS Positioning

AaaS is positioned between three categories and unifies them:

• Agent runtime platforms (execution and orchestration).
• LLM observability and evaluation systems (quality and efficiency signals).
• AI governance and red-team controls (safety and compliance).

AaaS differentiator: stewardship-first architecture where one platform owns runtime control, policy control, and economics of agent behavior.

Relationship to LLRE and Guardian One

• Guardian One is the first-generation steward model in AaaS.
• LLRE integration is the first primary toolset for efficiency, request effectiveness, and operator transparency.
• Governance as a Service provides the governing framework (10 Laws) and development security integration for the Guardian One model.

AaaS combines these into one market-facing standard: governed autonomous stewardship for software applications.

Current Program Mode

• Status: development mode with active audit learning and iterative hardening.
• Standard target: world-class reliability, governance, transparency, and security.

Product Pillars

1. Steward Agent Runtime

• Persistent, application-scoped autonomous operator.
• Lifecycle modes: observe, assist, act, recover.

1. Governance and Policy Fabric

• Cryptographic integrity for core directives.
• Tiered policy engine with approval gates and denials.

1. Full Transparency and Control Plane

• Complete traceability of decisions, tools, side effects, and approvals.
• Real-time operator dashboard for intervention and override.

1. Engineering Economics

• First-class metrics for latency, token economics, success quality, and tool precision.
• Budget and efficiency controls tied to deployment objectives.

1. Deployment Flexibility

• Local-first and edge-capable options.
• Remote and cloud control-plane support.
• Hybrid deployment for regulated environments.

Reference Architecture

The five pillars compose into one governed runtime. Requirement IDs refer to AaaS_STANDARD_v0.1.md; per-Law control detail lives in GOVERNANCE.md.

flowchart TB
    subgraph OCP["Operator Control Plane"]
        direction LR
        DASH["Real-time Dashboard<br/>traces · health · costs"]
        APPR["Approval Queue<br/>timeout + explicit deny (G-003)"]
        KILL["Kill Switch (R-004)<br/>scoped pause (R-005)"]
    end

    subgraph APPB["Application Boundary — one steward per application (R-001)"]
        direction LR
        subgraph G1["Guardian One Steward Runtime"]
            MODES["Modes (R-002)<br/>monitor · recommend · execute"]
            REC["Recovery fallback<br/>chains (R-006)"]
        end
        APP["Governed Application<br/>services · data · workflows"]
    end

    subgraph GOVP["Governance and Policy Fabric — GaaS"]
        direction LR
        CHART["10 Laws Charter<br/>digest-pinned · attested (S-001)"]
        PE["Policy Engine (G-002)<br/>allow · deny · require_approval"]
        GATES["Gates (R-003)<br/>interdiction · quarantine · risk · approval"]
        FAILSAFE["Fail-safe restriction on<br/>integrity failure (G-005)"]
    end

    subgraph TRANS["Transparency Plane"]
        direction LR
        LEDGER["Append-only Ledger<br/>SHA-256 hash-chained (G-004)"]
        TRACE["Trigger-to-outcome<br/>lineage (O-001)"]
        SEC["Security events (S-003)<br/>actor · action · target · time · outcome"]
    end

    subgraph ECON["Economics Plane — LLRE"]
        direction LR
        METRICS["Effectiveness metrics (O-002)<br/>RSI · CSR · TCA · TEQ"]
        BUDGET["Budgets + alerts (O-004)<br/>reliability telemetry (O-003)"]
    end

    DEPLOY["Packaging parity (P-series): API · Plugin/Add-on · Sidecar/Embedded — same MUST requirements"]

    OCP <-->|"control · evidence"| G1
    G1 -->|"stewards"| APP
    G1 -->|"every governed action"| PE
    CHART -->|"constitutional law"| PE
    PE --> GATES
    GATES -->|"authorized execution only"| G1
    PE -->|"all decisions"| LEDGER
    G1 -->|"all actions"| LEDGER
    LEDGER --> TRACE
    LEDGER --> SEC
    LEDGER -->|"evidence"| DASH
    G1 -->|"request telemetry"| METRICS
    METRICS --> BUDGET
    BUDGET -->|"cost governance"| DASH
    APPB -.- DEPLOY

    classDef operator fill:#7c3aed,stroke:#4c1d95,color:#ffffff
    classDef steward fill:#4f46e5,stroke:#312e81,color:#ffffff
    classDef app fill:#6b7280,stroke:#374151,color:#ffffff
    classDef governance fill:#059669,stroke:#064e3b,color:#ffffff
    classDef evidence fill:#d97706,stroke:#92400e,color:#ffffff
    classDef econ fill:#0284c7,stroke:#075985,color:#ffffff
    classDef neutral fill:#334155,stroke:#0f172a,color:#ffffff
    class DASH,APPR,KILL operator
    class MODES,REC steward
    class APP app
    class CHART,PE,GATES,FAILSAFE governance
    class LEDGER,TRACE,SEC evidence
    class METRICS,BUDGET econ
    class DEPLOY neutral

Loading

Governed Action Lifecycle

Every autonomous action follows one auditable path from trigger to outcome — including the paths where nothing executes.

sequenceDiagram
    autonumber
    participant T as Trigger
    participant G as Guardian One
    participant P as Policy Engine (GaaS)
    participant O as Operator
    participant A as Tool Adapter
    participant L as Append-only Ledger

    T->>G: event (alert · schedule · request)
    G->>G: classify blast radius (RISK-CLASS)
    G->>P: request decision (G-002)
    P->>L: decision + lineage recorded (G-004)

    alt allow
        P-->>G: allow
        G->>A: execute action
        A-->>G: receipt — real or failed, never faked (LAW7-NOFAKE)
    else require_approval
        P-->>G: require_approval (R-003)
        G->>O: approval request with timeout (G-003)
        alt operator approves
            O-->>G: signed ApprovalToken — single action, expiring (S-002)
            G->>A: execute action
            A-->>G: receipt
        else deny or timeout
            O-->>G: deny / no response
            G->>L: refusal + deciding policy (RISK-000)
        end
    else deny
        P-->>G: deny
        G->>L: refusal + deciding policy (RISK-000)
    end

    G->>L: trigger-to-outcome trace (O-001)
    G->>G: emit LLRE metrics — RSI · CSR · TCA · TEQ (O-002)
    Note over O,L: Kill switch (R-004) halts autonomous execution at any point.<br/>Governance integrity failure forces fail-safe restriction (G-005).

Loading

Target Users

Primary:

• Software platform teams.
• SRE and DevOps organizations.
• AI platform engineering teams.

Secondary:

• Security and governance teams.
• Product operations.
• Regulated enterprise operators.

Success Outcomes

AaaS is successful when teams can show:

• Higher uptime and faster recovery.
• Fewer unsafe or unexplained autonomous actions.
• Lower cost per successful outcome.
• Stronger audit readiness and operator trust.

Documentation

• Product requirements: see PRD.md
• Execution plan: see ROADMAP.md
• Standard specification: see AaaS_STANDARD_v0.1.md
• Governance control registry (10 Laws → runtime controls): see GOVERNANCE.md
• Governance Council charter: see GOVERNANCE_COUNCIL_CHARTER.md
• Machine-readable requirement manifest: see spec/requirements.json
• Executable conformance harness: see conformance/harness.py
• World-class implementation path: see WORLD_CLASS_DEVELOPMENT_PLAYBOOK.md
• Critical audit (step two): see CRITICAL_AUDIT_REPORT_STEP2.md
• Change history: see CHANGELOG.md
• Contributing: see CONTRIBUTING.md
• Security policy: see SECURITY.md
• License: Apache-2.0, see LICENSE

Running the Conformance Harness

The harness executes the documentation-scope checks of the standard against this repository and emits the release-gate decision report required by CA-003.

python conformance/harness.py

Requires Python 3.10+ with no third-party dependencies. CI runs it on every push and pull request. Optional pytest integration:

python -m pytest conformance/ -q

How AaaS Becomes a Standard

AaaS becomes a standard by moving from narrative to enforceable specification.

From Specification to Certification

flowchart LR
    STD["AaaS Standard v0.1<br/>41 normative requirements<br/>MUST · SHOULD · MAY"]
    MAN["spec/requirements.json<br/>machine-readable manifest<br/>(CA-001)"]
    HAR["conformance/harness.py<br/>executable harness · CI-enforced<br/>(CA-002)"]

    subgraph CHECKS["Check classes"]
        direction TB
        CHK["CHK — documentation scope<br/>8 checks · executable today · all passing"]
        RT["RT — runtime scope<br/>23 checks · all passing"]
        EV["EV — reviewed evidence<br/>6 exact-hash approvals"]
    end

    GATE{"Release Gate<br/>(CA-003)"}
    DRAFT["Draft publication<br/>go"]
    PROD["Profile A certification<br/>production go · 30/30 MUST"]
    BADGE["Certification Badge Registry<br/>AaaS Conformant · Adapter type · Profile A/B/C"]

    STD --> MAN --> HAR
    HAR --> CHK
    HAR --> RT
    HAR --> EV
    CHK --> GATE
    RT --> GATE
    EV --> GATE
    GATE --> DRAFT
    GATE --> PROD
    PROD -. all gates green .-> BADGE

    classDef spec fill:#4f46e5,stroke:#312e81,color:#ffffff
    classDef pass fill:#059669,stroke:#064e3b,color:#ffffff
    classDef gate fill:#7c3aed,stroke:#4c1d95,color:#ffffff
    class STD,MAN,HAR spec
    class CHK,RT,EV,DRAFT,PROD pass
    class GATE gate
    class BADGE gate

Loading

1. Define normative requirements

• Publish mandatory statements for runtime behavior, governance controls, and audit evidence.
• Use requirement language: MUST, SHOULD, MAY.

1. Certify conformance

• Create a conformance profile for Guardian One implementations.
• Require passing tests for policy gates, trace completeness, and recovery behavior.

1. Version and govern the standard

• Adopt semantic versioning for the AaaS standard.
• Establish change control and review for the 10 Laws and enforcement contracts.

1. Prove operational fitness

• Require due diligence audit results before release readiness.
• Require pilot evidence across local, remote, and cloud operational modes.

Due Diligence Audit Snapshot

Current status assessment:

• Strength: clear product thesis, first-generation model identity (Guardian One), and LLRE-first efficiency direction.
• Strength: Governance as a Service and 10 Laws are explicitly in scope.
• Strength: machine-readable 41-requirement manifest and executable conformance harness are published.
• Strength: Guardian One Profile A passed 30/30 MUST requirements with zero open critical findings.
• Strength: the complete evidence bundle includes runtime, adversarial, pilot, risk, and exact-hash reviewed evidence.

Next maturity actions:

• Publish the assessor handbook with worked certification examples.
• Exercise Profile B operational controls and recovery playbooks.
• Validate additional application adapters without changing the Profile A baseline.

Adoption Architecture

AaaS should be adopted through a layered model, not a single packaging choice.

1. API-first core

• Canonical integration surface for runtime, governance, and telemetry.
• Best fit for portability and enterprise interoperability.

1. Plugin and add-on adapters

• Fast adoption wrappers for specific platforms and ecosystems.
• Must map to the same standard controls and evidence outputs.

1. Sidecar and embedded runtime

• Local and regulated deployment option using the same conformance requirements.
• Best fit for sovereign, offline, and high-control environments.

Packaging Decision Matrix

Packaging path	Primary value	Primary risk	Best fit
API integration	Broad interoperability	Requires integration engineering	Platform and enterprise teams
Plugin/Add-on	Fast distribution and adoption	Adapter drift from core semantics	Ecosystem-led growth
Sidecar/Embedded	Strong local control and data boundaries	Operational complexity	Regulated and mission-critical workloads

Adapter Conformance Principle

All adapters MUST preserve:

• 10 Laws enforcement path.
• Policy decision path (allow, deny, require approval).
• Trace lineage and audit evidence schema.
• LLRE metric emission contract.
• Kill switch and fail-safe behavior.

Critical Audit Update (Step Two)

Step-two critical audit closure:

• Draft publication: Go.
• Guardian One Profile A production certification: Go.

Closed blockers:

• Executable conformance harness and machine-readable requirement manifest are published.
• Runtime, governance, adversarial, pilot, and reviewed evidence are complete.
• The final gate passes 30/30 MUST requirements with zero open critical findings.

Required closure artifacts:

• Conformance harness output report.
• Requirement manifest with test linkage.
• Governance adversarial validation report.
• Release-gate decision report.

Remediation status (2026-08-09): complete. Guardian One 0.1.0.dev0 is the first Profile A certified reference candidate. Its six reviewed evidence checks are bound to exact artifact hashes; PrismRefraction remains an optional secondary adapter outside the certification critical path.

Version

• Version: 0.1.0 (v0.1.0-draft public release)
• Status: Public draft standard with Guardian One Profile A production certification
• Repository: https://github.com/kirklasalle/AaaS-standard
• License: Apache-2.0
• Owner: AaaS initiative (Kirk LaSalle)