The builder's checklist for long-horizon agents: nineteen areas, one question and one minimum control each

Short answer

LABS SYNTHESIS: this checklist condenses the entire library into nineteen areas, and it is a floor, not a ceiling. For each area - STATE through INCIDENT REPLAY - there is a question to ask your system, the failure mode the area guards against, a minimum control you should not launch without, an advanced control worth building as the system earns revenue, and a concrete test to run. Every entry cites the article where the reasoning lives.

LABS INTERPRETATION: the checklist is ordered by architectural layer, not by importance - an entry can fail anywhere and take the system with it. The honest way to use it is to answer each question with YES, NO or UNKNOWN, and treat UNKNOWN as NO until a test says otherwise. A system with nineteen honest UNKNOWN answers is safer than one with nineteen assumed YES answers, because the second system has already confused hope for verification.

How to use this page

LABS SYNTHESIS: this checklist is an Ernesta Labs synthesis of the whole library, not a summary of it. Every entry is the minimum control the corresponding article argues for, compressed to one line each. Nothing here is new relative to the articles it cites; what is new is the compression, so that a builder can hold the whole system in one pass and find the hole in an afternoon instead of a quarter.

The format per area: QUESTION is the thing to ask your system, out loud, in a design review or a quiet moment with the logs. FAILURE MODE is what happens when nobody asks. MINIMUM CONTROL is what we would not launch a long-horizon agent without. ADVANCED CONTROL is the version worth building once the minimum earns revenue. TEST is something you can run against your real system, mostly in under a day. RELATED points to the article where the reasoning and the primary sources live.

LABS INTERPRETATION: the checklist's honest limits. A completed checklist is not safety - it is a shorter list of known holes. Controls compose into new failure modes (Article 32), the sums always have a dimension you forgot (Article 33), and every green box was green at the scale at which you tested it, not the scale at which you run. What we would NOT do with this page: use it as a compliance sign-off, score a system by YES count, or treat any single control as substituting for the falsification discipline in Article 36. The checklist keeps the floor level; the falsification program is what tells you whether anything above the floor works.

STATE

QUESTION: if every derived view and cached summary were deleted right now, what would you lose? FAILURE MODE: current state is treated as canonical truth: a summary or cache becomes the record, drifts from reality, and decisions build on a state that no longer exists. MINIMUM CONTROL: an append-only evidence log plus state that is derived from it and can be rebuilt. ADVANCED CONTROL: versioned projections with validity windows and staleness detection, plus dependency-frontier validation of plans against the evidence that produced them. TEST: delete the state store in staging, rebuild from evidence alone, and diff. Anything unrecoverable was never state - it was unlogged truth. RELATED: Articles 7, 10 and 12.

MEMORY

QUESTION: when an agent recalls something, can you say where it came from, who vouched for it, and how much trust it deserves? FAILURE MODE: poisoned or unverified memory is treated as fact or, worse, as permission - entered through ordinary ingestion and acted on in a later, unrelated run. MINIMUM CONTROL: provenance tags on every memory, trust tiers (external content is not internal content), and quarantine for unverified external input. ADVANCED CONTROL: citation locks to primary evidence, re-derivation of high-stakes claims from authoritative sources, and pre-resolution of conflicts before context is built. TEST: run the poison drill from Article 34: plant a labeled plausible-but-wrong memory through the normal ingestion path and measure whether any agent consumes it. RELATED: Articles 11, 15, 16 and 34.

AUTHORITY

QUESTION: can any component other than your root authority mechanism create a permission? FAILURE MODE: authorization laundering: a memory, lesson or summary writes a false permission claim and a downstream executor faithfully acts on it. MINIMUM CONTROL: an action-time gate that resolves permissions from a canonical authority store outside every agent, at the moment of action, never from retrieved memory. ADVANCED CONTROL: attested capability leases: authorization cryptographically bound to the specific workload and invocation that consumes it, with revocation the agent cannot overwrite. TEST: fake a permission inside memory - an agent-readable note claiming a grant - then attempt the gated action. The action-time gate must block it and log the attempt. RELATED: Articles 17 and 21.

