Propose & approve: let AI agents act without losing control
An AI agent that can change your data needs more than a kill switch. Here's the propose-and-approve broker model — per-action review, immutable audit, and a cost ledger — that lets agents do real work while a human stays accountable for every consequential change.
By Dmitrii SelikhovFounderReviewed by Planoda
Key takeaways
- Governing an agent means reviewing the action, not just gating who the agent is: a broker sits between the agent and your data and turns each consequential change — delete, bulk-update, mass-archive — into a proposal a human accepts or rejects before it touches anything.
- Per-action approval is stricter than per-agent permission: a per-agent grant trusts a whole role up front, while per-action review judges each individual change in context, so a normally-safe agent can't quietly do something destructive at scale.
- Every proposal, approval, and rejection lands in the same immutable audit log as human actions, so months later you can answer who or what changed a record and who signed off — the agent's work is as accountable as a person's.
- Pairing the broker with a per-workspace cost ledger means autonomy never becomes a runaway bill: spend is metered and visible per action, so you can let agents run on the safe long tail and still see exactly what every change cost.
The first instinct teams have when they hand real power to an AI agent is to look for the off switch. That's understandable, but an emergency stop is a blunt tool — it only helps after something has already gone wrong, and the thing you actually fear isn't the agent answering a question, it's the agent quietly deleting fifty records or reassigning a quarter's worth of work because it misread an instruction. The control you want isn't a switch you flip in a panic. It's a checkpoint the agent has to pass through every time it tries to change something that matters.
The broker sits between the agent and your data
The model that gives you that checkpoint is a broker — a thin layer the agent's actions are routed through before they reach the database. A read, or any harmless action, passes straight through. But the moment an agent reaches for a consequential, hard-to-undo operation — a delete, a bulk update, a mass archive — the broker intercepts it and turns it into a proposal instead of an execution. Nothing has happened to your data yet. What exists is a clearly described intent: here is the action, here are the exact rows it would touch, here is the agent that wants to do it. A human accepts or rejects it, and only an accepted proposal actually runs.
The key design choice is that destructiveness is a property of the action, declared once in a central registry, not something each agent or each surface decides for itself. That single source of truth is what makes the gate consistent: whether the request arrives through the app, an API, or an external agent over a protocol like MCP, the same actions are brokered the same way. There's no side door where a tool call skips review because someone forgot to wire the check on that path.
Per-action review, not just per-agent permission
It's worth being precise about why per-action approval is stronger than the more common per-agent grant. Per-agent permission is a decision made up front: you decide this agent is allowed to do these categories of thing, and from then on it does them unattended. That's fine for low-stakes work, but it trusts a role in the abstract — and an agent that's safe ninety-nine times can still be catastrophically wrong on the hundredth, at a scale no human would reach by hand.
Per-action review judges the individual change in its actual context. The question shifts from 'is this agent allowed to delete things in general' to 'should this specific delete, of these specific records, right now, go through.' It's the difference between trusting an employee with a corporate card and approving each wire transfer over a threshold. You can still auto-approve the safe long tail; the point is that the consequential actions surface for a human, every time, with the full blast radius shown.
Immutable audit and a cost ledger
Approval only matters if you can reconstruct it later. So every proposal, every approval, and every rejection writes to the same immutable audit trail that records human actions — not a separate, weaker agent log off to the side. Months after the fact you can answer the questions that actually come up in a post-mortem or a compliance review: what changed, which agent proposed it, who signed off, and when. The agent's work carries the same accountability as a person's because it lives in the same record.
The second ledger is financial. Autonomy that isn't metered becomes a bill you discover at the end of the month, so each brokered action is also costed against a transparent per-workspace ledger. That's what makes it safe to let agents loose on the long tail of small tasks: you can see spend per action as it happens, not as a surprise. Governance and cost are the same discipline viewed from two angles — knowing exactly what an agent did, and exactly what it cost.
What this looks like in practice
Put the pieces together and the experience is calm rather than fearful. Agents triage, draft, and update freely on everything reversible. When one reaches for something destructive, you get a proposal with the full scope laid out, you approve or decline in a click, and the decision is permanently on the record. You're not babysitting a black box and you're not blindly trusting one either.
This is the axis Planoda built on rather than bolted on. Every destructive agent action — through the app or through the MCP path for external agents — becomes a propose-and-approve proposal, recorded in the same immutable audit log as people and metered on a per-workspace cost ledger, with destructiveness driven by one central tool registry so no path escapes the gate. The agent is a teammate with real authority and a real paper trail, which is the only way to give one power you can actually live with.
Sources
- Introducing Linear Agent — Linear Changelog (Mar 24, 2026)
- Notion just turned its workspace into a hub for AI agents — TechCrunch (May 13, 2026)