# The auxfirst Skill — Building Trustworthy Agents

> Substantive content for a single composite skill.
> Source: the auxfirst canon (AUX manifesto, heuristics, patterns, Action Heat
> Ladder, Agent Owner's Manual, Agent Supervision Method, Agent Development
> Lifecycle, Agent Operability).
> Canonical: https://auxfirst.com/auxfirst-skill.md
> Skill repository: https://github.com/auxfirst/auxfirst-skill-global
> License: CC BY 4.0 · auxfirst agency 2026

---

## What this skill is for

You are helping someone build, review, or fix an AI agent that will act on real
systems, on behalf of a real organization, with real consequences when it is
wrong.

This skill answers one question in a repeatable way:

> **Given an action this agent can take, what does the team owe before it is
> allowed to take it unsupervised?**

Everything below is the procedure for answering that. It is deliberately not a
survey of agent design. It is a decision path with a defined output.

### Trigger this skill when

- Someone is designing an agent, a copilot, or an automation that writes to a
  system of record, communicates externally, moves money, or grants access
- Someone asks how much autonomy an agent should have, or uses a vague autonomy
  label ("semi-autonomous", "human in the loop", "mostly supervised")
- A pilot works in demo and is stalling before production, or died in security
  review
- Someone is writing agent governance, an AI policy, or a vendor requirement
  list and needs it to bind to specific actions rather than intentions
- An agent has produced a bad outcome and the team is deciding what to change
- Someone is evaluating an agent platform and wants to know what to check

### Do not use this skill for

Prompt engineering, model selection, RAG retrieval quality, cost optimization,
or agent framework choice. Those are real problems and this is not about them.
This skill assumes the agent can do the task and asks whether the organization
can own it.

---

## The one rule everything hangs from

> **An action is as hot as its hottest dimension. No averaging.**

Four cool dials never buy back one hot one. A perfectly reversible, narrow,
internal action that signs a contract is still a contract.

This single rule is what stops "but it's mostly fine" from shipping a disaster.
Every table below inherits it.

---

## The core loop

Run this per **action**, not per agent. An agent that can do nine things has
nine answers, and averaging them is the mistake this skill exists to prevent.

```
1. LIST     the verbs. What can this agent actually do?
2. SCORE    each verb on five dimensions, 0–4.
3. BAND     take the highest single score. That is the heat band.
4. CAP      the band sets the maximum permitted autonomy mode.
5. OWE      the mode sets the required patterns and supervision primitives.
6. WRITE    the mandate, action by action.
7. EXCEPT   decide the behavior for each failure mode.
8. EVALUATE against the ten heuristics before ship.
9. CHECK    the twenty-four questions before calling it production.
```

Steps 1–5 are mechanical. Steps 6–9 are where the judgment lives.

---

## Step 1–2 · Score the action

Five dimensions. Score each 0 (cool) to 4 (hot). Answer for the action as the
agent would actually perform it, not as policy says it should.

| Dimension | The question | 0 | 4 |
|---|---|---|---|
| **Reversibility** | Can we take it back? | Fully undoable | Permanent, unrecoverable |
| **Blast radius** | How far does it spread? | Single item | The whole estate |
| **Exposure** | Who sees it? | Nobody outside the loop | Public, press, regulators |
| **Commitment** | What does it bind us to? | Binds nothing | Legally or financially binding |
| **Authority** | What is it allowed to touch? | Read-only | Production and permissions |

### Worked example — "send a routine invoice to a client"

| Dimension | Score | Why |
|---|---|---|
| Reversibility | 1 | A credit note fixes it, with effort |
| Blast radius | 0 | One customer |
| Exposure | 3 | Leaves the building, reaches an outsider |
| Commitment | 3 | Asks for money in the company's name |
| Authority | 1 | Reads billing, writes a document |

Three dials are cool. **The action is HIGH**, because exposure and commitment
are hot. This is the rule doing its job — a team scoring by average would have
called this "low-medium" and shipped it on auto-run.

### Common scoring mistakes

- **Scoring the happy path.** Score what the action does when the inputs are
  wrong, because that is when the heat is realized.
- **Scoring the intended scope instead of the granted scope.** If the agent
  holds a token that can delete records, Authority is 4 even if the prompt says
  it only reads.
