Implementation worksheet · 6 min read
A Marketing Agent Action-Permission Matrix
List every action the agent can take and assign each one of four levels: autonomous (it acts and logs), review-required (it prepares, a human approves, it acts), human-only (the agent can recommend but never execute), and forbidden. Then add two columns that make the matrix usable — a blast radius estimate (how many customers a single mistake reaches) and a reversibility note (can this be undone). Anything with a large blast radius and no undo belongs in review-required or human-only regardless of how reliable the agent has been, because reliability is a rate and the matrix is about the tail.
Agent demos show the same capability that production governance has to constrain: the agent decides and acts. In a demo that is the point. In a marketing system the actions reach customers, cost money and cannot be recalled, and the difference between a useful agent and an incident is entirely in which actions it may take without a human. Nobody writes that down until after the first surprise.
Put it into practice
1. Enumerate actions at the level the agent actually acts
Not 'manage campaigns' but the specific verbs: draft copy, create a segment, modify a segment, schedule a send, execute a send, pause a campaign, change a suppression rule, adjust a budget, message an individual customer. Coarse entries hide the dangerous action inside a safe-sounding one, which is how 'manage campaigns' comes to include 'send to everyone'.
2. Assign a level, and default new actions to review-required
Autonomous, review-required, human-only, forbidden. When a capability is added later and nobody has classified it, the system should treat it as review-required rather than autonomous. Fail-closed is the only sane default here, and it has to be the code's default rather than a policy people remember.
3. Estimate blast radius per action, in customers
A drafted email reaches nobody. A segment change reaches whoever is next messaged. An immediate send reaches everyone in the segment now. Writing the number down changes the conversation from 'is the agent good' to 'how many people does one mistake reach', which is the question that should decide the level.
4. Mark reversibility honestly
Draft: fully reversible. Schedule: reversible until it fires. Send: not reversible, ever. Suppression change: reversible but the missed messages are not. Large blast radius plus no undo means review-required at minimum, no matter how well the agent has performed, because past performance describes the average and the matrix exists for the tail.
5. Name the approver per review-required action, with a fallback
An approval queue with no named owner is a queue that fills up, and a full queue creates pressure to grant autonomy for the wrong reason. Name the person, name the deputy, and state the response time you are actually committing to.
6. Review the matrix on a schedule and after every incident
Capabilities accumulate quietly. A quarterly review against the current action list catches the ones added since, and the post-incident review catches the level that was set too permissively. Both are short; neither happens unless scheduled.
The action-permission matrix
Copy this structure into your review document and record your observed result for each row.
| Action | Level | Blast radius | Reversible | Approver |
|---|---|---|---|---|
| Draft copy | autonomous | 0 customers | yes | n/a |
| Propose a segment | autonomous | 0 | yes | n/a |
| Modify an existing segment | review-required | whoever is next messaged | partly | |
| Schedule a send | review-required | segment size | until it fires | |
| Execute a send now | human-only | segment size | never | |
| Message an individual customer | review-required | 1 | never | |
| Pause a campaign | autonomous | 0 — fails safe | yes | n/a |
| Change a suppression rule | human-only | all future sends | partly | |
| Change consent state | forbidden | — | — | n/a |
| Adjust spend or budget | human-only | financial | partly | |
| Any newly added capability | review-required by default | unknown | unknown |
A failure worth checking
Granting send autonomy because the drafts have been good. Draft quality and send safety are different questions — the first is about the median output, the second about the worst one, and a thousand good drafts say nothing about the segment filter that silently resolved to every contact. The blast radius and reversibility columns exist to keep that conversation honest, because 'it has been reliable' is the argument that always gets made and never addresses the actual risk.
Common questions
Should an agent ever send without review?
For low blast radius and reversible actions, reasonably. For an immediate send to a large segment, the honest answer for most teams is no — not because agents are unreliable but because the action is irreversible and the cost of the rare failure is out of proportion to the time approval takes.
How do we stop the approval queue becoming a bottleneck?
Reduce what needs approving rather than approving faster. Move genuinely low-risk actions to autonomous, batch similar approvals, and make the approval surface show the resolved audience count rather than a description. Most queue pain is actually review friction, not review volume.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.