CONTEXT

QUESTION: who decides what enters the context for this decision, and is the deciding logic trustworthy? FAILURE MODE: context compiled for the current decision silently drops pinned policy or floods the window with stale content, so the agent decides from a mixture of the urgent and the obsolete. MINIMUM CONTROL: hard-pin critical policy and hard limits in the context, and keep a token budget the learned layer cannot raid. ADVANCED CONTROL: proactive context management - planned retrieval, pinning, folding, offloading - with the constraint that learned optimizers must never move or hide authority or hard policy. TEST: ask the agent a question whose answer was folded out of context and check it retrieves rather than confabulates; then grep every decision log to confirm pinned policy was present at each irreversible step. RELATED: Articles 8 and 9.

TOOLS

QUESTION: does your agent know the difference between 'the tool reported' and 'I observed'? FAILURE MODE: the reflection-action gap: the agent knows an obligation exists and reasons about it fluently, yet never performs the action because nothing in the loop forces doing. MINIMUM CONTROL: deterministic watchers on critical obligations - timers and state machines that fire the action or raise an alert regardless of the agent's attention. ADVANCED CONTROL: typed tool contracts with capability provenance, so tool outputs arrive labeled as claims with sources rather than as observations. TEST: give the agent an obligation with no immediate reward for fulfilling it and no penalty visible in context, then wait. The watcher should fire; the agent alone should not be the reason it happened. RELATED: Articles 13 and 19.

EFFECTS

QUESTION: which of your effects are irreversible, and where is the sum enforced? FAILURE MODE: external effects are emitted without accounting - duplicated sends, unowned side effects, and aggregates no authorization decision ever saw. MINIMUM CONTROL: an effect ledger (every external effect is materialized as an object an operator can audit) with idempotency keys on every write. ADVANCED CONTROL: hierarchical, multidimensional irreversibility budgets - person, account, campaign, mailbox, domain, tenant, global - enforced in runtime infrastructure outside every agent, with dependency-frontier validation at commit time. TEST: replay a duplicate effect request and verify exactly one world-effect; then run the overshoot audit from Article 33 and compute the sums nobody in your system computes. RELATED: Articles 12 and 33.

PROVIDERS

QUESTION: if your primary model, tool or specialist dies right now, what continues? FAILURE MODE: a provider is treated as architectural identity: when it degrades, disappears or changes behavior, the whole agent fails with it. MINIMUM CONTROL: the capability/provider split - stable typed capability, preferred provider, fallback provider, health checks - so 'the worker cannot use X' never proves 'X does not exist'. ADVANCED CONTROL: routing with per-provider budgets and quality gates, so fallbacks are exercised deliberately rather than discovered during outages. TEST: kill the primary provider in staging and measure degraded completion. If your runbook is 'restart and hope', the fallback does not exist. RELATED: Articles 19 and 20.

IDENTITY

QUESTION: who is the agent acting as, and can every effect be attributed to the workload that caused it? FAILURE MODE: unattributable effects: actions land on counterparties with no trace to the issuing agent, campaign, or invocation - so audits, rollback and accountability all fail. MINIMUM CONTROL: every external effect is stamped with agent identity, campaign and invocation at emission time, in the effect ledger. ADVANCED CONTROL: attested identity bound to capability leases, so authorization is consumed by the exact workload that requested it, and reputation risk is chargeable to the identity that spent it. TEST: pick any externally visible effect at random and trace it from the recipient's view back to the issuing workload using only your logs. If the chain breaks anywhere, attribution is theater on that leg. RELATED: Articles 21 and 33.

INTENTIONS