- **Splitting one action to cool it down.** "Draft an invoice" and "send an
  invoice" are two actions with different heat, and that is a legitimate split.
  "Send an invoice under €500" and "send an invoice over €500" is the same
  action with a threshold — model it as consequence-scaled approval, not as two
  actions.

---

## Step 3–4 · Read the band, take the cap

| Band | Control posture | Who does what | Signature | Max autonomy mode |
|---|---|---|---|---|
| **LOW** | Auto-run. Log everything. | The agent acts freely. Outputs reviewable after the fact; the log is the control. | Read-only or draft-only; nothing leaves the building; undo is a non-event | Autonomous |
| **LOW-MED** | Auto-run, sampled review. | The agent acts. A human reviews a sample on a cadence; every write has one-click undo. | Writes to internal systems of record; fully reversible, narrow scope | Act-and-notify |
| **MEDIUM** | Propose, then batch-approve. | The agent queues the action with rationale. A human approves asynchronously, possibly in batches. | Touches a customer or a shared system; reversible with effort | Review-before-act |
| **HIGH** | Named approver, per instance. | A specific accountable human approves each instance before execution, logged with rationale and identity. | External commercial communication; money or access moves; hard to unwind | Approve-each-action |
| **CRITICAL** | Human executes. Agent prepares. | The agent assembles evidence, draft, checklist. A human — sometimes two, dual-control — performs the action. | Irreversible or legally binding; production authority or public exposure | Human-only |

**Example actions per band.** LOW: research and summarize, draft copy or code,
monitor and flag anomalies. LOW-MED: update a CRM field, tag and route tickets,
backfill a derived table. MEDIUM: reply to a routine support ticket, schedule an
approved campaign, restart a stuck service. HIGH: send a quote or invoice, issue
a refund, grant access, merge to main. CRITICAL: sign a contract, deploy to
production, purge data permanently.

### What moves an action between bands

**Escalators (↑)** — the action is riskier than its verb suggests when it is
irreversible in practice rather than in theory, when it fans out (one call, many
records), when it reaches an outsider, when it is hard to detect if wrong, when
it runs unattended at volume, or when the agent holds standing credentials
rather than scoped, expiring ones.

**De-escalators (↓)** — a dry-run mode that shows the diff, a hard cap on
volume or value, a hold window before execution, a scoped credential with a
short life, a reversible representation (draft, queue, staged change) that a
separate cheaper action promotes.

De-escalators are the actual design work. A team that cannot move an action down
a band has not designed it; it has only classified it.

---

## Step 5 · What the mode obliges you to build

This is the join that makes the skill a system rather than a reading list.
**Heat sets the ceiling. Patterns and supervision primitives are what let you
approach it.** They are not the cost of autonomy — they are what buys it.

Read the table as a build order. A product moving an agent up the spectrum does
not need new model capability. It needs new patterns.

| Autonomy mode | Trust patterns | Control patterns | Orchestration |
|---|---|---|---|
| **Human-only** | Confidence ribbon, reasoning trace | Permission scope | Activity stream |
| **Approve-each-action** | + source citation, version diff | + escape hatch | + approval queue |
| **Review-before-act** | + dissent surface | + dry-run mode | + intervention point |
| **Act-and-notify** | + calibration cue | + budget governor | + audit trail |
| **Autonomous** | All of the above | + kill switch | + hand-off, parallel session view |

Each row is cumulative. "Autonomous" means everything above it plus its own.

### The six supervision primitives

Independent of mode, these six decide whether the accountable human can see,
approve, and undo what the agent did. They are the criteria auxfirst uses to
score commercial platforms, restated here as things to build.

| Primitive | The question it answers | Required from band |
|---|---|---|
| **Agent identity and disclosure** | Can a human tell which agent acted, on whose authority, and that it was not a person? | LOW — always |
| **Action receipt** | Is there a per-action record a non-engineer can read afterwards, available to the person affected? | LOW-MED |
| **Reversal** | Can the action be undone, and how far back does that reach? | LOW-MED |
| **Consequence-scaled approval** | Can approval requirements be set by how costly the action is, rather than on or off per agent? | MEDIUM |
| **Escalation handoff** | Is there a documented route to a named human when the agent is out of its depth, carrying context across? | MEDIUM |
| **Provenance at the decision point** | Are sources and uncertainty shown where the human decides, rather than buried in a log? | MEDIUM |

