Working with agents / 2026
The decisions I make, the direction I give, and how I check the result.
Working decisions and the evidence behind them.
A fleet-maintenance platform for mechanics, managers, and administrators across multiple shops.
What’s happeningAn inherited fleet-maintenance codebase needed a security and correctness audit. I asked for implementation plans that future agents could use, a register of checks still needing proof, and a dashboard that showed me the next decision.
The pointI define the risks to investigate, require agent-ready plans, and make the remaining evidence and my next review decision visible.
Break the broad audit into bounded implementation plans, each with enough context for a fresh agent to act.
Keep a separate register of checks that still need runtime evidence.
Use those checks as acceptance criteria so a code change does not stand in for proof that the risk is resolved.
Make the next task, its evidence, and the decision I need to make visible at a glance.
The historical records contain bounded plans, a testing register, and a review dashboard. The diagram explains how I coordinated the work.
The original audit was primarily source review. Its test register records missing runtime proof; the audit itself is not a penetration-test pass. This workflow diagram does not establish current release readiness.
Paraphrased from historical working sessions and project records; supporting media and evidence limits are labeled separately.
What’s happeningWe established design principles for Malpais frontend work: put ease of use and reliability first, minimize the mechanic’s time at the computer, and reuse patterns so familiar interactions carry across pages. The later dashboard wording exchange shows those principles guiding a specific decision.
The pointThese recorded principles act as guardrails for any agent working on the frontend. I ask agents to judge each change against the mechanic’s workflow, keep shared behavior consistent, and make a clear case for exceptions rather than following my wording blindly.
Prioritize the mechanic’s ease of use and reliability. Keep familiar behavior consistent across screens and make exceptions only where they add value.
Judge the wording from the mechanic’s point of view, and challenge my suggestion if another version is clearer.
The banner was revised to ask users to choose one or more shops before viewing dashboard data.
The principle became shared product guidance. The review process later became the portable frontend-ux-review skill.
The image preserves the intermediate state; the later transcript reports the wording change and 14 focused tests. No user time-saving study was run.
Paraphrased from historical working sessions and project records; supporting media and evidence limits are labeled separately.
What’s happeningI designed a multi-agent review council, then questioned whether its review process was wasting effort. An agent challenged my suggestion to share findings during discovery, and I refined the referee’s handoff for a fresh implementation thread.
The pointI ask where review cost goes, invite criticism of my own ideas, and protect independent discovery while improving handoffs and validation.
Have a referee validate uncertain findings, combine duplicates, and check severity after the independent reviews finish.
Revisit the review process’s cost. Could narrower handoffs or a different sequence reduce repeated work?
Sharing findings during discovery could anchor later reviewers. Keep discovery independent and consolidate evidence afterward.
Make the final report self-contained enough for a fresh agent to implement the accepted findings.
The revised skill uses bounded context, risk-based reviewer selection, centralized validation, and an implementation-ready referee report.
The workflow is reconstructed from historical skill definitions and revision records. It does not establish equal defect recall or a measured cost saving.
Paraphrased from historical working sessions and project records; supporting media and evidence limits are labeled separately.
What’s happeningA manual UX audit had many flows to inspect and fix. I asked for a durable board that lets a new agent pick up the next action, then simplified the process into a repeatable implement-and-verify loop.
The pointI move workflow state into a durable tracker, simplify the control flow, and preserve incomplete evidence instead of making “done” hide it.
Put the next action in a durable tracker so a fresh thread can continue without asking me to reconstruct the workflow.
Combine the stages into one action per flow, with an implement-and-verify loop until the result is satisfactory.
The board retains flow identity, revision, evidence, and the next instruction. A new agent can resume from that record.
This describes the early UX tracker, distinct from the audit review dashboard. The field summary explains the recorded workflow; it does not rerun historical tests.
Paraphrased from historical working sessions and project records; supporting media and evidence limits are labeled separately.
A configurable show engine that maps media across surfaces and runs playback on a Raspberry Pi.
What’s happeningI started with an installation idea and asked what decisions were still missing. The resulting specification made projector and screen setup configurable and gave an implementation agent a runnable first milestone.
The pointI use discovery to expose missing decisions, generalize the design beyond one display, and give the implementation agent a self-contained, runnable first milestone.
Use discovery to identify the decisions that still need answers.
Make projector and screen setup configurable, with an intuitive interface and no hard-coded installation layout.
Give a fresh implementation agent the complete specification, a runnable first milestone, and explicit verification requirements.
The specification became a running configurable prototype, with hardware qualification left as separate work.
The recovered source is written discovery, not the missing voice recording. The first milestone’s runtime evidence was on the Mac.
Paraphrased from historical working sessions and project records; supporting media and evidence limits are labeled separately.
What’s happeningA proposed rendering architecture needed both a feasibility judgment and a clear handoff. I asked one agent to capture the decisions for a fresh implementer and brought another agent into the Pi diagnosis before changing the repository.
The pointI separate implementation, design consultation, and on-device diagnosis. I require the handoff to carry the decisions and evidence, rather than relying on a long shared conversation.
Investigate feasibility candidly; be willing to drop an approach that is unlikely to work.
Carry the architecture decisions into a comprehensive implementation handoff that assumes no prior conversation context.
Separate repository changes from project configuration, and get a second opinion on the proposed device fixes.
The architecture moved toward compiling on the Mac and delivering playback to the Pi, with an explicit review handoff.
This demonstrates how the work was assigned. It is not a comparative benchmark of the models.
Paraphrased from historical working sessions and project records; supporting media and evidence limits are labeled separately.
What’s happeningThe live preview appeared to burden the Pi renderer. I asked for root-cause investigation, allowed a lower preview rate, then required metrics and a sustained device report after the change.
The pointI define the experience that must survive, allow explicit tradeoffs, and ask for instrumentation so the result can be checked after deployment.
Investigate the cause of the slowdown before committing to a fix. A lower render rate is an acceptable tradeoff.
Preserve live preview, even at a lower rate or resolution, and instrument the change so its effect can be checked.
The later device report described more than two hours of continuous runtime without a restart or configuration change.
The implementation rate-limited capture and moved JPEG encoding off the render loop; the later report checked sustained operation.
Configuration and code both changed. These measurements do not establish a controlled 2× speedup or physical four-projector acceptance.
Paraphrased from historical working sessions and project records; supporting media and evidence limits are labeled separately.
An iOS research prototype for finding trusted people through consent-aware location sharing and directional AR.
What’s happeningBeacon’s planning documents contained decisions from different stages of the project. I gave agents an authority order for resolving conflicts and recorded when a newer sharing decision superseded an older one.
The pointI separate current requirements from vision, research, and historical rationale, then explicitly resolve decisions that changed.
Resolve conflicts against current requirements, repository records, and freshly observed device behavior. Recollection should not override stronger evidence.
A newer decision replaced reciprocal sharing with independent control of each person’s outbound sharing and expiration.
An old answer is explicitly superseded, so a fresh agent can distinguish today’s requirement from yesterday’s rationale.
This is a documented context system, not a demonstrated knowledge graph. Early decisions are preserved in repository records where original chat is unavailable.
Paraphrased from historical working sessions and project records; supporting media and evidence limits are labeled separately.
What’s happeningBeacon had unfamiliar technical and device questions. I used bounded experiments with explicit decisions, asked the agent to make local simulator progress, and left physical-device checks visible for later verification.
The pointI turn architectural unknowns into bounded experiments with rejection criteria, keep progressing locally, and retain the device checks I cannot yet prove.
Bound each experiment around an architecture question and record an adopt, revise, or reject decision with the available evidence.
Make useful progress with local tools and simulators, while recording checks that need a physical phone.
The checkpoint distinguished completed local feasibility work from the still-incomplete overall stage.
The handoff preserves both the completed local work and the evidence needed to decide the next step.
Beacon remains a prototype. Database and simulator checks do not establish physical-device or field qualification.
Paraphrased from historical working sessions and project records; supporting media and evidence limits are labeled separately.
I turn a useful way of working into instructions that another agent can follow.
review-code-council
The point: I design how agents challenge a change, verify each other’s claims, and hand off work.
All eight named specialists plus a wildcard. The referee joins after discovery, when synthesis is needed.
If every required reviewer finds no issue and no material gap, write a no-findings report without a referee pass.
Coordinator
I give reviewers the same constraints, accepted deferrals, and selected diff. The coordinator chooses the relevant roles and runs shared validation once. Each reviewer gets a fresh context.
Output A bounded snapshot, a curated brief, a risk map, and reusable test evidence.
Run shared validation centrally; reserve repeated checks for a specific finding that needs them.
Specialist agents
Correctness, security, and tests always run. Other roles depend on the change; a full council uses all eight named specialists plus a wildcard. Reviewers work in capacity-bounded waves and cannot read each other’s findings.
Output Independent candidate findings, not a shared consensus.
Keep reviewers’ discoveries independent until the synthesis stage.
Coordinator + schema checks
Each candidate needs a concrete trigger, location, evidence, and consequence. The coordinator groups likely duplicates mechanically; it does not decide which claims are true.
Output One validated input bundle with every candidate accounted for.
Account for every candidate finding before deciding which claims hold up.
Fresh referee
The referee independently traces or reproduces each candidate, corrects confidence and severity, and merges shared root causes. Extra reasoning is reserved for unresolved catastrophic risks.
Output A disposition for every candidate and only defensible findings in the report.
Treat each submitted finding as a claim to investigate.
Validated report → fresh agent
The final report carries the constraints, accepted findings, fix direction, implementation order, and tests into a new thread. A validator checks the snapshot and disposition totals before the parent accepts it. Implementation is a subsequent task.
Output A standalone implementation handoff with explicit remaining evidence gaps.
Give a fresh implementer the context, constraints, and acceptance checks in one report.
Independent specialist
Traces domain rules, state transitions, boundaries, and error handling.
Runs when Every review.
Independent specialist
Checks authentication, permissions, tenant boundaries, and attacker prerequisites.
Runs when Every review.
Independent specialist
Checks whether tests would catch meaningful regressions, including failure and permission paths.
Runs when Every review.
Independent specialist
Looks for coupling, duplicated policy, and structural choices that raise defect or change risk.
Runs when Broad refactors, new abstractions, ownership changes, or high complexity.
Independent specialist
Traces concurrency, retries, resource lifecycle, performance, deployment, and failure recovery.
Runs when Async work, queues, caches, retries, runtime configuration, or operational changes.
Independent specialist
Checks affected user journeys, responsive states, accessibility, focus, and navigation data loss.
Runs when UI, forms, client state, browser behavior, or user journeys change.
Independent specialist
Traces producers and consumers for compatibility, validation, serialization, and error contracts.
Runs when Endpoints, shared types, events, public functions, or integrations change.
Independent specialist
Examines transactions, constraints, migrations, tenant policies, backfills, and partial rollout.
Runs when Persistence, queries, schemas, migrations, policies, or retention change.
Independent specialist
Looks across ownership seams for unsafe composition and assumptions missed by a single lens.
Runs when Cross-layer composition, multiple domains, uncertain ownership, broad impact, or a full council.
frontend-ux-review
The point: I make product judgment, live verification, and recorded approval part of the same workflow.
Feedback returns to the fix.
Retest and recapture what changed.
Feedback → scoped fix → live test → fresh evidence → review again.
Agent
The agent reads the actual diff, product principles, and prior approvals. It prepares the real route with representative local synthetic data, preserving unrelated work.
Output A known surface, scenario, and review boundary.
Start from the agreed surface, product constraints, and a usable running app.
Agent
The agent fixes obvious blockers within scope and exercises the real interaction. If the feature saves data, it checks both the visible result and the durable state. Focused tests are proportional to the change.
Output A working interaction and evidence of its behavior.
Check the real behavior as well as the appearance.
Agent
Capture the state the user needs to judge. Check responsive behavior, focus, overflow, and state preservation. Use the project’s review sizes; default conventions cover desktop, tablet, and phone.
Output A small, labeled evidence set tied to the scenario.
Show evidence from the relevant states and viewport sizes.
Aaron
I judge the task, language, consequences, and next action. Feedback returns to implementation and verification. The agent recaptures only affected evidence before bringing the surface back.
Output A concrete change request or an explicit approval of the reviewed surface.
Record the human’s decision and keep revisions within the agreed scope.
Agent + durable tracker
The agent records approval in the existing tracker or working notes, preserves the accepted state, and moves to the next in-scope surface. Deferred work and verification gaps remain visible.
Output A resumable record of what is approved, deferred, and still unproven.
Preserve approved work and identify what remains deferred or unverified.
Designer
The point: I turn recurring design feedback into a reusable role, so I spend less time repeating the same corrections.
My Designer agent works from a written taste profile and a broader design philosophy, drawn from feedback across projects: make the important thing obvious, put actions where attention already is, and give each product an identity that makes sense for its users. When a correction belongs beyond one project, I record the principle and its limits in durable guidance. That carries my judgment forward while leaving each app room for its own visual language.
I use Designer when planning an interface and reviewing its implementation. It combines my preferences with Impeccable’s design guidance, with the current project’s needs taking priority. Common AI-generated interface habits get challenged; claims about a particular model’s taste remain hypotheses until there is evidence.
The review still has to look at the actual screen. Agents miss details, so I ask for rendered comparisons against approved mocks, element by element. A polished screenshot or working code is a starting point for judgment, not proof that the design survived implementation.
These diagrams explain my recorded workflows. Selecting a scope or path does not run agents or approve a real screen. The council produces findings; the UX review guides live remediation and human approval.
The council and UX diagrams summarize the skill definitions reviewed in September 2026. The Designer section describes the reusable role established in October 2026. Current project requirements and user direction take priority. Private conversations and internal review records are not published here.
Product context only · Excerpt of actual local app footage with synthetic data. The isolated recording copy included local fixes; it was not the deployed beta.
Product context only · Excerpt of the real Mac application. Local native renderer; no physical projector or Pi deployment shown.
Product context only · a design mock for sharing and permissions, not an implemented or field-tested screen.