Earlier this month, one of my AI agents swept my websites for broken links and found several dozen. Most had obvious fixes it applied on its own. Fourteen needed my judgment: redirect this old URL or retire it, restore this missing image or drop the reference. Every question was legitimate. The delivery was the problem. The agent asked me in chat, one question at a time, and each question stopped its work until I answered.
Fourteen interruptions for one link sweep. Now multiply that across the way serious engineering organizations are starting to run: several agents working in parallel on upgrades, triage, refactoring, and operations, each one generating decisions only a human should make. The interruption cost doesn’t grow linearly. It compounds, because every context switch costs the human far more than the minute the answer takes. This piece is for engineering leaders whose teams are heading into that world, and for any practitioner whose agents already owe them more answers than the day has room for.
In synthesis engineering, the discipline I’ve been building for rigorous, production-grade collaboration with AI, this sits inside the Direction Dynamic: the human directs, decides, and verifies; the AI executes, surfaces options, and reports evidence. Neither role blurs. The Direction Dynamic keeps acceleration under human authority. But taken naively, it has a throughput problem: if every decision travels back to the human as its own conversation, the human becomes the bottleneck, and the pressure to “just let the agent decide” grows with every interruption. That pressure is exactly how teams slide from AI-assisted engineering into unreviewed AI output.
The answer is not fewer decisions reaching the human. It’s a better vehicle
for them. I call it the Decision Packet, and I’ve open-sourced the
generator as synthesis-decision-packet in my
synthesis-skills
collection.
What a Decision Packet is
A Decision Packet is a single self-contained HTML page, one row per decision. Each row carries the item in plain language, the agent’s recommendation with its reasoning, a link to the evidence, and the consequences of taking or declining the recommendation, stated both ways. Rows that share a decision shape share one option set; a row whose real choices are different carries its own options, because forcing an awkward decision into someone else’s buttons is how nuance gets lost. I open it like a checklist, click my answer on each row, add a note wherever a button can’t carry my meaning, and paste the generated summary back to the agent. The agent executes the batch. One sitting, every decision, and my attention spent where my judgment actually changes the outcome.
The interface is simple, but its integrity rests on two design rules that preserve human judgment.
The examples below are constructed.
Example one: a platform team’s upgrade wave
A platform team owes its principal engineer decisions across a service-upgrade wave. Most are routine; a few carry breaking changes.
The engineer bulk-accepts the routine upgrades, works each breaking change against its diff, and holds one with a note: “not until the payments freeze lifts.” A decision process that would otherwise splinter across separate threads is handled in one pass, with each exception visibly reasoned.
Example two: a product team’s feature-flag cleanup
A quarterly audit turns up a long list of stale feature flags. Most belong to experiments that have ended. Two that look stale are load-bearing: a payments kill switch and a regional consent gate.
The team lead bulk-accepts the routine removals, keeps the load-bearing flags with ownership notes, and holds a stalled experiment for a conversation with its former owner’s manager. Flag debt that had survived repeated cleanup meetings gets resolved in one sitting, while the dangerous rows receive individual attention.
Example three: a solo maintainer’s security triage
An open-source maintainer’s agent sweeps the outstanding security advisories across her repositories and recommends a disposition for each: patch and release, false positive with the reasoning documented, or affects an example only.
Security triage is deliberately not a bulk-accept case. The maintainer reviews each advisory against the evidence, using the packet to centralize the agent’s recommendation and her disposition rather than to turn security judgment into routine work.
One real packet, including the version that failed
The examples above are constructed. This one is real, and it begins with the packet failing. This week I closed out a research project on my open-source writing-quality skill with a fifteen-row packet. The first version collected zero of fifteen decisions. Every mechanical property worked, the buttons and filters and marked recommendations included, and none of it mattered, because the rows named things only the session that wrote them knew: internal test codes, treatment vocabulary, corpus jargon. My verdict on my own tool’s output was that it read as if “written in some alien or machine language.”
The repair was a reader contract, now enforced by the generator itself: a packet must name its reader, gloss any surviving term of art, and state every row’s consequences both ways in the reader’s own terms, or the generator refuses to build it. The rewritten packet read like this:
Idea: piling up metaphors instead of explaining -> Keep in holding pen; test once more later
Fifteen of fifteen decided in one pass. My browser happened to block local storage that day, so nothing persisted between sittings; the paste-back summary carried every decision anyway, which is the design absorbing a failure it was built to absorb. The lesson stands in front of the two rules below as their precondition: structure without comprehension collects nothing. A packet is a stranger-read document, and its reader arrives without your context, even when its reader is you.
The discipline: Honest Defaults
Now the part that makes this synthesis engineering rather than a UI trick.
Rule one: the recommendation is marked, never pre-selected. The tempting design is to pre-select the agent’s recommendation so the human only clicks where they disagree. I rejected it on principle, and the principle generalizes far beyond this tool: a record that opens fully decided cannot distinguish “I agreed” from “I never looked.” Scroll to the bottom of a pre-selected packet, press copy, and you hold a complete-looking record of decisions nobody made. So in my packets the recommended button is visually marked (the eye lands on it, and agreeing costs one click) but a fresh packet has nothing selected, and every recorded agreement is a real gesture. Ballots don’t arrive pre-marked. Code review tools don’t pre-press approve. Wherever the record is the point, defaults poison it.
Rule two: bulk acceptance is recorded as bulk. Thirty routine upgrades don’t deserve thirty considered clicks, and any tool that pretends otherwise will train its users to lie. So the packet has an explicit, confirmed bulk-accept, and the rows it covers are recorded distinctly from rows the human clicked individually. The summary the agent receives separates the two. The record therefore shows precisely what I examined closely and what I accepted as routine. When something surfaces later, that is the difference between “I signed off on this specifically” and “this rode through in a batch.” Both are legitimate. Conflating them is how accountability quietly evaporates.
These two rules are one idea seen twice, and in synthesis engineering I call it Honest Defaults: the integrity of the record outranks the convenience of the workflow. In synthesis engineering the human’s accountability is the load-bearing wall; every tool in the practice is built so that what the record says the human decided is what the human actually decided. Speed comes from batching, filtering, and good recommendations, never from blurring who chose.
The boundary that keeps it safe
The Decision Packet collects decisions; it does not grant authority beyond them. Anything a button cannot express faithfully returns to conversation, and consequential external actions keep their own explicit approval steps regardless of what a packet row says. The packet removes the transport cost of asking. The asking, and the authority, stay with the human.
The generator enforces its own honesty too: duplicate row ids, a recommendation pointing at an option that doesn’t exist, or a packet with no recommendations at all are build errors, not warnings. A tool whose output feeds human accountability has to refuse to produce structures that could misrepresent it.
Where to start
If your agents owe you a batch of similar decisions, the pattern transfers directly: batch the decisions, mark recommendations without pre-selecting them, record bulk as bulk, and route anything a button cannot express faithfully back to conversation. The generator, with a worked example and its validation rules, is in the synthesis-skills repository, CC0 like the rest of the collection, and the broader practice it belongs to is at synthesisengineering.org. The decision packet is one pattern among many, and its value appears as soon as an agent owes you a batch of decisions: you get the throughput without surrendering the record of your own judgment.