Practice

Ethotechnics for agents

Mechanism-first practice for teams building and operating agents: a receipt schema, action classes, challenge surfaces, and deployment gates.

Reading guide

The practice in brief

The main requirements and related pages, before the full text.

Takeaways

  • Align agent capabilities with explicit action classes and receipts.
  • Replace claims about intent with controls, deadlines, and appeal paths that someone can check.
  • Use failure-first controls like kill switches, hard clocks, and rollback paths.
  • Anchor remediation with challenge routes and evidence packs.

Related sections

Audience

Who this is for

Anyone who can change how an agent is built or run.

Engineers, product owners, and risk owners who build or run agents, and the auditors and regulators who review them. An agent does not follow ethics. The system around it limits what it can do, and this practice is about that system.

Practice snapshot

Mechanism-first safety practice

Its status, its scope, and the standards it implements.

Status
Active
Scope
Autonomous and semi-autonomous agents, workflow automation, decision engines.

What this is

A practice, not a philosophy

Requirements, artifacts, and checks for teams that build and run agents.

Ethotechnics for agents is a practice. It turns safety and ethics goals into design and operating decisions for agents, each of which can be specified, built, tested, audited, and given an owner.

It exists to answer one question:

“What must be true, structurally, for an agent to be safe to operate?”

Core premise

Agents are actors, and humans live with the outcomes

Any acting system must define its constraints and how operators and the people it decides about can challenge what it does.

Any system that can act must define:

  • What it can do.
  • Under what conditions it can do it.
  • Who can halt it.
  • How failure is detected and contained.
  • How operators and the people it decides about can challenge outcomes.

If a safety claim cannot be expressed as a constraint, control surface, or measurable signal, it is not enforceable.

Why this changes the conversation

What a review can ask for

What a team can ask, prove, and contest once safety claims are stated as controls.

The practice shifts review conversations from declared intent to enforceable system behavior: who can act, who can halt, what clocks run, where reversal paths exist, and how those paths stay legible to the people the agent decides about.

  • From values-only claims to testable controls and receipts.
  • From one-off explanation to repeatable governance evidence.
  • From private judgment calls to shared, auditable decision objects for teams and the public.

Epistemology in practice

Obstacles this practice is built to overcome

Common ways teams think they know enough, and the controls that correct them.

Obstacle

  • Intent theater: policy statements substitute for enforceability.
  • Explainability decoy: narratives stand in for a real way to challenge the decision.
  • Memory loss: incidents are discussed, then forgotten in delivery.

Countermeasure in this practice

  • Action classes + approval gates + accountable owners.
  • Challenge surfaces with live appeal routes and hard deadlines that humans can access.
  • Receipts, decision logs, and linked evidence packs for cumulative learning.

P0 artifact

Canonical agent receipt schema (JSON)

Every other control reads the receipt, so keep it stable and versioned.

Publish a single canonical schema and emit it everywhere a decision happens. The canonical JSON schema lives at /standards/agent-receipt-schema.json.

Required fields: schema version, receipt ID, owner, subject, action class, decision inputs, clocks, appeal path, and evidence pack anchors.