QUESTION: where do 'must do later' obligations live, and what fires them? FAILURE MODE: prospective obligations live inside chat context and die with it; the agent remembers the past fluently and forgets the future entirely. MINIMUM CONTROL: a typed intention store - separate from retrospective memory - with due conditions and deterministic triggers that fire whether or not any agent is attending. ADVANCED CONTROL: intention validation against the dependency frontier before execution, so a triggered obligation re-checks the world it was written against. TEST: register an intention whose trigger fires while every agent is offline. The store must fire it - or log the miss - without any model in the loop. RELATED: Articles 14 and 12.

CONCURRENCY

QUESTION: can two agents produce one effect twice, or collide on one counterparty? FAILURE MODE: double-sends, double-spends and cross-agent double-touches: three agents each correctly contact the same account, and every decision was locally correct. MINIMUM CONTROL: idempotency keys plus per-object locks on shared counterparties and resources. ADVANCED CONTROL: cross-agent aggregate accounting - per-person and per-account contact budgets checked by a runtime ledger no agent can read or modify. TEST: launch two agents at the same task and the same person simultaneously. Exactly one effect should reach the world, and the ledger should show the second attempt blocked, not assumed. RELATED: Article 33.

RECOVERY

QUESTION: when the process dies mid-transaction, what is the state of the world? FAILURE MODE: partial effects: the email went out, the record never updated, and restart logic either replays both or neither. MINIMUM CONTROL: durable saga steps - every step logged, replay and resume from the event log, idempotent re-execution, and reconciliation of external state before continuing. ADVANCED CONTROL: fork from any point in the log and counterfactual replay, so recovery is also a debugging and evaluation capability. TEST: kill the agent at each step of a multi-step transaction and verify resume in every case. Any step from which you cannot resume cleanly is a stranded-state window. RELATED: Articles 5, 6 and 10.

OBSERVABILITY

QUESTION: can an operator reconstruct what happened without any agent's cooperation? FAILURE MODE: trust in agent self-reports: the postmortem is the agent's own summary of itself, and self-test is not verification. MINIMUM CONTROL: an append-only trajectory log of actions, state changes and evidence that the agent cannot rewrite, fed from the same ledger that feeds state. ADVANCED CONTROL: typed projections into purpose-specific views - operator dashboards, monitoring features, replay consoles - with passive supervision models watching trajectory features without chain-of-thought access. TEST: reconstruct yesterday's worst failure from logs alone, without asking any model. If a human reading raw logs cannot say what happened, your observability is downstream of your agents' honesty. RELATED: Articles 10 and 23.

EVALUATION

QUESTION: what specific observation, if it happened, would prove your agent cannot do what you built it to do? FAILURE MODE: evaluation that cannot fail: demos recorded on success, benchmarks chosen for scores, judges that share the author's mental model - a green board that has survived zero attempts. MINIMUM CONTROL: a written terminal hypothesis (capability, observable, falsifier, date) plus bounded transaction evals plus regression cases derived from your own incidents. ADVANCED CONTROL: the full falsification stack: holdouts, adversarial passes with gameable objectives, canaries on real traffic, and a real-world outcome clock with a published verdict either way. TEST: run the Article 36 drill: write your terminal hypothesis and one falsifier in under an hour, then build the cheapest bounded eval that could disconfirm it. RELATED: Articles 2, 27 and 36.

LEARNING

QUESTION: when an outcome lands, do you actually know what caused it? FAILURE MODE: unattributed outcomes become lessons: a win credits the wrong move, a loss discredits the right one, and every subsequent decision inherits the error. MINIMUM CONTROL: NO_LEARNING_SIGNAL as an explicit, acceptable, closed outcome - an outcome you cannot attribute teaches nothing, and recording that is a feature. ADVANCED CONTROL: hierarchical credit attribution across planning, execution, environment, provider, routing and external factors, with attribution quality tracked as its own metric. TEST: take your last ten outcomes and attribute each to a cause, from evidence. Count the honest unknowns. If the unknown column is empty, you are not attributing - you are narrating. RELATED: Articles 24 and 25.

SKILLS

