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.

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"] }
}

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.

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.