The Last Seat: Designing a Reviewable AI Engineering Workflow

How to connect business intent, human decisions, bounded agent work, and operational evidence without mistaking instructions for controls.

The last seat exposes what the toolchain cannot decide

Imagine a hypothetical registration service for a 30-seat workshop. Twenty-nine registrations are confirmed when two valid requests arrive at almost the same time. The desired result sounds obvious: one person gets the final seat; the other joins a first-in, first-out waitlist.

But “first” according to which moment: when a request reaches the edge, when it passes validation, or when it commits? What identifies a duplicate submission? If a cancellation opens a place, can a retried message promote two people? And if the seat is allocated but the confirmation email fails, is the person registered, notified, both, or neither?

A coding agent can produce a plausible endpoint before the team answers any of those questions. It can also generate tests that agree with its own implementation. A green build may then prove internal consistency while leaving the business rule unresolved.

That is the gap between an AI toolchain and an engineering workflow. Standards files, specialist agents, reusable skills, and multiple coding tools are useful building blocks. They become reviewable only when they remain connected to domain intent, human-owned decisions, bounded actions, and evidence of the resulting behavior.

The research starts from the workshop’s three original pillars—Standards as Code, an Agent Ecosystem, and Multi-Tool Collaboration—but its most useful extension is to put Domain, Decision & Context Engineering beneath them.

The practical thesis is simple: do not ask only, “What did the agent generate?” Ask, “Which accepted decision authorized this change, what was the agent allowed to do, and what evidence would let another person judge the outcome?”

Standards as Code is guidance, not control

Repository instruction files can reduce repeated explanation and make expectations visible. Reusable skills can package a procedure with supporting scripts and references. Both matter but their names make them sound more authoritative than they are.

Anthropic documents project instructions as context and notes that adherence can vary; their presence is therefore not, by itself, an enforcement boundary. It recommends a CLAUDE.md import such as @AGENTS.md when a repository already uses AGENTS.md; imported text still enters the context window at launch. Its “under 200 lines” advice is a writing target, not a loader cutoff or a security guarantee.

The Agent Skills specification similarly standardizes a package: lightweight metadata is available for discovery, the full SKILL.md loads on activation, and other resources are pulled in as needed. That shared format does not guarantee that every client discovers the same folders, interprets optional fields identically, or applies the same permissions and sandboxing.

For consequential work, separate five layers that are often collapsed into one:

1. the written expectation;
2. the effective tool and permission policy;
3. filesystem and network containment;
4. deterministic checks that reject a bad result; and
5. a human-controlled approval record.

A role named “security reviewer” may still possess write or execution tools. In Claude Code, a skill’s allowed-tools field preapproves listed tools; it is not the restrictive allowlist used for a subagent. The relevant question is not what the file is called, but what the resolved runtime can actually do. Anthropic’s subagent documentation distinguishes a worker’s own context from the allowlists and denylists that narrow its effective tool set.

There is also a supply chain behind each capability. In a historical snapshot of 3,984 ClawHub skills taken on 3 February 2026, Snyk manually confirmed 76 malicious skill identities; automated scanning flagged 534 skills, or 13.4%, with at least one Critical-severity issue. Its skills.sh analysis used a separate top-100 sample, so those categories and samples are not interchangeable. Together, they make the review question concrete: which exact version, scripts, remote fetches, permissions, data paths, and removal procedure are being approved?

Put domain meaning and human decisions underneath the tools

Before choosing a framework, database, or deployment topology, clarify the behavior the system must preserve. Event Modeling is useful here because it connects commands, events, views, and examples along an information timeline. Its own method description leaves room for different implementation mechanisms; drawing events does not force event sourcing, queues, or microservices.

For the last-seat scenario, start with an invariant: confirmed registrations must never exceed capacity. Then separate the concepts that a hurried implementation might merge. Allocation of a seat is not delivery of a notification. The Registration context may need identity and contact data; Catering may need only an aggregate confirmed count.

