On Monday afternoon I sat down with a catch-up decision packet: thirty-one decisions my agents had collected over several busy days, each on one page with the agent’s recommendation and the consequences of taking or declining it. I answered all thirty-one in one sitting. The packet did its job.
The message that came after it did not. My agent carried out the rulings and reported back in a single chat reply: what it had already done, thirteen messages waiting for my approval before it could send them, four more texts to check, five messages I had to send myself from WhatsApp and LinkedIn, and a finding about one of the projects. Every line was accurate. I still couldn’t tell, at a glance, what was done, what I needed to approve, what I needed to type and what I needed to send. I told the agent so, in about those words. If your agents finish real work every day, you have likely read a reply like it, and this piece is for engineering leaders and practitioners in that position.
That reply exposed the other half of the throughput problem the decision packet solves. A packet batches what the human has to decide. Once the agents act on those decisions, what remains is what the human has to do, and it comes back as prose: a status report with the actions buried inside it. The end of an agent’s run is where the human’s attention is scarcest and where the agent’s report is longest.
So I built the packet’s companion, the action sheet, and open-sourced its generator as
synthesis-action-sheet in my
synthesis-skills collection.
What an action sheet is
An action sheet is a single self-contained HTML page that the agent generates from a spec it writes. It has three parts, always in this order:
- Done for you, folded: counts and links, so the evidence is there when I want it and out of my way when I don’t.
- Approve: each message the agent has staged, with its recipient and its exact text.
- Do: everything left for me: messages to send from apps the agent can’t reach, calls, and tasks only I can do. Each row names the person, the channel and the reason, shows the exact text, and carries a Copy button, an Open link, buttons to mark it done, skipped or not now, and a box for a note.
A word about who writes those messages. Anything personal, creative or long that goes out from me, I write myself; an agent may carry my words, but it doesn’t supply them. What an agent drafts for me is logistics nobody would mind a helper handling: sharing an itinerary, confirming a booking, telling someone I’m on my way. A message an agent sends itself carries a label saying so, and the sheet shows every message with its exact text, so nothing reaches anyone in words I haven’t read.
The Open link is where the page saves the most time. WhatsApp documents a click-to-chat link that opens the conversation with the message already filled in, so a WhatsApp row takes two taps: Open, then Send. LinkedIn documents no such link, so its row copies the text and opens the conversation. Links into Messages, the phone and mail behave differently across devices, and some viewers ignore them entirely, so those rows show the number or address as selectable text and treat Copy as the dependable path. A task that touches money or security gets a link to the right place and nothing filled in.
I open the sheet on my phone or laptop, work down the Do list, mark each row, and paste the page’s summary back to the agent. The summary carries my marks and notes. It never carries an approval.
Why it isn’t part of the packet
The obvious design was to extend the decision packet. I decided against it, because a decision and an action close differently. A decision closes the moment I make it. An action closes when it is done and confirmed, which can be hours later, and an action I can’t get to tonight carries forward to the next sheet under the same id, so nothing drops off because a day ran long. Packet rows also require a recommendation and the consequences stated both ways. Most actions have neither, and loosening the packet’s rules to fit them would weaken the property that makes packets work. So the two pages share one engine (the page shell, the copy buttons, the paste-back summary, the filing) and keep their own rules.
Rules that keep it honest and short
Approval codes never go on the page. By default, none of my agents can send a message on my
behalf until I type approve and a six-character code for that exact message, in my own prompt. That is the
approval step
my send guard enforces. The action sheet lists the staged messages, but the codes go in chat on a
single line, and the generator refuses to build a page that contains one. A page holding codes
would turn its pasted summary into a grant: copy the page back to the agent and you would have
approved sends you never chose.
A tap is a claim, not proof. When I mark a message done, the agent doesn’t log it as sent on my behalf on my word alone. It confirms from the source: the Messages database, WhatsApp’s local store, the sent folder. An action that leaves nothing readable, such as mailing a check, goes into the record as “principal reports done.” This is the decision packet’s Honest Defaults applied to actions: what the record says I did should be what I did.
The chat contract is three lines. After a packet or a sheet, the agent’s reply is what was done (a count and a link), the page to open, and the line of approval codes. The lists live on the page. Without this rule the agent writes the long report anyway, and the sheet becomes a second place to read the same thing.
Me or the agent, row by row
Every Do row offers a choice: Me or Agent.
Some rows take me ten seconds: open the conversation, send, mark it done. Doing those myself is faster than delegating them, and it saves the agent’s time and tokens. Others are tedious: a form on a site with no API, or a logistics note in an app the agent can reach only by operating the screen. Agents that can drive a browser or use the computer can take those rows, and the sheet makes their job easier for the same reason it makes mine easier. The recipient, the channel and the exact text are already decided and written down, so the agent executes instead of composing.
Handing a row to the agent permits exactly that text, to exactly that recipient, on that channel, once. The agent uses a guarded send tool where one exists and computer use where none does. My send guard can’t see an agent clicking Send inside an app, so the agent stops on any difference between what is on the screen and what is on the row, and afterward it confirms the send from the source like any other. Some rows never go to the agent: anything involving money, security, credentials or identity, and anything without exact text. The generator refuses a sheet that offers those to the agent, and their links are never prefilled.
What it looks like on an engineering team
This example is constructed. A release packet settles which fixes ship this week. The sheet that follows folds the merged pull requests and green builds into Done for you. Approve holds the release notes the engineering manager wrote, staged for the two channels they go to, and a status update on a customer’s ticket saying the fix ships Thursday, each waiting for its code. Do holds four rows. A call to the on-call lead, with talking points to copy. The maintenance-window notice for a partner’s chat workspace, which none of the team’s agents can reach, so she hands it to an agent that drives the browser. Rotating a deploy key, a security row that stays hers. And a vendor’s web form, which she fills in herself in thirty seconds because explaining it would take longer.
The boundary
The sheet carries no authority of its own. Every message an agent sends still goes through my send guard, a row handed to the agent is permission for that one row, and anything the page can’t express faithfully goes back to conversation. The sheet removes the cost of finding and formatting the work. The work, and the decision about who does it, stay with me.
Where to start
If your agents finish work that ends in steps only you can take, the pattern carries over directly:
separate what’s done from what needs your approval from what’s yours to do; put the exact text on
the page with a way to send it in a tap or two; keep approvals off the page; confirm each action
from its source before recording it; and decide, row by row, whether you or an agent does it. The
generator, with a worked example and its validation rules, is synthesis-action-sheet in the
synthesis-skills repository, under
Apache 2.0, beside the decision packet it builds on. The packet keeps the record of what I decided.
The sheet keeps the record of what was done about it, and turns my part into a few minutes instead
of an evening spent reading.