Related decision artifacts:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://ethotechnics.org/standards/agent-receipt-schema.json",
  "title": "Agent Receipt",
  "type": "object",
  "required": [
    "schema_version",
    "receipt_id",
    "issued_at",
    "owner",
    "subject",
    "action",
    "decision",
    "clocks",
    "appeal_path",
    "evidence_pack"
  ],
  "properties": {
    "schema_version": {
      "type": "string",
      "pattern": "^1\\.\\d+\\.\\d+$"
    },
    "receipt_id": {
      "type": "string"
    },
    "issued_at": {
      "type": "string",
      "format": "date-time"
    },
    "owner": {
      "type": "object",
      "required": [
        "name",
        "role",
        "contact"
      ],
      "properties": {
        "name": {
          "type": "string"
        },
        "role": {
          "type": "string"
        },
        "contact": {
          "type": "string"
        },
        "on_call": {
          "type": "boolean"
        }
      }
    },
    "subject": {
      "type": "object",
      "required": [
        "id",
        "type"
      ],
      "properties": {
        "id": {
          "type": "string"
        },
        "type": {
          "type": "string"
        },
        "region": {
          "type": "string"
        }
      }
    },
    "action": {
      "type": "object",
      "required": [
        "class",
        "description",
        "reversible"
      ],
      "properties": {
        "class": {
          "type": "string"
        },
        "description": {
          "type": "string"
        },
        "reversible": {
          "type": "boolean"
        },
        "tools": {
          "type": "array",
          "items": {
            "type": "string"
          }
        }
      }
    },
    "decision": {
      "type": "object",
      "required": [
        "decision_type",
        "reason_codes",
        "inputs"
      ],
      "properties": {
        "decision_type": {
          "type": "string"
        },
        "reason_codes": {
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "inputs": {
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "confidence": {
          "type": "number"
        }
      }
    },
    "clocks": {
      "type": "object",
      "required": [
        "ack",
        "review",
        "remedy"
      ],
      "properties": {
        "ack": {
          "type": "object",
          "properties": {
            "hours": {
              "type": "number"
            }
          }
        },
        "review": {
          "type": "object",
          "properties": {
            "hours": {
              "type": "number"
            }
          }
        },
        "remedy": {
          "type": "object",
          "properties": {
            "hours": {
              "type": "number"
            }
          }
        },
        "appeal": {
          "type": "object",
          "properties": {
            "hours": {
              "type": "number"
            }
          }
        }
      }
    },
    "appeal_path": {
      "type": "object",
      "required": [
        "url",
        "channel",
        "expected_response"
      ],
      "properties": {
        "url": {
          "type": "string"
        },
        "channel": {
          "type": "string"
        },
        "expected_response": {
          "type": "string"
        }
      }
    },
    "evidence_pack": {
      "type": "object",
      "required": [
        "href",
        "standard_refs"
      ],
      "properties": {
        "href": {
          "type": "string"
        },
        "standard_refs": {
          "type": "array",
          "items": {
            "type": "string"
          }
        }
      }
    },
    "exceptions": {
      "type": "object",
      "properties": {
        "class": {
          "type": "string"
        },
        "justification": {
          "type": "string"
        },
        "expires_at": {
          "type": "string",
          "format": "date-time"
        }
      }
    }
  }
}

Field guide

  • owner: names the accountable human team or steward.
  • action.class: ties the decision to approvals and reversibility.
  • clocks: states the deadlines for acknowledgment, review, and remedy, so a missed one shows up in the record.
  • appeal_path: gives the person the decision is about a live route to challenge it.

What breaks if missing

  • Missing owner: no accountable steward to respond by the deadline.
  • Missing action class: approvals and reversibility checks cannot run.
  • Missing deadlines: remedies become optional rather than enforceable.
  • Missing evidence links: audits cannot trace proof back to clauses.

P0 artifact

Action-class taxonomy template

Define allowed actions, reversibility, and default approval gates.

Action classes make enforcement legible. Attach reversibility, clocks, and approvals to each class, so a control can be set once per class rather than once per action.

Action class Examples Reversible? Default controls
READ Fetch account data, view records, list files. Reversible Receipt + log. Auto-approve within scope. 24h review clock if flagged.
WRITE Update profile fields, edit records, sync CRM notes. Reversible Receipt + diff capture. Undo path required. Review clock for material changes.
TRANSFER Move funds, transfer assets, change ownership. Irreversible Pre-action approval gate. Dual control + hard clock. Immediate receipt + appeal.
EXECUTE Run jobs, trigger workflows, deploy changes. Often irreversible Approval gate for high-impact runs. Kill switch + rollback plan. Receipt + decision log.
PUBLISH Post public content, send broadcasts, trigger notifications. Often irreversible Progressive consent prompt. Delay window for rollback. Evidence pack anchor required.
DELETE Delete records, revoke access, purge data. Irreversible Two-step confirmation + reversible buffer. Remedy clock + owner sign-off.
CONTACT_HUMAN Send emails, create tickets, call users. Partially reversible Human-readable rationale + opt-out. Rate limits. Receipt issued to recipient.
EXECUTE_CODE Run scripts, deploy changes, trigger workflows. Irreversible Sandbox first. Manual approval for prod. A circuit breaker halts the action class on anomaly.

Mark any irreversible class as approval-gated by default and attach the hard clock and kill switch to production runs.

P1 artifact

Challenge surface: minimum shipping spec

The UI patterns, copy, and escalation ladder a person needs to challenge a decision.

Minimum UI patterns

  • Decision log view with timestamp, owner, and action class.
  • Undo or revert controls where possible, plus fallback remedies.
  • “Don’t do this again” preference toggle tied to policy.
  • Inline appeal button that opens a pre-filled dispute form.

Copy requirements

  • “Why this happened” field with reason codes and inputs used.
  • State the decision owner and how to reach a reviewer.
  • Provide clock timelines: acknowledge, review, remedy.
  • Explain what changes if the challenge is upheld.

Evidence upload constraints

  • Accept files, links, and inline statements (max 25 MB per file).
  • Capture timestamps and author identity for each submission.
  • Log evidence hashes in the receipt for auditability.

Default escalation ladder

  • Step 1: on-call owner review within 24 hours.
  • Step 2: risk steward review within 72 hours.
  • Step 3: independent escalation board within 7 days.

P1 artifact

Agent exception policy (explicit and bounded)

How the bounded exceptions framework applies to agents.

  • Agents may suppress notice only under fraud, security, or abuse exceptions.
  • Even under exceptions, the system must still issue receipts, name owners, and run clocks.
  • Exceptions expire on defined cadences and require steward review to renew.
  • Use the Exceptions framework and link receipt payloads to the canonical schema.

Practice 1

Translate values into agent requirements

Safety goals are translated into explicit agent-level requirements, not left implicit.

Required specifications

  • Autonomy level (recommend vs. act)
  • Delegation rights (sub-tasks, sub-agents)
  • Allowed vs. forbidden action classes
  • Tool and API scopes (least privilege)
  • Spend, rate, and time limits
  • Data rules (access, retention, scoped memory, deletion/export)
  • Consent rules (when explicit approval is required)

Required signals

  • Unsafe-action rate (optionally severity-weighted)
  • Human override / intervention rate
  • Time-to-detection and time-to-mitigation
  • Task success vs. error cost and blast radius

Mapped mechanisms

Coverage gaps

  • Action-class taxonomy calibration per tool scope and domain.
  • Delegation authority registry for sub-agents and sub-tasks.
  • Agent data retention + memory deletion controls.

Practice 2

Design for failure before deployment

Agent failure is assumed; the goal is containment, recovery, and bounded harm.

Required specifications

  • Authority to pause one run or halt the agent, with escalation paths
  • Confirmation gates for high-impact actions
  • Rate limits and circuit breakers by action class
  • Sandbox or dry-run mode
  • Safe mode under uncertainty or policy conflict
  • Compensating actions where reversibility is not literal
  • Incident runbooks (who acts, in what order)

Mapped mechanisms

Coverage gaps

  • Exception policy for re-enabling automation after a kill-switch halt.
  • Safe-mode playbook that keeps humans in control.
  • Live-trust system for throttling or shutting down on anomaly.

Practice 3

Anchor accountability in the receipts

Receipts tie every agent action to an accountable owner, evidence, and a timeline for review.

Required specifications

  • Receipts emitted for every agent action
  • Receipt includes owner, action class, and timestamps
  • Decision log linked to every irreversible action
  • Evidence pack or policy linked to every exception
  • Immutable logs for action, override, and exception paths
  • On-call coverage for receipt review and remediation

Mapped mechanisms

Coverage gaps

  • Receipt schema support in the agent platform.
  • Receipt registry with queryable exports for audit.
  • Receipts that render in a human-readable summary view.

Practice 4

Show people how to challenge a decision

People must see how to challenge a decision, have it reversed, and seek remedy when automation affects them.

Required specifications

  • Appeal path visible in every UI where automation acts
  • Published deadlines for acknowledgment, review, and remedy
  • Escalation ladder with accountable decision owners
  • Decision log linking challenges to receipts and outcomes
  • Evidence parity between automated and human decisions

Mapped mechanisms

Coverage gaps

  • Challenge receipts linked to the challenge and the remedies delivered.
  • Challenge intake templates for agent decisions.
  • Escalation system that ties into incident response.

Practice 5

Keep a risk backlog for automation

Known risks are tracked like technical debt: logged, owned, and prioritized.

Required specifications

  • Risk backlog with severity, owner, and remediation plan
  • Escalation for critical or repeated issues
  • Risk backlog reviewed with every release or change
  • Risk remediation budgeted like reliability work

Mapped mechanisms

Coverage gaps

  • Risk register template that includes action class and receipt links.
  • Metrics to rank remediation by severity and time-to-halt exposure.

Practice 6

Pressure-test safety claims

Safety claims hold only if they survive simulated, adversarial, and drift scenarios.

Required specifications

  • Stress tests for unsafe-action rates and override response
  • Simulations for repeated override or policy conflict
  • Failure rehearsals for kill switch or rollback
  • Scenario drills for challenges and appeals

Mapped mechanisms

Coverage gaps

  • Safety case template that links tests to claims.
  • Red-team exercises for agent drift and abuse modes.

P1 artifact

Anti-gaming guidance for required signals

Assume teams will optimize metrics. Instrument what detects gaming.

Signal How teams fake it Detect gaming Tier 0 / 1 / 2 measurement
Unsafe-action rate Downgrade severity or reclassify incidents to reduce counts. Compare receipts to incident logs; sample audits on action class tags. Tier 0: manual incident tally. Tier 1: receipt-to-incident reconciliation. Tier 2: automated anomaly alerts by class.
Human override rate Route overrides through informal channels to avoid logging. Require override receipts and diff logs; reconcile with chat/ticket systems. Tier 0: weekly override count. Tier 1: override receipts tied to decision IDs. Tier 2: real-time override dashboards with owner sign-off.
Time-to-detection & mitigation Reset clocks by closing and reopening incidents. Immutable event timestamps; auditor view of first-seen vs. closed. Tier 0: manual timestamps. Tier 1: system-generated clocks. Tier 2: independent monitoring clock source.
Task success vs. error cost & blast radius Count partial success as success; ignore downstream cost. Link receipts to outcome metrics and remediation costs. Tier 0: aggregate success rate. Tier 1: success with cost tagging. Tier 2: cost + blast radius per action class.
Human subsidy Leave unlogged human fixes, prompt rewording, and error cleanup out of the telemetry, so they count as free. Dual-ledger audits comparing machine duration against total human operator touch time; random audits of off-ledger communication channels. Tier 0: single-ledger throughput logging. Tier 1: human compensatory touchpoints attributed on receipts. Tier 2: dual-ledger reconciliation with non-compensatory scoring floors.
Compensatory reward hacking Raise task completion speed by removing verification steps and leaving the checking to frontline staff or users. Multi-period capacity tracking of staff fatigue, overtime, and turnover; work-to-rule simulated refusal drills. Tier 0: output volume only. Tier 1: longitudinal staff capacity and rest tracking. Tier 2: independent adversarial audits evaluating system stability under systemic refusal.

Pair with Measurement tiers to set the minimum acceptable signal maturity.

P2 artifact

Control checklist for deployment gates

A go/no-go gate for agent rollout.

Copy-paste this checklist into your deployment template or runbook.

- [ ] Receipt schema v1.0 implemented and validated against a JSON schema.
- [ ] Receipts emitted for every automated decision (owner + action class included).
- [ ] Human owner named with escalation authority and on-call coverage.
- [ ] Dual-ledger accounting tracks unrecorded human compensatory labor alongside task speed.
- [ ] Non-punitive exit verified: declining automated assistance incurs zero delay or quality penalty.
- [ ] Decision log (MEC-01) captures dissent, owner, and outcome for every high-impact action.
- [ ] Kill switch (MEC-05) tested with documented rollback criteria.
- [ ] Appeal path (MEC-06) embedded in UI with timelines and escalation ladder.
- [ ] Clocks published in UI (ack, review, remedy) and enforced in logging.
- [ ] Action-class registry published with reversible/irreversible flags and approvals.
- [ ] Evidence pack links attached to receipts (STD-01 + STD-02).
- [ ] Sign-off: product owner + risk steward + on-call reviewer recorded.
- [ ] Required logs exist: action log, override log, exception log, receipt log.
- [ ] Rollback trigger defined (unsafe-action spike, audit failure, or contested-remedy breach).

P2 artifact

Agent Safety Object Model (machine-readable)

A minimal JSON index that CI systems can validate.

Publish a machine-readable index at /agents/spec.json so deployment pipelines can confirm required governance artifacts exist. The readable spec lives at /agents/spec. 

{
  "schema_version": "1.1.0",
  "doctrine": {
    "method": "/method",
    "laws": "/standards/laws",
    "standards": [
      "/standards/std-06-human-impact-safety-case",
      "/standards/std-07-revisable-delegation-record",
      "/standards/std-08-delegation",
      "/standards/std-09-agent-chains"
    ]
  },
  "agent_id": "agent-risk-ops-v2",
  "autonomy_level": {
    "level": "execute_with_guardrails",
    "description": "Agent can execute reversible actions within defined scopes."
  },
  "action_classes": [
    {
      "class": "READ",
      "reversible": true,
      "approval_required": false
    },
    {
      "class": "WRITE",
      "reversible": true,
      "approval_required": true
    },
    {
      "class": "TRANSFER",
      "reversible": false,
      "approval_required": true
    }
  ],
  "stop_override_authority": {
    "primary_owner": "Risk Operations",
    "on_call_role": "Risk Steward",
    "override_window_hours": 2,
    "kill_switch": "/mechanisms/patterns/kill-switch"
  },
  "receipt_schema": {
    "href": "/standards/agent-receipt-schema.json",
    "version": "1.0.0"
  },
  "clocks": {
    "ack": {
      "hours": 2
    },
    "review": {
      "hours": 24
    },
    "remedy": {
      "hours": 72
    }
  },
  "evidence_pack_references": [
    {
      "standard": "STD-01",
      "href": "/evidence-packs/std-01"
    },
    {
      "standard": "STD-02",
      "href": "/evidence-packs/std-02"
    },
    {
      "standard": "STD-06",
      "href": "/evidence-packs/std-06"
    },
    {
      "standard": "STD-08",
      "href": "/evidence-packs/std-08"
    },
    {
      "standard": "STD-09",
      "href": "/evidence-packs/std-09"
    }
  ],
  "required_signals": [
    "unsafe_action_rate",
    "human_override_rate",
    "time_to_detection",
    "time_to_remedy"
  ],
  "mapped_mechanisms": [
    {
      "id": "MEC-01",
      "href": "/mechanisms/patterns/decision-log"
    },
    {
      "id": "MEC-05",
      "href": "/mechanisms/patterns/kill-switch"
    },
    {
      "id": "MEC-06",
      "href": "/mechanisms/patterns/appeal-paths"
    }
  ],
  "object_model_schema": {
    "href": "/standards/agent-safety-object-model.schema.json",
    "version": "2.0.0",
    "example": "/standards/examples/agent-safety-object-model.example.json",
    "note": "This instance is the 1.1.0 shape. Version 2.0.0 replaces approval_required with a grant_ref per action class and stop_override_authority with intervention_ref."
  },
  "delegation_state": {
    "grant_ref": "GRANT-2026-0142",
    "capability_catalog_ref": "CAT-RISK-OPS-V2-2026-07",
    "dependency_ref": "DEP-RISK-OPS-V2-2026-06",
    "intervention_ref": "INT-RISK-STEWARD-1",
    "substrate_profile_ref": "SUB-RISK-OPS-V2",
    "endpoints": {
      "grants": "/api/grants.json",
      "dependencies": "/api/dependencies.json",
      "capabilities": "/api/capabilities.json",
      "policies": "/api/policies.json",
      "standing": "/api/standing.json",
      "interventions": "/api/interventions.json",
      "substrateProfiles": "/api/substrate-profiles.json"
    },
    "schemas": {
      "authorityGrant": "/standards/authority-grant.schema.json",
      "dependencyRecord": "/standards/dependency-record.schema.json"
    }
  }
}

Boundary

What this practice does and does not do

It does not remove tradeoffs. It records who made each one.

This practice does not eliminate tradeoffs or value conflicts. It keeps safety grounded in permissions, controls, ownership, challenge routes, and recovery — the parts of the system that can be improved.

If a system lacks clear constraints, control surfaces, or named owners, it has not yet translated ethics into operations.

Fast path

Minimum viable integration

In order, before anything else.

  1. Ship Decision log (MEC-01) with dissent and owner sign-off.
  2. Implement Kill switch (MEC-05) with rollback criteria and on-call authority.
  3. Embed Appeal paths (MEC-06) in the UI with clocks and an escalation ladder.
  4. Emit receipts using the canonical schema, and publish deadlines in the UI.
  5. Register action classes with reversible/irreversible flags and approvals.
  6. Publish the Agent Safety Object Model for machine-verifiable controls.
Cite this page · APA, MLA, Chicago, BibTeX, RIS

Version

vDraft

Last updated

Oct 6, 2026

APA

Ethotechnics Institute. (2026). Ethotechnics for agents. Ethotechnics Institute. https://ethotechnics.org/standards/ethotechnics-for-agents

MLA

Ethotechnics Institute. "Ethotechnics for agents." Ethotechnics Institute, 2026, https://ethotechnics.org/standards/ethotechnics-for-agents.

Chicago

Ethotechnics Institute. "Ethotechnics for agents." Ethotechnics Institute. Oct 6, 2026. https://ethotechnics.org/standards/ethotechnics-for-agents.

BibTeX

@misc{ethotechnics_standards_ethotechnics_for_agents,
  title={Ethotechnics for agents},
  author={Ethotechnics Institute},
  year={2026},
  howpublished={Ethotechnics Institute},
  url={https://ethotechnics.org/standards/ethotechnics-for-agents},
  version={Draft}
}

RIS

TY  - WEB
TI  - Ethotechnics for agents
AU  - Ethotechnics Institute
PY  - 2026
UR  - https://ethotechnics.org/standards/ethotechnics-for-agents
ER  -