agent-surface

Five surfaces. Four of them are ranked by the only thing that matters, which is whether the output gets used. The fifth has no reader at all.

1. A draft inside the tool they already use. The email sits in the drafts folder. The note is on the record. The row is in the sheet they open every Monday. This wins almost every time, because it asks for no new habit and the human edit happens where editing already happens.
2. A scheduled run with a digest where they already read. Good when the output is a list rather than a thing to act on one at a time. Its low volume sibling is an alert in the same place: same channel, no daily rhythm, speaks only when there is something. A nightly job that usually produces one row is an alert, not a digest.
3. An on demand command. Good when the trigger is human judgment and the run is cheap. A rep decides this account is worth the work.
4. A new dashboard or a new app. Last, always. A dashboard is a place someone has to remember to go, and in two weeks nobody goes.

And the fifth, off the ranking because nobody reads it:

5. A write into a system of record, with no human reader. The enrichment job that corrects a field nightly. It belongs on the list because people build it constantly and the four above do not describe it. Its day one change for the user is zero, which is exactly the problem: nobody will notice it being wrong. It ships only with the third rule in Step 3 satisfied, a checkpoint or a source stamped on every value it writes, and its review burden is double the sample size, not double the cadence, because the review is the only thing standing between a wrong value and a quarter of decisions made on top of it.

Write down the honest answer to one question: what does the user have to do differently on day one? Count actions, not clauses: opening a tool they did not have open, remembering a command, moving a result from where it appeared to where the work happens. "Ask the bot" is three actions written as two words. If the answer is more than one new action, the surface is wrong, not the user.

Then check whether the output shape actually fits the surface. A structured object needs a field or a row. A message needs a draft. A verdict with reasoning needs somewhere the reasoning survives, because a surface that shows only the answer throws away the part that makes it trustworthy.

Pick for the typical run rather than the maximum one. A list of up to 40 rows that is usually 0 or 1 rows is not a digest, it is an alert, and choosing by the declared capacity gets you a daily email that is empty most mornings.

Name what fires it: a schedule, a record change, a human command, or an inbound message.

Then answer the question that gets skipped: what does it do when it fires and there is nothing to do? Nothing on the output channel. No empty digest, no zero row report, no "no signals found this week" message. An agent that reports its own emptiness gets muted in a month, and a muted agent is a dead agent that still costs money.

The run log is a different line and it always writes. It can live in the same place the output goes, the same channel or the same sheet, as long as it is its own always written line rather than a row of the output. That distinction is the whole trick, and collapsing the two is how silence becomes the failure mode. The output says nothing on an empty run; the log says "ran, produced 0, refused 0" every single time. Silence belongs to the output, never to the log.

Three of the four triggers need their own version of this. A schedule can fire with nothing to do, so it gets the empty run rule and an overlap rule. A record change or an inbound message cannot fire empty, so the empty run rule reads not applicable and what it needs instead is a concurrency rule: what happens when ten arrive at once, which is the ordinary case rather than the edge. A human command cannot fire empty either, and its concurrency rule is usually none needed.

For a scheduled run, also write the overlap rule: what happens if the previous run is still going. The test is whether the work is standing or passing. Standing work, the stale deals that will still be stale in an hour, gets skip. Passing work, an inbound comment that exists once and is gone, gets caught up rather than skipped, because skipping it loses the thing the agent exists for. Most work is standing, which is why skip is the usual answer, and an agent whose whole purpose is "so we never miss one" is exactly the case where it is the wrong one.

The Split already decided what the human keeps. This step makes the surface enforce it, rather than trusting a convention. Where the Split and the three rules below disagree, the rules win and the disagreement goes on the DENIED line as a change to the Split, named as such. A Split that lets an agent write into a shared system unattended was written before somebody thought about who reads that field.

The test is blunt. Can the irreversible thing happen without a person touching it? If yes, the checkpoint is a policy and not a checkpoint. A draft that sits in a folder is structural. A send that is technically possible but "we agreed not to" is not.

Three rules that do not bend:

• Nothing leaves on its own to an audience the agent cannot recall it from. Customer facing is the obvious half: a first touch is sent by a person, every time, and the surface should make that the only path rather than the polite path. The half people miss is internal. An email to the exec team, a post in a company channel, a message to a customer's shared Slack, all land in people's heads and cannot be unsent, so they get a person too. The test is not who the audience is, it is whether you could take it back.
• Anything that spends money gets a batch approval above it, showing the amount and the weakest records first.
• Anything that writes into a system other people read, a CRM field, a shared sheet, a ticket, is irreversible in practice, because a wrong value cannot be unwritten out of the heads of the people who read it. It gets either a checkpoint or a visible source on every value it wrote, so a reader can tell where the number came from. A silent unattended write into a system of record is the most common harm one of these agents does, and it is neither a send nor a charge, which is exactly why the first two rules miss it.

Write the checkpoint as who approves, what they see, and what they click. Then name the mechanism that makes the forbidden path impossible, not the intention behind it. "Structural" is a claim, and the evidence for it is a missing credential, an endpoint the agent cannot reach, a queue only a person can drain. If the only evidence is the sentence you just typed, it is a policy.

