On this page
Last week was drafts, where a person still decides what goes out. Acts is the first rung where nobody does, so every write has to answer one question first: how would we find it and undo it?
On the Trust Ladder, the two rungs below this one, reads and drafts, keep a person between the agent and the world. Someone checks what was read, or someone sends what was drafted. Acts is the first rung where that person steps aside.
The agent changes a record, and the change is real before anyone looks at it.
That is the rung where I get careful, because it is also where the work gets useful. A summary saves a person some reading. A request filed, a lead logged, or a note attached to the right record saves the trip to another tool, every time, for everyone.
The rule we use to move a task up a rung has not changed since the opener. The failure mode at the current rung is known and rare, the step up is reversible or tightly bounded, and someone has written the paragraph of what it may do alone. At acts the second condition does most of the work, so most of this piece is about it.
Two places an agent writes for us
We have two places where an agent writes to a system of record at InTech. Both are on the acts rung, but they differ in what happens next. A time-off request the agent files still waits for a person to approve it. A note or stage change in the pipeline takes effect with no one approving it.
The first is time off. A team member asks for a day in the assistant they already have open, and the agent files the request in InTech Time. Filing is the act. It creates a record with the dates, the business days and the leave type, under that person's identity, in a pending state. Approving is a separate step. Every request in the live records that went through the approval flow was decided by a named person.
The agent puts requests into the queue and has not taken one out of it.
The split is deliberate. A request has four states, pending, approved, denied and cancelled, and a filed request can be cancelled or denied at any point before someone's plans depend on it. An approval is what other people plan around.
Filing is cheap to take back and approving is not, so approving stays with a person.
The second is the pipeline. Our CRM runs on CRAFT OS, and the internal MCP server in front of it is a thin process over the same access service the web interface uses. The agent gets the same permission check and leaves the same audit entry as a person clicking the same button, and parity tests keep the two surfaces from drifting apart on what each is allowed to do. The writes in this category are a new lead, a note on an existing one, and a change of stage. Each is a record change that shows up in the history and can be put back.
Reversibility is the gate
I ask one question of any write before it goes on this rung: if it is wrong, how does the wrong version get found, and how does it get undone?
A note on a lead passes easily. It is visible to whoever opens the lead, it carries who wrote it and when, and the fix is another edit. A stage change is nearly as easy. A proposal that goes out to a prospect fails the question completely, because the person on the other end has it. The first two belong on the acts rung. The third stays a draft that waits for a person, and I expect it to stay one for a long time.
The shared access path is what makes the gate checkable. An agent that went around the permission layer would bring a failure mode we would have to learn from scratch. An agent that goes through the same layer inherits the ones we already know: the wrong record, the wrong person, the wrong day. We have practice catching those, and the audit entry tells us where to look.
Demotion is the other half of the gate. A task on the acts rung comes back down without a meeting the first time its failure mode turns out to be one we did not know. Pulling a write back to a draft costs a few minutes of someone's attention. Leaving it up after a surprise costs more.
Who finds out
Skip's piece last week ended on a question about drafts that go out unread: whether a message sent in someone's name should say so, the way a signature once carried p.p. for someone signing on another person's behalf. At acts the same question takes a different form, and it is easier to work on here, because the record already exists.
When the agent files a time-off request, the request belongs to the team member who asked. The audit entry says what changed and under whose identity. I have not settled whether the record should also say that an agent did the typing. My view is that it should, for a practical reason. The person working the approval queue is deciding based on what they believe the request is, and a reviewer who knows how it was made can check the parts that tend to go wrong for that route.
The reasoning carries outward. A reviewer inside the company can be told cheaply. A customer who receives something an agent did on our behalf is a harder case, and it is the one the disclosure question was really about. If marking the internal record is routine, there is a case for marking the external one too, scaled to what the agent did.
A logged note needs no mark. A message that goes out in our name probably does.
What we would like to hear
Think of one thing an agent in your business can change without asking anyone. Who wrote down that it may, and how would you put the change back if it were wrong? Post your answer in the comments. The ones that name a specific write and a specific undo are the ones we learn from.
Next week is decides, the rung where no one approves anything before it happens.