Action Policies and Approvals

The seven categories

Send messages and email — anything that reaches a person, inside or outside Kavanah. The category most workspaces keep tightest, because it cannot be undone.

Move money and change the books — payments and transfers, the invoice and bill lifecycle, ledger and journal entries, cap-table changes. Note the boundary: the reference data around finance (customers, vendors, GL codes) is not this category, it is 'write to connected tools'.

Delete and disconnect — irreversible deletes, and disconnecting integrations.

Membership and access — deactivating members, removing project or portal access.

Deploy and run external workflows — triggering deployments, executing external automations.

Write to connected tools — creating and updating records in third-party systems like Jira, Notion or Sheets.

Spend AI usage — actions whose cost is model calls rather than an effect on the world. Convening an exec meeting is the clearest example; so is arming a recurring autonomous run. This category exists because none of the other six describes 'this burns credits', and without it those actions would be misfiled under external writes and governed by a policy whose label would be a lie.

The four modes

Allow — the agent may do it without asking. Correct for categories where you have watched enough instances to be confident and where a mistake is cheap.

Allow up to a daily budget — permitted, capped per day. This is the underused middle setting and often the right one: it lets routine volume through while bounding the damage from a runaway loop. Particularly apt for AI spend and for external writes.

Approve — parked for explicit per-action approval. This is the default, and it is what you want for anything irreversible until you have evidence otherwise.

Block — never, regardless. For categories your organization simply does not delegate.

Set them per category rather than globally. The whole point of having seven categories is that 'write to Jira' and 'move money' deserve different answers.

Working the queue

Parked actions surface as agent alerts — in the notification centre and in the dashboard right rail. Each shows what the agent intends to do and why.

The habit that keeps this from becoming a chore is to work it at a fixed time rather than reactively. Once in the morning and once after lunch is enough for most workspaces, and it caps the latency at a few hours.

What kills the mechanism is a stale queue. An approval that sits for three days teaches everyone that asking the agent to do something means it will not happen, and they stop asking. If your queue is regularly stale, that is not a discipline problem — it is evidence that a category is over-tight and should move to a budget.

And note the diagnostic value: 'the agent didn't do it' is most often an action sitting in this queue. Check here before assuming anything is broken.

Loosening on evidence

The queue is a dataset about your own decisions. Use it.

After a few weeks, look at what you approved. A category where you approved every single instance without hesitation is a category where the approval step is adding latency and no safety. Move it to a budgeted allowance — not to unrestricted allow, because the budget is what protects you from the failure mode approvals were really guarding against, which is volume rather than any single action.

A category where you rejected anything at all stays at approve. One rejection is enough; the whole value of the step is that it caught something.

And revisit after a change in circumstances — a new integration, a new persona, a new class of work. A policy tuned for last quarter's workload is a policy tuned for a different agent.

One thing that never loosens

Some actions are irreversible in a way no policy can soften. A sent email is sent. A deleted integration credential is gone. A triggered deploy has deployed.

For these, the approval step is not a formality you graduate out of — it is the only control that exists, because undo does not apply. Workspaces that eventually run most categories on budgets still keep external sends and destructive actions on approve, and that is a reasonable permanent end state rather than a failure to progress.