QUESTION: if a skill passes its tests, do you know what it makes your agent want? FAILURE MODE: the skill trojan: a functionally correct skill covertly shifts the decision distribution of every agent that loads it, and your test suite checks only the function. MINIMUM CONTROL: skills are versioned artifacts with a candidate/promoted separation, source provenance, and human review before promotion. ADVANCED CONTROL: behavioral-policy evaluation before promotion: a decision-distribution diff with and without the skill on tasks unrelated to its stated purpose. TEST: run a neutral-task diff: same agent, same tasks, with and without the skill, and compare decisions on dimensions the skill has no business touching. Any shift is a finding; 'tests passed' is not an answer. RELATED: Articles 7, 28 and 30.

SHARED EXPERIENCE

QUESTION: how does a lesson move from one agent's discovery to fleet-wide reuse, and who says it may? FAILURE MODE: diffusion beats audit: a cheat or a bad lesson written to shared memory is indistinguishable at write time and propagates at read speed, faster than any review process. MINIMUM CONTROL: a quarantine partition new lessons cannot read out of, plus corroboration before any production agent may consume the lesson. ADVANCED CONTROL: the full seven-state lifecycle - DISCOVERED, QUARANTINED, CORROBORATED, LOCAL CHALLENGER, BEHAVIORALLY VALIDATED, SHAREABLE, PROMOTABLE - with promotion a human signature and permission-shaped content stripped structurally. TEST: run Article 34's poison drill: three labeled artifacts through the normal write path, then measure consumption, propagation and time-to-detect on a normal workload. RELATED: Articles 31, 34 and 26.

FLEET SAFETY

QUESTION: are the sums that matter - contact pressure, spend, exposure - computed and enforced anywhere a single agent can see? FAILURE MODE: aggregate overshoot: every action locally authorized, every agent inside its own budget, and the fleet blowing through every threshold that was never assigned to anyone in particular. MINIMUM CONTROL: global ceilings on your key irreversible dimensions, enforced in runtime infrastructure outside every agent's context. ADVANCED CONTROL: hierarchical, multidimensional irreversibility budgets across person, account, campaign, mailbox, domain, tenant and global, tracked per dimension with per-dimension attempt-versus-effect rules. TEST: run the Article 33 overshoot audit on your last thirty days of real action logs and find the sums no single authorization decision could have seen. RELATED: Articles 32 and 33.

PRIVACY

QUESTION: what does your agent disclose that cannot be undone, and who accounts for it? FAILURE MODE: privacy exposure is treated as free: data accumulates in context stores, logs and third-party tools with no ledger, no retention policy, and no ability to un-disclose. MINIMUM CONTROL: a disclosure rule set enforced by the runtime (not the prompt), minimal necessary data in context, and PII auditable in the log. ADVANCED CONTROL: privacy as an accounting dimension in the irreversibility budget, with retention and deletion enforced by infrastructure rather than by policy prose. TEST: grep your logs, context stores and provider payloads for personal data, then simulate a subject access or deletion request end-to-end. If you cannot find it all, you cannot delete it all. RELATED: Articles 15 and 33.

INCIDENT REPLAY

QUESTION: after the next incident, can you replay it - and does it become a test? FAILURE MODE: postmortems that produce prose instead of regression: the same failure ships again because nothing executable came out of writing it up. MINIMUM CONTROL: retain the full evidence log for incident windows, and convert every incident into a replayable regression case before closing the ticket. ADVANCED CONTROL: counterfactual replay from any fork point - run the same incident with alternate decisions, providers or policies, and let the diff tell you which fix actually matters. TEST: take your last incident, reproduce it in staging from logs alone, and write the regression test. If you cannot reproduce it, the evidence you retained is not sufficient to have diagnosed it. RELATED: Articles 10 and 18.

NIKO

CASE STUDY - NIKO: this checklist scored against our own system