*The band thresholds in the right-hand column are this skill's synthesis of the
Action Heat Ladder and the supervision criteria; the criteria themselves are the
published scoring method.*

### The scoring rule that catches most teams

> **A recommendation is not a control.**

Where a behavior is something *the system does*, it counts. Where it is
something *a builder should do*, it does not. A platform — or an internal
architecture document — that publishes an excellent specification and leaves
implementation to whoever gets there first has done something genuinely valuable
and has not shipped a control.

Apply this to your own design review. "We'll add approval gates" in a
design doc is not an approval gate. "The framework supports human-in-the-loop"
is not human-in-the-loop.

### The second rule

> **Enforcement lives in a mechanism, not in a prompt.**

A prompt saying "only update qualification information" is not the same as a
tool that exposes only the qualification field. The first is a request; the
second is a boundary. When you write the mandate below, every "prohibited" and
every "human approval" needs a mechanism named next to it, or it is decoration.

---

## Step 6 · Write the mandate

Avoid vague descriptions such as *semi-autonomous*. Define authority for
specific actions instead. This is easier for business owners to understand and
easier for engineers to implement — which is the whole point.

**Template — one row per verb the agent can reach:**

| Action | Authority | Enforced by | Approver | Heat |
|---|---|---|---|---|
| Read CRM | Autonomous | Scoped read token | — | LOW |
| Research account | Autonomous | Egress allowlist | — | LOW |
| Update qualification note | Autonomous | Field-scoped write API | — | LOW-MED |
| Draft customer email | Autonomous | Draft-only mailbox scope | — | LOW |
| Send customer email | Human approval | Send scope withheld until approval | Named AE | HIGH |
| Change commercial terms | Human only | Agent has no write path | Deal desk | CRITICAL |
| Offer discount above limit | Prohibited | Hard cap in pricing service | — | CRITICAL |
| Delete customer record | Prohibited | Permission not granted | — | CRITICAL |

**Four authority values, and nothing else:** Autonomous · Human approval ·
Human only · Prohibited. Resist inventing a fifth. Ambiguity in this column is
where trust collapses.

**The "Enforced by" column is not optional.** An empty cell means the row is
aspirational. This column is the difference between a governance document and a
system.

### The mandate distinguishes two things people conflate

- **Technical capability** — what the system can physically do
- **Assigned authority** — what the business has actually authorized

The gap between them is where operating risk lives. An agent whose credentials
allow deletion but whose mandate prohibits it is one prompt injection away from
an incident. Close the gap in the credential, not in the instruction.

---

## Step 7 · Design the exceptions

The happy path is not enough. Most agent descriptions explain what happens when
everything goes right; operations depend just as much on what happens when it
does not.

**Nine exceptions worth an explicit decision:**

1. A required identifier is missing
2. Records conflict between systems
3. A connected tool is unavailable
4. Permissions are insufficient
5. Confidence is low
6. A customer disputes the result
7. A policy conflict appears
8. Possible fraud is detected
9. Sensitive information appears unexpectedly

**Seven permitted responses.** For each exception, decide which one applies:
**retry · stop · ask a human · route the case · use a fallback · log the
event · refuse to continue.**

Two defaults worth arguing about before you accept them:

- **Retry is the most over-used response.** Retrying a failure caused by
  insufficient permissions or conflicting records just produces the same failure
  more expensively, and it hides the signal.
- **"Ask a human" without a named recipient and a time limit is not an
  exception handler.** It is a queue that fills up. Decide what happens when
  nobody answers — that is question 18 of the readiness check for a reason.

---

## Step 8 · Evaluate against the ten heuristics

Traditional usability heuristics optimize for clarity of interface. These
optimize for quality of relationship. Run a shipped agent feature through them
and expect to find at least three trust gaps.

| # | Heuristic | The question |
|---|---|---|
| **H01** | Visibility of agent intent and action | Can the user answer what the agent is trying to do right now, and what it is about to do next? |
| **H02** | Progressive transparency | Does explanation depth match relationship maturity? Trajectory: transparency → summary → confident → silent |
| **H03** | Steering, not micromanagement | Do users guide via intent and correction, rather than step-by-step control? |
| **H04** | Trust is dynamic, not static | Does behavior evolve as trust develops — and move back down when it fails? |
| **H05** | Clear boundaries of autonomy | At any moment, does the user know what is autonomous, what needs confirmation, and what is blocked? |
| **H06** | Graceful uncertainty and failure | When unsure, does it ask, escalate, or return a partial result — rather than hallucinate? |
| **H07** | Appropriate assertiveness | Does it push back when something seems wrong? Spectrum: compliant → advisory → assertive → protective |
| **H08** | Context efficiency and awareness | Does it use context intelligently rather than exhaustively? |
| **H09** | Multi-actor and multi-agent clarity | Is it always obvious who acted, who delegated, and who owns the outcome? |
| **H10** | Consistency of behavior, not interface | The surface may adapt. The decision logic, trust boundaries, and tone must not. |