When the requester asked for something any rule in this file forbids, wherever that rule sits, the card carries a DENIED line: what was asked, which rule, and what they get instead. Silently substituting the safe version is worse than refusing, because the person still believes they got what they asked for. A sign off from someone senior does not move the rule, and it goes on the DENIED line too, named, so the decision is visible now rather than argued about later.

Every agent on a surface has three states and most surfaces show one.

• Ran and produced. The output is there. Easy.
• Ran and refused. The abstain clause fired. This must be visible and it must carry its reason. Refusals are the most useful thing the agent tells you and the first thing a surface hides.
• Did not run. The schedule failed, the credential expired, the upstream never delivered. This is the dangerous one, because a dead agent and a quiet week look identical, and the assumption will always be the quiet week.

So the card names one specific place a human already looks, a channel, a sheet, a page, where four things appear: the last run time, the count produced, the count refused, and the reasons. That is the whole requirement. Not a monitoring stack, one visible line that writes on every run including the empty ones. Naming a place that does not exist yet is the same as naming none, so if it has to be built, that is a blocking question rather than a line.

Then one staleness rule next to it: how long without a line is wrong for this trigger. A nightly agent with no line for two days is the alarm. An event triggered agent has one too, measured against its own arrival rate: a classifier on a queue that normally sees fifty tickets a day and has written nothing for six hours is broken. A human triggered agent has none available, because nobody can tell the difference between unused and broken, and saying that out loud on the card is the honest version rather than a gap.

The failure to design for: an agent that has been broken for eleven days while everyone believed it was working. That happens through silence, not through errors.

One documented way to turn it off that the owner can perform without the builder. A toggle, a command, a disabled schedule. Write it on the card in the imperative. If you do not know what the mechanism is, the line is UNKNOWN and it is a blocking question, not a sentence you compose. A kill switch that was described but never confirmed is the same as none, and confirmed has a specific meaning here: the owner has performed it at least once and the card records who did it and roughly when. "Dana disabled it during the March migration" counts. A missing exact date is a detail to tidy, not a reason to call a working switch UNKNOWN. A dry run before launch is the preferred form; an owner who has already disabled the thing in anger counts too. What does not count is a mechanism somebody described.

If turning it off requires a code change by a specific person, you do not have a kill switch, you have that person's calendar. The moment an agent writes something wrong to a customer is exactly the moment that person is on a plane.

One person, named. A human being. Not a team, not a function, not two people who both think the other one has it, and never the agent itself. An agent cannot be accountable for its own drift, because the thing under review cannot be the reviewer, and a self owning agent is an orphan with a name on it. If the only candidate offered is the agent or a function, the owner line stays UNKNOWN and it is a blocking question.

The owner does four things and they go on the card:

• Reads the sample. The agreed number of outputs per review, or all of them when there are fewer than that, chosen worst first rather than at random. Random sampling on a 90 percent agent shows you nine good ones. Worst first needs something to sort by, so the surface has to carry one weakness field: the count of unsupported claims, the number of missing inputs, the confidence the contract already produces. If the output has no such field, that goes back to agent-contract, because an unsortable output turns the review into a lottery. The card is still written, it carries the blocking question, and it is headed NOT READY TO TURN ON rather than deploying and hoping.
• Checks the contract, not the vibe. The must-always rules are the checklist. Did every claim have a source. Did the refusals fire on the right cases. This is why the contract lives next to the verdict.
• Owns the kill switch.
• Triggers a re-score when the contract changes. Any edit to the artifact invalidates the verdict, and the prebuild hash check will demand it regardless.

The owner does not have to be the builder and usually should not be. The person who feels the output is wrong first is the person who uses it.

Weekly for the first month, then monthly. In the calendar with the owner's name on it, because a review that lives in a document is a review that happened twice.

What the review looks for, in order, because the order saves time:

1. Input drift. Almost always the real cause. The upstream field changed, the form added a question, the site redesigned, the Clay table got a new column. The agent is fine and its world moved.
2. Refusal rate moving. A rising refusal rate is usually input drift, already visible. A falling refusal rate to zero is worse, because that is an agent that has started answering things it used to decline. The baseline is the refusal rate from the verdict run, so record that number on the card at deployment. Without it the first review has nothing to compare against, which is the review that matters most. A baseline of zero is not a clean bill of health, it means the abstain band never fired during scoring, and that goes back to eval-set-builder as a question about the set rather than onto the card as a number.
3. Fence leaks. Someone asked it to do something on its fence. That is a sibling agent asking to be built, and it goes back to name-the-job.
4. Output the owner would not have sent. One real example beats a rate. Capture it as case 101 and re-score.

State the condition under which this agent gets turned off rather than maintained: the owner leaves and nobody takes it, two consecutive reviews get skipped, or the job it does stopped mattering.

Turning it off is the correct move and it needs to be pre authorized, because nobody wants to be the person who killed a thing that still technically runs. Orphan agents are how an organization learns to distrust all of them at once, and the first one is always a thing somebody shipped and left.