Plans and governance

A Plan is an agent’s proposal, attached to a record, that a human decides on before anything happens. It lists the steps the agent wants to take, and you inspect, refine, approve, or reject it. Only after approval do the steps execute. By default you decide a plan inline in the plan review. If you want a formal sign-off chain instead, you opt a plan into an Approval Policy. Either way, an agent’s proposed change waits for a person.

When you’d use it

Review an agent’s proposed change before it touches a record.
Refine or reject what an agent suggests rather than accepting it wholesale.
Require a formal approval chain for plans by opting them into a policy.
Constrain an agent to only the kinds of change it is meant to propose.

What you manage

You review plans on the agent’s run in the Agent Designer (AI → Agents, /admin/agents), where a proposed plan appears with an approve or reject decision. To govern plans with a formal chain, create an Approval Policy that names fl_plans in its target tables.

What a plan may contain is not a setting you type. It follows from the agent’s reach: a record write goes through the Platform records door and is narrowed by the writable fields set under Autonomy and output, a REST call goes through a connection the agent is allowed on the External systems door, and the platform-only steps (configuring a capability, granting a tool) are never an agent’s to propose. Every other kind of step can be proposed, and the approver decides. The Guardrails view lists the result as an enforced row named Plans may contain, and a step outside it is refused before the plan exists.

Good to know

A record write is shown as the change, field by field. For a write to the record you are on, each field the step touches is listed with its value now and its value after approval, so you approve what you can see. A write to another record, or a create, lists the proposed values and says that current values are not shown.
A record write that the table’s own validation rules would refuse is refused when proposed. If a rule says a resolved incident needs a resolution code, a plan that sets the state without the code is not created: the session is told the rule’s message and proposes again with the code in the same step. Nobody approves a plan that would fail on that rule. A rule written as a script still runs only when the plan executes.
A record write that moves it to a state demanding another field is refused when proposed, not after you approve it. If In Progress requires an assignee, a plan that sets the state with nobody assigned is not created: the agent is told which field by name and proposes again with it included, or with the record’s existing value, in the same step.
A record write that would leave the assignee outside the assignment group is refused when proposed. If a plan routes an incident to a group the current assignee is not a member of, it is not created: the session is told the group and the person by name and either clears the assignee in the same step or asks you to add them to the group first. Nobody approves a plan that the membership rule would refuse when it runs. The rule itself does not change: an empty group is valid configuration, and a person is never added to a group by a plan.
A record another system owns is not changed by a session. While a record is still owned by the tool you are migrating from, a plan that writes to it is refused when proposed, and the session’s own update and delete tools refuse it too. Ownership is set per record on the Migration page.
A plan that changes nothing outside FlowLakes is decided inline unless a policy names fl_plans. A record-table policy never picks up plans by accident.
A plan that changes an outside system is never decided inline. It is governed by the approval policy that matches its risk level, and if no policy matches it is refused when proposed, with the level and the connection named. Every tenant carries a platform ladder for this: three policies named Governed external changes, one per risk level (low: one approver; medium: one approver, and the manager of the person the change is about is told; high: every listed approver). They arrive at the first sign-in after the platform update, name the tenant’s administrators, and you edit who approves on the Approval Policies page. A connection can carry its own policy for one or more levels, which takes precedence.
Once a policy governs a plan, the inline decision is refused and the decision flows through the policy instead. An edit to a governed plan may not change which policy would decide it; reject and propose again instead.
A plan reaches one connection at a time. Propose changes to a second system as a separate plan.
The doors decide what a plan may contain. A REST step needs a connection the agent is allowed to use, a record write is narrowed by the writable fields, and the approver decides the rest. There is no separate allow-list of step kinds to maintain.
An empty plan (zero steps) is valid. An agent can declare fields to set on the record for that case, such as parking it for review.
A plan step can write words, not only fields. An agent can propose a work note (visible only to staff) or a comment to the person who raised the record, posted once the plan is approved. A proposed public comment still passes the same visibility check a human-posted one does: if the agent’s own reading touched something that person cannot see, the comment is held as an internal note instead, and the plan’s result says so.

Earned autonomy

An approval policy can let a plan through without a person, once the same change has been shown to work several times. You switch that on per policy, name the steps it may cover, say how many times in a row, and name the person whose permissions an unattended plan runs under.

What counts as evidence is narrow on purpose. A plan counts only when a person approved it, it finished, and every change it made outside FlowLakes was read back afterwards and found. A plan that failed, one still running, and one whose change could not be confirmed count for nothing. A rejected plan of the same shape resets the count to zero.

Evidence is also tied to exactly what was approved. It is counted per agent, per connection and per operation, so approvals of one operation never arm another. If the operation is edited on the connection, or the approval policy itself is edited, the count starts again from zero: the approvals were about the older wording. And evidence from ordinary work does not stretch: approvals of a small, ordinary change never arm a change to a protected or large target, or one covering more items than the approved plans did. Those still go to a person.

When something goes wrong, the delegation is suspended. That happens when an unattended plan fails, when its change cannot be confirmed afterwards, or when the ground moves between approval and execution (the risk level rises, or the approval policy is changed or switched off). A suspension is shown on the Approval Policies page with the connection, the operation and the reason. It stays in force until somebody reviews it: open the policy, read the suspension, and select Mark reviewed. Nothing else clears it, and a fresh approval on its own does not.

How it connects

A Plan is the proposal and its governance; it does not execute itself. Execution is a separate step that runs once a plan is approved. Who approves is owned by Approvals, and what an agent may propose at all is bounded by the Safety model. A plan’s lifecycle moments are observable through Triggers and events.

Review and approve a plan in the agent-designer guides.
Govern plans with a policy in the admin guides.
Exact shapes: plan table fl_plans (target record, steps, status, governing policy); governance is opt-in via naming fl_plans; every term in the glossary.