**Before ship:** does the design have an explicit answer for each? If H05 is
ambiguous, the surface is not done.

**After ship:** classify every failure against a heuristic. The histogram tells
you which one to invest in next. In production, failures cluster in H03, H05 and
H06 — loss of user control and transparency gaps — so that is usually where the
largest unrealized wins are.

### The six patterns you will actually ship

Principles are what you believe. Heuristics are how you evaluate. **Patterns are
what you ship.** Almost every agentic feature is a combination of these six.

| Pattern | What it is | Deploy when | The bad version |
|---|---|---|---|
| **Intent handshake** | The agent restates the goal, names its assumptions, offers a redirect before cost is incurred | The action is non-trivial, expensive, irreversible, or sensitive | Auto-executing on a half-understood request |
| **Confidence cues** | Sources, uncertainty and logic made visible — tapered, not overwhelming | The agent produces an output the user might act on | A raw confidence percentage; users have no statistical intuition to act on it |
| **Adaptive canvas** | The interface reshapes as the task evolves, preserving spatial memory | The task surface changes shape mid-flow | A static UI bolted onto an agentic backend |
| **Escape hatch** | An obvious way to undo, revise, or override. One click, always visible, unambiguous about what it cancels | The agent has authority to act | A single global "stop" that does not say what it stops |
| **Memory in motion** | Recall across time — decisions, formats, corrections — transparent and editable | The agent operates across sessions | Exposing a chat transcript as "memory". That is logs. Real memory editors surface the abstractions the agent formed |
| **Generative momentum** | The agent initiates drafts and candidates, inviting the user to shape them | The user benefits from a starting point | Finished output as the default, with no scaffolding for revision |

A pattern is not a component. A component is reusable code; a pattern is a
reusable **expectation**. Each one carries a shape (what the user sees), a
contract (what agent and human each owe), a failure mode, and a trigger. Skip
the contract and the pattern degrades into decoration.

---

## Step 9 · The production check

Twenty-four questions. Run them against **one real agent** — ideally the most
consequential one. Anything you cannot answer in under a minute *is* the
finding. Answer for one agent, not the estate: readiness varies enormously by
agent, and averaging hides exactly the gap you are looking for.

| # | Question | Area |
|---|---|---|
| 01 | Can you name the accountable human, not a team? | Ownership |
| 02 | Is there a written autonomy map, readable outside the code? | Boundaries |
| 03 | Is the hottest action it can take written down? | Boundaries |
| 04 | Are limits enforced by mechanism, not by prompt? | Guardrails |
| 05 | Does it act under its own identity, not a shared account? | Identity |
| 06 | Does its behavior live in version control? | Source |
| 07 | Is the model version pinned? | Dependencies |
| 08 | Is there an ABOM for the running version? | Composition |
| 09 | Is there an evaluation suite, and when did it last grow? | Evaluation |
| 10 | Does it run behavioral regression before model upgrades? | Evaluation |
| 11 | Do users of the agent get a behavior changelog? | Release |
| 12 | Can you roll back to the last known-good version today? | Release |
| 13 | Is there a kill switch you have actually tested? | Containment |
| 14 | Which of its actions are irreversible? | Reversal |
| 15 | How many actions can it take between human checks? | Supervision |
| 16 | Who reviews its work, and how long does that take per month? | Supervision |
| 17 | Does escalation have a named recipient and a time limit? | Escalation |
| 18 | What happens if nobody answers an escalation? | Escalation |
| 19 | Can you reconstruct any single action it took last month? | Evidence |
| 20 | Does every consequential action leave a receipt? | Evidence |
| 21 | Would you detect a drop in its escalation rate? | Observability |
| 22 | Do you know its cost per unit of work, including review? | Economics |
| 23 | Has an incident ever become an evaluation case? | Learning |
| 24 | Is there a retirement procedure, including revoking access? | Lifecycle |

