Runs

One tool, one scope, and the findings it owns.

A run is a saved object rather than a button you pressed once. It knows which records it covers, which rules it used, and what it found.

The gap this closes. Bulk operations in a CRM are anonymous. You select some records, you act, and afterwards there is nothing that says what was done, to which records, under which rules, or by whom. The only evidence is the damage.

A run names two things: the tool it uses, and the records it covers. The scope is a filter over your own fields, the same builder every tool uses, with a count you can read before you commit.

A run owns its findings. The duplicate groups a deduplication run detects belong to that run. Two runs over overlapping records produce independent findings rather than fighting over the same ones, so you can scope narrowly, review, and scope again without losing work.

Re-running is not starting over. A second pass refreshes the findings nobody has decided on yet and preserves the ones you already approved or rejected. The decisions you made are the expensive part and they survive.

The distinction

Two words worth keeping apart.

Most tools use these interchangeably. Here they are different objects, and the difference is what makes a run re-runnable.

A run

The saved thing. It persists, it is listed, and it can be run again.

Names a tool and the records it covers
Owns its findings independently of every other run
Keeps your decisions across re-runs
Can be deleted when you are done with it

A pass

One execution of that run. A run may have many.

Reads the scope as it stands right now
Applies the rules as they stand right now
Writes what changed and skips what did not
Records what it wrote with the value before it

How it goes

From nothing to a record of what happened.

Choose the tool. Eleven tools, each correcting a different kind of drift.
Scope it. A filter over your own fields, with a live count of what it selects.
Decide who releases it. Run on dispatch, hold the whole run for one approval, or queue one proposal per record.
Dispatch. The pass runs, writing only what actually differs.
Read it back. The run keeps its records, its counts and its outcome, and stays listed.

Disposition

Who releases the writes is a property of the run.

Not a global setting, and not a decision the tool makes for you.

The same tool can be fully automatic on one scope and fully supervised on another, because the choice belongs to the run rather than to the tool. A normalization run over a scope you trust writes on dispatch. The same tool over the book you just inherited holds every record for review.

Three postures: execute writes when dispatched, queue holds the whole run behind one approval, and propose computes everything, writes nothing, and puts one reviewable proposal in the queue per record it would have changed. A credential may ask for either form of review and may never release it.

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_runs every run on this connection read

get_run one run, with its scope and outcome read

get_run_records the records a run touched read

create_deduplication_run one of eleven create tools, one for each write

dispatch_run start a pass write

delete_run remove a run you created 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.
Rules: The decisions a tool applies, saved apart from any run that uses them.
Plans: An ordered sequence of runs, fired on demand or on a schedule.
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