Plans

An ordered sequence, fired as many times as you need.

The eight clauses you said in one sentence, kept as eight runs in order. Readable before it runs, re-runnable after, and undoable as the execution it actually was.

The gap this closes. The quarterly cleanup is a real procedure that exists nowhere. It is a sequence somebody worked out once, performed by hand, and will work out again from scratch next quarter, slightly differently, with no record of what the last one did.

A plan is a definition. It holds an ordered list of runs, each one a tool with its scope, and it can be fired any number of times without being rewritten.

Runs can depend on each other. A run can be guarded on what an earlier run did, and a run can scope itself to the records an earlier run produced. So find the duplicates, then merge only what was found, then tell the owners of what changed is one plan rather than three jobs and a person in between.

Failure has a posture. A plan says whether a failed run halts the rest or lets it continue, because those are different decisions for a cleanup and for a nightly sweep.

The distinction

A plan is not a firing.

One is what you wrote. The other is what happened the time it ran. Keeping them apart is what makes a plan safe to run twice.

The plan

A definition. It answers whether this may run.

Ordered runs, each a tool with its scope
Guards that read what an earlier run did
A failure posture: halt, or continue
A schedule, if it should fire without a person
One state: active, superseded or archived

A firing

One execution. It answers what happened that time.

Its own record of every run and outcome
A skipped run is distinguishable from one that ran
Its own state: executing, executed, failed, stopped or cancelled
Its own reversal, addressed to this execution and not the plan

How it goes

From nothing to a record of what happened.

Compose. Describe the outcome in the Console, or author the runs directly.
Read it. Every run, its scope and its record count, before anything is written.
Confirm. The plan is stored. Nothing has run yet.
Fire it. On demand, or on a schedule expressed as a cron or rate, in a timezone you name.
Undo the firing. Reversal is addressed to the execution, so undoing last night's run does not touch the one before it.

Reversal

Undo is addressed to the execution, not the definition.

Which is the only way it can be correct for a plan that has run more than once.

A plan that runs nightly has fired thirty times this month. Asking to undo the plan is not a question with an answer. Asking to undo Tuesday's firing is, and that is the one the product accepts.

Each firing carries its own record of what its runs wrote, so reversing it restores exactly what that execution changed and leaves every other firing alone. A firing can be previewed before it is reversed, so you see what putting it back would actually do.

For agents

The same surface, over MCP.

Reads are free and need no permission to write. Anything that changes a record is a separate grant.

list_plans every plan on this tenant read

get_plan one plan, run by run read

preview_plan_reversal what undoing a firing would restore read

create_plan author an ordered sequence write

dispatch_run start a run the plan names write

The rest of it

How the pieces fit.

The Console: Describe the outcome in a sentence. Reads answer immediately, writes are held as a plan you confirm.
Runs: One saved, scoped operation. It owns the findings it produced.
Rules: The decisions a tool applies, saved apart from any run that uses them.
Tools: The eleven things a run can be, one per kind of drift.

Where to start

Start with what is already in there.

The readiness scan reads your CRM and reports what it finds, before you describe a single change.

Run a readiness scan Request a demo