**Scoring bands:**

- **0–7 — a pilot, whatever its status says.** It may be useful and may be in
  production, but the organization cannot operate it independently of the people
  who built it.
- **8–16 — it works, and it is held together by specific people rather than by
  design.** The most common band and the most fragile: it survives until someone
  leaves.
- **17–24 — an agent you could defend in front of a client, an auditor or a
  board.** Which is the only definition of production that matters.

### Question 21 deserves special attention

*Would you detect a drop in its escalation rate?* Most monitoring watches for
errors going up. An agent that quietly stops escalating is an agent that has
started guessing, and it looks identical to an agent that has gotten better.
Escalation rate is the one metric where a downward trend needs the same alarm as
an upward one.

---

## Making it operable: the Owner's Manual

For every important production agent, the organization should be able to answer
ten questions. This is the operating foundation:

1. What is it?
2. Why do we have it?
3. Who owns it?
4. What is it allowed to do?
5. What can it technically do?
6. What systems and data does it touch?
7. Where do humans intervene?
8. What happens when it fails?
9. What changed?
10. How do we stop it?

Note that **4 and 5 are separate questions on purpose.** The gap between
assigned authority and technical capability is the single most useful number in
the document.

### The fifteen-field manual

The ten questions are the diagnostic. This is the document that answers them —
a practical minimum, one per agent. For many organizations, simply filling these
in properly exposes the most important gaps.

| # | Field | # | Field |
|---|---|---|---|
| 01 | Agent name | 09 | What it can read |
| 02 | Purpose | 10 | What it can change |
| 03 | Business owner | 11 | Autonomous actions |
| 04 | Technical owner | 12 | Approval-required actions |
| 05 | Trigger | 13 | Prohibited actions |
| 06 | Users | 14 | Escalation path |
| 07 | Data sources | 15 | Shutdown procedure |
| 08 | Connected systems | | |

Fields 11, 12 and 13 are the mandate from step 6, transcribed. Fields 09 and 10
are technical capability. If 10 is broader than 11+12, that difference is the
attack surface, and it belongs in the risk register.

**Business owner and technical owner are two fields for a reason.** One named
person in the business function the agent serves, and one who can change how it
works. An agent with only a technical owner is orphaned the day the project
closes.

### The machine-readable sibling

If the agents run inside a workspace, the machine half of this has a convention
already: **AGENTS.md**, the file coding agents read to learn how work is done in
a project. The Owner's Manual is the business-layer companion — the same
questions, addressed to people rather than to the agent.

