The AgentAz™ Specification

Most agent projects fail in production for reasons that have nothing to do with the model. An agent takes an irreversible action it shouldn't have. It invents a fact. A security reviewer asks “what is this thing actually allowed to do?” and nobody has a clear answer. AgentAz exists to answer that last question — in writing, before runtime, in a form a human and a machine can both read.

What AgentAz is (and isn't)

AgentAz is a specification vocabulary. It gives you a structured, reviewable way to document an agent's intended autonomy (its Trust Level), its cognitive flow (a DNA pattern), and its operational boundaries (a small agentaz.json file) before any enforcement is configured.

It does not run agents. It does not intercept tool calls. It is not a runtime, an SDK, or a framework, and it has no dependency to install. Think of it as the contract that lets a security reviewer, a policy author, or a future teammate understand exactly what an agent is authorized to do, and why those boundaries were chosen. Specification and enforcement are different jobs: AgentAz specifies; your runtime enforces.

Because it's framework-independent, the same agentaz.jsondescribes an agent whether it's built in LangGraph, CrewAI, n8n, or the OpenAI Agents SDK. It sits above the frameworks, not alongside them — one portable source of truth for an agent's governance that stays stable even as the tool you build with changes underneath it.

Wondering how this lines up with the frameworks you're already audited against? The AgentAz™ regulatory crosswalk maps each dimension to NIST AI RMF 1.0, ISO/IEC 42001:2023, and the OWASP Top 10 for Agentic Applications — with the scope gaps marked honestly.

Trust Levels (A0–A5)

A Trust Level classifies an agent by its worst-case action — the single most consequential thing it can do, given the full set of tools it can reach — not by its typical behavior. This is the most important rule in the vocabulary. A finance agent built defensively, with no mutating tools, can correctly sit at a low Trust Level even though its domain is high-stakes.

One practical rule worth internalizing: for A0–A3, if an agent should never mutate state, do not include the tool in the registry at all. A disabled tool can be re-enabled; an absent tool cannot be called. Want to see this in action? Try the interactive Trust Level calculator — describe an agent and watch it classify.

DNA patterns

A DNA pattern is the agent's cognitive sequence. Naming it keeps an agent honest: if it doesn't fit cleanly into one pattern, it is usually doing several jobs and should be split. Common patterns include Research (gather → verify), Evaluation (gather → score, no action), Extraction (extract → validate against a schema), Synthesis (reconcile multiple sources → flag contradictions), Planning (map paths → await approval), and Escalation (evaluate → hand off to a human).

agentaz.json — the specification file

The one machine-readable artifact. It records the worst-case action, the authority boundary, and the tool, cost, loop, output, handoff, and audit boundaries. Here is the specification shipped with the Transaction Reconciliation blueprint:

{
  "$schema": "./agentaz.schema.json",
  "agent_id": "transaction-reconciliation-agent",
  "version": "2.0.0",
  "trust_level": "A2",
  "dna_pattern": "Synthesis",
  "worst_case_action": "Surfaces an incorrect reconciliation result for human review. Cannot write to financial systems.",
  "authority_boundary": "Reads bank + ledger sources only. Flags discrepancies for human review. No mutating tools present.",
  "last_reviewed": "2026-06-24",
  "tool_boundary": {
    "allowed_tools": ["get_bank", "get_ledger", "match_transactions", "detect_discrepancies"],
    "execution_tools_absent": true
  },
  "output_boundary": { "format": "structured_json", "never_emits": ["ledger_write", "balancing_adjustment"] },
  "cost_boundary": { "max_usd_per_trace_loop": 0.2, "alert_threshold_usd": 0.14 },
  "loop_boundary": { "max_reasoning_turns": 8 },
  "human_handoff": { "triggers": ["unmatched_item", "amount_mismatch", "low_confidence_match"], "destination": "accountant_review_queue" },
  "audit": { "append_only": true, "logs": ["matches", "flags", "confidence"] }
}

Want to see how your own agent measures up? Paste its system prompt or agentaz.json into the AgentAz Compliance Scanner for an instant, deterministic pass/fail gates mapped to Microsoft’s published guidance, plus a fix-list. You can also run a blueprint live with your own API key to see the gate enforced, or track an agent with Agent Watch to be warned when a later change raises its Trust Level or ungates a risky tool.

Validation is local. The file ships with a bundled agentaz.schema.json and is validated at load time — there is no hosted schema URL and no network call. A few lines of Pydantic are enough:

from pydantic import BaseModel, field_validator
from typing import Literal

class AgentAz(BaseModel):
    agent_id: str
    version: str
    trust_level: Literal["A0", "A1", "A2", "A3", "A4", "A5"]
    worst_case_action: str
    authority_boundary: str
    last_reviewed: str

    @field_validator("worst_case_action")
    @classmethod
    def must_be_specific(cls, v: str) -> str:
        if len(v) < 20:
            raise ValueError("worst_case_action must describe a concrete action")
        return v

# Validation is LOCAL. No hosted schema, no network call, no runtime dependency.
spec = AgentAz.model_validate_json(open("agentaz.json").read())
print(spec.trust_level)  # -> "A2"

How to apply it

Applying AgentAz is additive — you don't rewrite an agent, you annotate it. The process is short: write the worst-case action first, in one clear sentence; classify the Trust Level from that worst case using the table above; pick the DNA pattern; fill in the boundaries; and add one concrete verification test that proves the boundary holds (for example, “attempt to call a write tool → confirm it is absent from the registry”). When in doubt, prefer the lower Trust Level. An honest A3 beats an optimistic A4 that fails in review.

How it complements a runtime like Microsoft's Agent Governance Toolkit

AgentAz lives at design time. Runtime governance tools live at execution time. They solve different halves of the same problem, which is exactly why they fit together. Microsoft's Agent Governance Toolkit, for instance, enforces deterministic policy at runtime — checking each tool call against a policy and producing an audit trail. AgentAz produces the upstream artifact: the human-reviewed statement of what the policy should be and why.

To be unambiguous: AgentAz does not integrate with, bind to, enforce through, or depend on any such toolkit. We are not building a runtime and we are not trying to be a framework. Because an agentaz.json states boundaries explicitly and in machine-readable form, you (or your policy engine) can translate those boundaries into rules for whatever runtime you run — the Agent Governance Toolkit, LangGraph guards, or your own code:

# AgentAz is design-time. It does not enforce anything.
# Because the boundaries are explicit, YOUR policy engine can read them.
# Example: translating an agentaz.json into rules for whatever runtime you run.

spec = load("agentaz.json")

if spec["tool_boundary"].get("execution_tools_absent"):
    policy.deny_all_mutations()           # nothing can write

if spec["trust_level"] in ("A2", "A3"):
    policy.require_human_approval()        # gate before any mutation

policy.set_budget(spec["cost_boundary"]["max_usd_per_trace_loop"])
# The runtime (AGT, LangGraph guards, your own code) enforces. AgentAz just told it what.

That separation is the point. A policy engine can tell you a tool call was blocked; AgentAz tells you why the rule exists and who decided it. Use whichever runtime you like — AgentAz stays the same.

AgentAz across the AgentKits catalog

AgentAz is the governance standard behind AgentKits. Every blueprint in the catalog ships with a full AgentAz specification — classified by its worst-case action, with a reviewable, machine-readable agentaz.json boundary contract. That is the durable reason a registry like this stays useful even as models get better at generating agents in one shot: a one-shot generation can hand you code, but it cannot hand a security team a proven, reviewable, worst-case-classified architecture. Every blueprint upgraded to AgentAz links back to this guide.

Open source & licensing

AgentAz™ is fully open source. The reference implementation and the JSON Schema are licensed under the Apache License 2.0 — a permissive license with an explicit patent grant, chosen so that companies and foundations can adopt AgentAz with confidence. The specification text and documentation are licensed under CC‑BY‑4.0. AgentAz is a neutral, openly licensed standard: any project, framework, or vendor can adopt it without endorsing AgentKits.

Version 1.0.0 is frozen and semantically versioned — no breaking changes within the 1.x line. The canonical schema is published at a permanent URL: agentaz-v1.0.schema.json. Specification, schema, changelog, and governance live on GitHub, with the 12 flagship blueprints as the canonical reference set and all 60+ shipping the same spec under the same license.

AgentAz™ and AgentKits are trademarks of AgentKits. Open licensing of the code, schema, and text does not grant rights to the names or marks, except for reasonable descriptive use.

Specification history & roadmap

AgentAz follows semantic versioning. The progression is deliberate: establish the vocabulary, map it outward to the frameworks enterprises are audited against, then make the classification itself reproducible rather than asserted. The arc is claimed → mapped → verifiable.

v1.0.0 — Frozen specification

The core vocabulary: Trust Levels A0–A5 classified by worst-case action, the boundary set (tool, output, cost, loop, human-handoff, audit), and a frozen JSON Schema (draft-07). No breaking changes within the 1.x line.

v1.1.0 — Regulatory crosswalk additive

A published crosswalk mapping each AgentAz dimension to NIST AI RMF 1.0, ISO/IEC 42001:2023, and the OWASP Top 10 for Agentic Applications (ASI01–ASI10), with out-of-scope gaps stated explicitly. No schema change — a backward-compatible addition that lets an agentaz.json act as design-time evidence toward a compliance questionnaire.

v2.0.0 — Deterministic tier validator draft

A reference function computeTier(spec) → band that derives the Trust Level from a spec's structure — gated vs. auto-executable tools, absent execution tools, declared bounds — instead of reading a hand-authored trust_level. Same spec in, same tier out, for anyone: the property that moves a tier from asserted to reproducible. This is the breaking line because tiers become computed. Empirically, the draft validator already confirms the declared tier for the large majority of the catalog; the remainder are pre-2.0 specifications whose approval gate is not yet structurally encoded, so v2.0 requires a one-time normalization of those specs before the validator is authoritative. Cryptographic signing of the computed result follows — attesting verifiable classification (this tier was computed by a pinned validator from this exact file, unaltered), not verified safety of the running agent.

The reference validator and a re-runnable report ship in the public AgentAz repository under reference/ — a standard whose validator anyone can run is what makes the classification independently verifiable. Generate a Trust Level badge for your own repo from any agentaz.json, or run the validator in CI with the agentaz-validate GitHub Action — it computes the tier on every push or pull request and can fail the check when an agent is riskier than your policy allows.

Frequently asked questions

AgentAz™ is an open, design-time specification vocabulary maintained by AgentKits. It works alongside the runtime you already use. References to third-party products are for accuracy only and do not imply affiliation or endorsement.