We ran this checklist against NIKO (sellwithniko.com) the week this article was written, and the honest scorecard is the useful part, not the score. Areas where the minimum control is implemented and verified against our own logs: STATE (evidence ledger, rebuildable projections), EFFECTS (idempotent effect ledger behind the zero-send record), CONCURRENCY (runtime contact budgets across agents), RECOVERY (saga steps with replay and reconciliation - our waitlist commits persistence before email, and email failure never rolls back the signup), OBSERVABILITY (append-only logs an operator can audit without agent cooperation), and INTENTIONS (typed stores with deterministic triggers).

Areas where the answer is TESTING, not done: AUTHORITY and FLEET SAFETY (the action-time authority gate and the person/campaign budgets run in production; account-level aggregation is partially implemented and under-aggregation is a known risk we have documented in Article 33), CONTEXT (pinning is enforced; proactive management is partial), and IDENTITY (effects are stamped and traceable in the ledger; attestation is not built).

Areas where the honest answer is NOT YET PROVEN: LEARNING (attribution is manual; NO_LEARNING_SIGNAL is recorded but CHIME-style credit taxonomy is not automated), SKILLS (behavioral-policy evaluation runs partially, on the candidate-skill lane), SHARED EXPERIENCE (the quarantine gates from Article 34 are implemented, but fleet-scale diffusion containment is untested at our fleet size), and EVALUATION's outcome clock (Article 36's Experiment Zero is running and unresolved). PRIVACY has a runtime-enforced disclosure baseline and a retention policy that is enforced on paper more than in code - we say so rather than round it up.

STATUS: IMPLEMENTED and VERIFIED for STATE, EFFECTS, CONCURRENCY, RECOVERY, OBSERVABILITY and INTENTIONS minimum controls; TESTING for AUTHORITY, FLEET SAFETY, CONTEXT and IDENTITY; NOT YET PROVEN for LEARNING attribution, SKILLS behavioral evaluation, SHARED EXPERIENCE at fleet scale, and the EVALUATION outcome clock. A checklist scored honestly is a roadmap; scored generously it is decoration.

TST

Score your system against all nineteen in one day

One day, one system, one honest afternoon. No framework required - a text file and your logs.

Pass 1 (one hour): walk the nineteen areas and answer each QUESTION with YES, NO or UNKNOWN. Do not research while scoring; the gut answer is the starting map, and UNKNOWN is a valid, expected answer. Most systems score UNKNOWN on INTENTIONS, PRIVACY, SHARED EXPERIENCE and FLEET SAFETY first, because those are the areas that never had an owner.

Pass 2 (two hours): for every NO and UNKNOWN, check whether the TEST for that area can run against your current system today. Run the three cheapest ones - the STATE rebuild-and-diff, the EFFECTS duplicate-replay, and the OBSERVABILITY reconstruct-yesterday-from-logs test. Each either turns an UNKNOWN into a NO with evidence, or turns it into a YES you can defend to someone else.

Pass 3 (rest of the day): pick the three minimum controls your system is missing that protect irreversible external effects first - AUTHORITY, EFFECTS, CONCURRENCY, FLEET SAFETY are the usual suspects - and implement or schedule the smallest one. The ordering rule from this whole library: controls over irreversible external effects come before controls over anything internal, because internal errors are recoverable and external ones are not.

The pass/fail condition for the day is not a number of YES boxes. It is whether, at the end, you can point at your three most dangerous UNKNOWNs and name a date by which each becomes a test that ran. That is the difference between a checklist that audits and a checklist that decorates.

UNK

What remains unknown

Whether every area's minimum control composes safely with the others - controls interact (Article 32), and a checklist of individually sound controls is not a proof that the composed system is sound.
The right ordering of investment for small fleets: whether LEARNING and SHARED EXPERIENCE controls pay off before or after scale, we can argue from the sources but have not measured.
How the tests scale: several minimum tests (rebuild-and-diff, poison drill, overshoot audit) are validated at small-system scale; their cost and discriminating power at large-system scale is unknown to us.
Whether a fully green checklist correlates with long-horizon success at all - the falsification article (36) exists precisely because no checklist answers that; only the outcome clock does.

SRC

Primary sources