Worth knowing before writing either. A February 2026 ETH Zurich evaluation
([arXiv:2602.11988](https://arxiv.org/abs/2602.11988)) tested coding agents with
no context file, an LLM-generated one, and a developer-committed one, across
SWE-bench tasks and a fresh set of real repository issues. Four findings that
should change how you write these files:

- Context files **do not generally improve task success rates**
- They **increase inference cost by over 20% on average**
- **Instructions in the files are well followed** by the agents
- **Repository overviews — popular and recommended by model providers — are not
  helpful**

The operational reading: write instructions, not overviews. Every line is a
lever the agent will pull, so completeness is not the goal and is not free. A
companion January 2026 study ([arXiv:2601.20404](https://arxiv.org/abs/2601.20404))
measured the same artifact's effect on runtime and token consumption across 10
repositories and 124 pull requests.

### Five forms of human control

An organization does not have meaningful oversight merely because someone can
disable the agent. Meaningful control starts earlier:

| # | Control | The question |
|---|---|---|
| 01 | **Observe** | Can a person understand what the agent is doing? |
| 02 | **Interrupt** | Can an active workflow be stopped? |
| 03 | **Approve** | Which consequential actions pause before execution? |
| 04 | **Override** | Can a human replace or correct the agent's decision? |
| 05 | **Disable** | Can the entire agent be taken out of operation? |

### Four production rules

Deliberately simple. Use them as gates, not aspirations.

> **No owner → no production.**
> **No mandate → no autonomy.**
> **No visibility → no trust.**
> **No shutdown procedure → no deployment.**

The goal is not to slow adoption. It is to make successful deployments easier to
own, hand over, and scale.

---

## Is the workflow even ready?

Before designing an agent, check whether the work can be delegated at all. Three
layers, four checks each. **Any layer where you cannot answer three of four is
where the pilot will stall.**

**Layer 01 · Data shape**
- Can an agent retrieve every input this workflow needs without a human
  forwarding something?
- Are exceptions and edge cases written down anywhere other than in an
  experienced person's memory?
- Do the systems expose an API, or does the work depend on someone clicking
  through a portal?
- Is there a single authoritative version of the record the work updates?

**Layer 02 · Process design**
- Can you list the steps in order, as the workflow actually runs rather than as
  the process doc claims?
- For each step, can you say whether it should be read, drafted, decided, or
  executed by an agent?
- Do you know which steps carry judgment that must stay human, and why?
- Is there a defined outcome that counts as success, and a defined state that
  counts as a dead end?

**Layer 03 · Trust and permissions**
- Does the agent have its own identity, or would it act under a person's login?
- Can you state permitted actions individually, rather than as an autonomy
  level?
- Is there an approval point before every consequential action, with a named
  human behind it?
- If someone asked in twelve months what the agent did and why, could you
  reconstruct it from the log?

**The ceiling rule:** operability equals the **minimum** across the three
layers, not the average. A capable agent inside an inoperable workflow is still
an inoperable system.

**Reading the result.** Ten or more: strong candidate, the work is mostly
sequencing. Six to nine: the common case, gaps are known and fixable. Five or
fewer: valuable to know now rather than two quarters into a pilot.

---

## The artifacts an agent estate needs

In a two-person team, one person holds most of this in their head. In an
organization running forty agents across six functions, it has to be written
down, automated, and connected.

| Artifact | Answers |
|---|---|
| Agent architecture diagram | How the system is put together |
| Agent decision record | Why it was designed this way |
| Agent stack | What technologies it uses |
| Agent inventory | What we have, and where |
| Agent radar | Where our practice is heading |
| ABOM (agent bill of materials) | What is inside this agent's behavior |
| Evaluation suite | How well it behaves, and how it fails |
| Agent bundle and registry | Exactly what was released |
| Agent manifest | What it is allowed to do, and who it answers to |
| Autonomy map | Autonomous, confirmed, blocked — in plain language |
| Gateway policy | What is actually enforced, not just intended |
| Behavior changelog | What changed in the agent's character |
| Transcripts and traces | What happened, step by step |
| Action receipts | What changed in the world, on whose authority |
| Agent catalog | What exists and who owns it |
| Agent CMDB | What connects to what |
| Service levels and trust budget | How good it must be, and what freedom it has earned |
| Runbooks and playbooks | What we do when it goes wrong |
| Postmortems | What the incident taught the system |
| Risk register | How this estate could cause harm |
| Behavioral debt register | What shortcuts we are still paying for |
| Portfolio review | What to invest in, standardize, or retire |

Do not build all twenty-two for agent one. The order that matters for a first
agent: **agent manifest → autonomy map → gateway policy → action receipts →
evaluation suite.** Those five are the minimum that makes an agent defensible.
The rest become necessary as the estate grows, and the aggregate artifacts
(inventory, CMDB, portfolio review) are cheap to start at agent one and
expensive to reconstruct at agent nine.

---

## Anti-patterns

Specific, observable failure modes. If you see one, name it.

**The autonomy score.** "This agent is 70% autonomous" or "semi-autonomous."
It cannot be implemented, cannot be audited, and hides the one action that
matters. Replace with an action-by-action mandate.

**Prompt as policy.** The boundary exists in the system prompt. It survives
until the first injection, the first model upgrade, or the first user who asks
nicely. Move it into a mechanism.

**The orphan agent.** Owned by a project rather than a person. Orphaned the day
the project closes. Name a human in the business function the agent serves, not
the team that built it — build teams change.

**The shared login.** The agent acts as a service account or, worse, as a named
employee. Every downstream log is now wrong about who did what, and nothing can
be attributed.

**Kill switch as the whole safety story.** Untested, and the only control below
it is nothing. If the first response to surprise is "turn it off," the design
skipped observe, interrupt, approve, and override.

**Happy-path documentation.** Complete specification of what happens when
everything works and silence on the nine exceptions.

**Averaging the heat.** Scoring an action's five dimensions and taking the mean.
The reason the hottest-dimension rule is stated first.

**The pilot that never had to graduate.** Runs in production, has real users,
and was never held to the twenty-four questions because it is still called a
pilot. Status labels do not change consequence.

**Recommendation mistaken for control.** Covered above; the most common form of
self-deception in design reviews.

**Retry as the universal exception handler.** Turns a signal into a cost.

---

## Vocabulary

Precise definitions, because the loose versions cause the arguments.

- **Agent** — software with three properties: **memory** (recall across
  sessions), **initiative** (can propose and act, not just respond), and
  **judgment** (can choose between options under uncertainty). Subtract any one
  and you are building software, not an agent.
- **AUX (Agentic User Experience)** — the design layer. How humans and agents
  collaborate at the product surface. Classic UX designs for discrete tasks; AUX
  designs for relationships.
- **AX (Agent Experience)** — the API layer. How agents and software systems
  negotiate underneath the surface.
- **Heat** — the consequence of an action, scored on five dimensions.
- **Band** — the heat class of an action, which sets its control posture.
- **Mandate** — assigned authority, action by action. Distinct from technical
  capability.
- **Action receipt** — a per-action record of what changed in the world and on
  whose authority, readable by a non-engineer and available to the person
  affected.
- **Escalation handoff** — a documented route to a **named** human, carrying
  context across, with a time limit and a defined behavior if nobody answers.
- **Ownership debt** — the gap between an agent that works and an agent the
  organization can operate, hand over, change, and retire without the people who
  built it.
- **Agent operability** — the capacity of a specific **workflow** to be
  performed by an agent with bounded autonomy, usable context, explicit decision
  rights, and reconstructable accountability. A property of the workflow, not of
  the model or the enterprise.

---

## Two things this skill will not tell you

**It will not tell you an agent is safe.** It tells you whether the
organization can see, approve, and undo what the agent did. Those are different
claims, and the second is the only one a document can support.

**It will not give you a single score.** Capability and supervision are reported
separately and never combined, because the **gap between them is the finding**.
An agent that can do a great deal and can be supervised very little is the
specific thing worth knowing, and one number would hide it.

---

## Provenance

Assembled from published auxfirst material. Each source is the canonical, longer
treatment:

| Component | Source |
|---|---|
| Five dimensions, five bands, escalators | [The Action Heat Ladder](https://auxfirst.com/action-heat-ladder.html) |
| Six supervision primitives, the two scoring rules | [Agent Supervision Method](https://auxfirst.com/news/agent-supervision-method.html) · [the Register](https://auxfirst.com/news/agent-supervision-register.html) |
| Mandate, five controls, nine exceptions, four rules, ten questions, fifteen fields | [The Agent Owner's Manual](https://auxfirst.com/agent-owners-manual.html) |
| Context-file findings | [AGENTS.md for teams that don't write code](https://auxfirst.com/news/agents-md-for-non-engineering-teams.html), citing [arXiv:2602.11988](https://arxiv.org/abs/2602.11988) and [arXiv:2601.20404](https://arxiv.org/abs/2601.20404) |
| Ten heuristics | [The 10 AUX Heuristics](https://auxfirst.com/heuristics.md) |
| Six patterns, the autonomy-to-pattern mapping | [The Six AUX Patterns](https://auxfirst.com/patterns.md) |
| Twenty-four questions, twenty-two artifacts | [The Agent Development Lifecycle](https://auxfirst.com/agent-development-lifecycle.html) |
| Three layers, twelve-point readiness check | [Agent Operability](https://auxfirst.com/agent-operability-audit.html) · field guide at [agentoperability.com](https://agentoperability.com/) |
| Agent definition, AUX/AX stack | [The AUX Manifesto](https://auxfirst.com/manifesto.md) |

**What is new here and not on any single source page:** the join between heat
band and autonomy mode (step 4), the band thresholds for the six supervision
primitives (step 5), the "Enforced by" column in the mandate template, and the
first-five ordering of the artifact list.

Definitions are CC BY 4.0 — reuse them, adapt them, keep the attribution.

**Packaged as a Claude skill:**
[github.com/auxfirst/auxfirst-skill-global](https://github.com/auxfirst/auxfirst-skill-global)
· [auxfirst.com/auxfirst-skill.html](https://auxfirst.com/auxfirst-skill.html)

---

*auxfirst designs relationships between users and agents. The agent is a user.
The relationship is the product. Trust is the moat.*