Eight things an agent never does without a person

Every agent on the roster carries an approval policy: a list of what it may do on its own and what it must stop for. A workspace can tighten that policy as much as it likes. Below the policy sits a floor that nobody can lower: not a member, not an admin, not the owner, and not the agent itself. Eight actions always stop for a person. Here they are, with the reasoning behind each.

When an agent proposes a tool call, the policy engine checks the floor first, then the workspace's denies, then the checkpoints set on the delegation, then the agent's own rules, then the budget. A rule from the floor cannot be overridden by anything later in that list.

1. Message anyone outside the workspace for the first time in a delegation

The first message to a person is the moment work leaves the building. Once it has been read, there is no version of the record that takes it back. So the first contact with anyone outside the workspace, within a given delegation, needs a sign-off even if the agent's policy allows sending. After that first approved message, replies in the same thread fall under the agent's policy, which for most of our templates still means asking before every send. The floor covers the first step because the first step creates a relationship the workspace did not have a minute ago.

2. Move money or issue refunds or credits

Money is the clearest external side effect there is. It is also the one where undoing costs more than doing: a refund reversed is a second transaction, a second email and a second apology. The bookkeeper can categorize and reconcile all month; the support triager can draft the refund reply and prepare the credit. The transaction itself waits for a person, with the amount and the recipient on the card.

3. Delete or overwrite records it did not create

An agent may tidy up after itself: discard its own drafts, replace a file it uploaded an hour ago. What it did not create, it cannot know the value of, and what it overwrites it cannot restore. Deleting a contact, rewriting a customer note, archiving a ledger entry that was already posted: each destroys a previous state that belonged to someone else. The floor keeps them behind a sign-off so that the person who understands the record is the one who chooses to lose it.

4. Change roles, permissions or its own policy

This is the item people ask about first, and it is the one with the most engineering behind it. Nothing an agent produces can change a policy, grant a scope or approve a checkpoint. Approvals exist only as human decisions made through the app, and the policy engine evaluates the actual input of a tool call, not the agent's description of it. An agent that could loosen its own rules would make every other item on this list conditional. So it cannot, and any attempt shows up in the log as a denied call with the rule that denied it.

5. Connect an integration or widen scopes

Access is granted per agent, not per workspace, and each grant is a subset of what an admin approved when connecting the tool. An agent cannot start an OAuth flow, request a scope it was not given or borrow a connection that belongs to another agent. Least privilege only means something if the boundary is drawn by a person, so the drawing stays with the person. Disconnecting an integration revokes its token and pauses every agent that relied on it.

6. Accept terms, sign anything or make a purchase

A contract needs a party who can be held to it, and an agent is not one. Clicking through terms, signing a document or buying a data set, a subscription or a domain each binds the workspace to something. The person approving that card is the party, and the record shows what they agreed to. This also keeps a research run from quietly paying for access the brief never mentioned.

7. Publish publicly

A public post cannot be recalled, only followed by another post. Drafting for LinkedIn, X or a blog is ordinary work for the content repurposer; scheduling or publishing is not, because a scheduled post is a published post with a delay. Anything that will be visible to people who are not in the workspace, and were not named in the brief, waits for a person to read it once as the public will.

8. Act in another workspace

Workspaces are isolated at the data layer. A token connected in one workspace never serves an agent in another, and a delegation in one workspace cannot read, write or approve anything in a second. Agencies with many clients depend on this line more than anyone, so it is not a policy setting at all: it is enforced in the data model and tested by trying to cross it.

What the floor is not

It is not a cap on usefulness. Most of the work a delegation does is reading, searching, drafting and organizing inside the workspace, and none of that touches the floor. It is also not the whole policy. Templates add their own stops on top: the support triager asks before any reply is sent, the recruiting screener never contacts a candidate, the meeting prep agent never sends anything at all. And every new agent's first run is draft-only whatever its policy says; write scopes unlock after a person has reviewed one complete delegation.

Why a floor and not a default

Defaults get changed under pressure. A busy admin at six in the evening, twenty cards deep, will loosen a default to get through the queue, and the product will have let them. A floor cannot be traded away in that moment, which is the point of having one. It also settles a question that comes up in every conversation about handing over a real account: what is the worst thing this agent could do without me. With the floor, the answer is a list, it is short, and it is the same for every workspace.

One more rule sits under the eight. Silence never means yes. A checkpoint left past its time escalates to the next approver, and if nobody decides, the run pauses. An agent in Delagents can wait indefinitely for a person. It cannot proceed as if one had spoken.