“Submitted,” “validated,” “confirmed,” “waitlisted,” and “notified” should not become synonyms just because one API response contains them.

Once the team understands the decision it actually faces, an Architecture Decision Record or ADR preserves the reasoning. Michael Nygard’s original format is intentionally small: title, status, context, decision, and consequences. It keeps superseded choices instead of erasing the path that led to the current system.

The workshop research proposes a stronger gate around that familiar format: a decision can remain UNRESOLVED; only a human changes it to accepted; and only then may a compiler stage the related rules, skills, tests, or configuration for review. This is a governance design, not an established vendor feature or a completed implementation.

It also has a cost. Human acceptance, capability review, and provenance tracking add latency, so the ceremony should follow risk. A trivial, reversible edit does not need the same gate as a consistency model, a new data boundary, or a capability that can execute code.

Context and delegation must earn their place

Useful context is not synonymous with maximum context. Keep the current invariant, applicable decisions, task state, and stable source locators close to the work; retrieve supporting detail when it becomes relevant. This guards against three different failures: irrelevant material competing for attention, stale persistent instructions, and information lost at a handoff or compaction boundary. Shorter is not automatically fresher, and larger is not automatically more complete.

The empirical record is deliberately uncomfortable. Vercel reported pass rates of 53% for its baseline, 79% when prompts explicitly instructed the agent to invoke a skill, and 100% with an always-present documentation index in a Next.js 16 evaluation. It also replaced roughly 40 KB of injected documentation with an 8 KB index while retaining version-matched documentation for retrieval. The published account does not expose the sample size, exact model version, confidence intervals, or an independent replication, so it supports a task-specific design not a universal filename rule.

An independent 2026 preprint tested four agent/model configurations on 300 SWE-bench Lite tasks and 138 CTXbench instances. It found no statistically significant success-rate improvement from context files in those settings and reported higher inference cost. Its Python-heavy scope and benchmark design limit generalization in the opposite direction too.

The defensible conclusion is not “always load” or “never load.” Compare context variants including a no-extra-guidance baseline against the outcome you care about. An instruction can improve navigation without improving correctness; a smaller prompt can reduce cost without preserving the decision state needed for recovery.

Delegation deserves the same discipline. A useful agent contract names the input revision, exact question, read/write scope, tools, evidence requirements, return artifact, stop condition, and escalation owner. The work should be partitionable and independently checkable. Tightly sequential edits over shared mutable state may create more coordination than insight.

That caution is consistent with a controlled study of 260 configurations across six benchmarks: multi-agent effects varied with the task, coordination architecture, model capability, and overhead. More agents were not monotonically better.

Nor does a second provider automatically create independent corroboration. Independence comes from separately formed interpretations, controlled access, shared acceptance tests, and evidence that can be inspected—not from two fluent summaries agreeing.

The workshop adopts one specific collaboration pattern: Claude-first authoring followed by a final, read-only Codex mirror. That is intended to reduce one kind of configuration drift and create a separate review lane, but it is a local governance choice, not a proven universal optimum.

OpenAI’s import guide confirms that configuration can be migrated while also requiring a review of permissions, authentication, hooks, plugins, and runtime assumptions. A provider-neutral source or a simpler single-tool workflow may be a better tradeoff elsewhere.

Follow one slice from requirement to operations

The proposed workflow becomes tangible when one narrow requirement travels through the entire chain:

1. Frame the behavior. State the 30-seat scenario as a workshop example, not production evidence. Record the capacity invariant and the desired two-request outcome without selecting a storage engine or concurrency mechanism.
2. Expose unresolved meaning. Ask when FIFO order is assigned, how identity and duplicates work, what cancellation means, and who owns each datum. Separate a confirmed registration from a successfully delivered notification.
3. Propose and accept a decision. Write an ADR that compares viable consistency approaches and their consequences. Keep it proposed while material questions remain. A named human accepts a specific choice; the agent does not approve its own premise.
4. Stage the capability delta. Generate a reviewable proposal containing the applicable rule, implementation guidance, test fixture, requested permission changes, and provenance. Approval should bind to the exact inputs and output diff. Re-running an accepted deterministic build should produce no unexplained change—an engineering property the workshop still needs to demonstrate, not one the research claims has already been achieved.
5. Verify the slice independently. Test simultaneous attempts for the final seat, a retried duplicate, cancellation followed by a single promotion, and notification failure after allocation. Check the privacy boundary by proving that Catering can obtain its count without depending on participant details. The acceptance cases should be derived from the rule, not copied from the generated implementation.
6. Carry evidence into release and operation. Link the requirement, domain artifact, ADR, capability revision, code, tests, release, and operational check. A generated runbook is not evidence that recovery works; exercise the chosen rollback or restoration path once it has been decided.

This chain does not guarantee good software. It is designed to make missing reasoning and missing evidence visible before “the agent finished” is mistaken for “the system is correct.” It also supports proportionate governance: use the full chain where failure, access, or architectural drift is costly; keep lighter controls for low-risk, easily reversible work.

Measure outcomes, not agent activity

Three checks that sound similar should remain separate:

Check	Question	Last-seat example
Domain invariant	Did the behavior remain correct?	Confirmed registrations never exceed capacity.
Architecture fitness check	Did the structure honor an accepted boundary?	Catering cannot depend on participant personal data.
Service-level objective	What user-relevant reliability did the operation achieve?	A defined share of eligible registration attempts completes correctly over a stated window.

Do not invent the number in that final row. A useful SLO requires a defined indicator, numerator, denominator, window, exclusions, owner, and stakeholder agreement. Google’s SRE guidance also recommends recording whether a target came from experiment, observation, or an ad hoc choice.

Agent evaluation needs the same clarity. A final outcome and the trajectory used to reach it answer different questions. Deterministic checks, calibrated model graders, and human review each reveal different failure modes.

For a real pilot, track correct accepted outcomes, rework, escaped defects, human review minutes, end-to-end lead time, and cost per accepted result. Keep failures and abandoned attempts. Distinguish agent waiting from active human work. METR’s 2026 experiment-design update is a useful warning: selection effects and concurrent agent work can make seemingly simple productivity estimates unreliable.

A practical Monday-morning experiment

Choose one consequential requirement already in your backlog and ask four questions:

• What business invariant or user outcome must survive?
• Which human-owned decision explains the chosen approach and its consequences?
• What may the agent read, change, execute, or send outside the environment?
• Which independent test and operational signal would let someone else judge the result?

Run the smallest workflow that answers all four, then measure its cost as honestly as its benefit. The durable unit of trust is not a model, a prompt, or an instruction file. It is the traceable chain from intent to evidence.

Read more

• Event Modeling: What is it? Adam Dymitruk explains how events, commands, views, wireframes, and scenarios can turn a business process into an implementation-neutral blueprint.
• Documenting Architecture Decisions Michael Nygard’s original article shows how concise ADRs preserve context, status, decisions, and consequences for future engineers.
• How Claude remembers your project Anthropic clarifies how persistent instructions are loaded and why behavioral context should not be mistaken for enforced control.
• Specification Agent Skills The specification defines the portable SKILL.md package while showing which optional capabilities remain dependent on client implementation.
• Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? This preprint provides a useful counterweight to unqualified claims that repository context automatically improves task success.
• Towards a Science of Scaling Agent Systems A controlled multi-agent study explores why coordination architecture must fit the task and why additional agents can add overhead.
• Demystifying evals for AI agents A practical guide distinguishes outcomes from trajectories and compares deterministic, model-based, and human graders.
• Exploring the Threat Landscape of Agent Skills Snyk’s technical account separates manually confirmed malicious skills from broader critical-risk findings and makes capability provenance concrete.
• We are Changing our Developer Productivity Experiment Design METR explains why task selection, participant selection, and concurrent agent work complicate productivity measurement.
• The Site Reliability Workbook: Implementing SLOs Google’s SRE chapter connects user journeys, reliability targets, stakeholder approval, and explicit documentation of how thresholds were chosen.