New · September 2026
Action Recordand Tool Rules
Before the AI runs a command, writes a file, opens a page or touches a connected app, Plexon writes the call down. When it ends, it writes the result. The Record panel shows what ran, what it touched, how it ended and who asked for it, and a "Nobody watching" filter shows what happened while you were away. Beside every tool's On, Off and Blocked switch, a rule can refuse a call by what it is about to do.
Related features
Written Down Before It Runs
Every call goes through one record on its way to running: a row before, a row after. A row that cannot be written stops the call, so nothing runs unrecorded. If your disk is full, every AI tool waits until you free some space, and the message says so. That is the trade: the record is the road the action takes, not a report written beside it.
- Built-in tools and every connected app pass through the same record
- The row before says what is about to happen; the row after says how it went and how long it took
- A crash between the two rows leaves "no outcome recorded", not a guess
- Kept as a plain file on your computer, in your Plexon folder
Who Started It
Each row names who started the turn: you, a workflow, a dashboard, a reminder, a handoff from a teammate, the desktop pet, or Plexon itself. When Plexon cannot tell, the row says unknown. It never guesses a person. Pick "Nobody watching" and the panel shows only what ran while you were not there, unknowns included.
- Seven named starters, plus unknown
- "Nobody watching" is everything a person did not start
- A sub-agent's call carries that agent's name
- A workflow step or dashboard widget that named the tool itself is marked as a binding
- A row names its run: the workflow and the run, the dashboard and the widget, so one workflow's every run reads as one list
Reached From the Thing That Made the Calls
The Record has no icon on the side bar until you give it one. It opens from where the calls came from: the tool activity panel and the tools chip under the chat box open it whole; a workflow card, a dashboard card, an agent, or a running sub-agent opens it narrowed to itself, with one chip you can remove for everything. Export writes what you are looking at, filter included, as a file you can send with a bug report. Clear empties the record, asks first, and leaves a line saying how many rows went and when.
- Off the side bar by default; Settings or a right-click on the bar puts it there for good
- Scoped views: one workflow and every run of it, one dashboard and every widget, one agent, one chat
- Export as actions.jsonl: the rows on screen, in the order they ran
- Clear is all or nothing, so no single row can ever be edited out; the clear itself is written down
- A file read shows its paths and line counts, never the file, the same as the tool activity panel
A Rule Reads What the Call Is About to Do
A rule is one short expression over the call: the program about to run, the files it touches, the address of a web request, the connected app and whether the call reads or writes, and who started it. It lives in Settings, under Tools, in the Rules tab. A call that is not clearly a read counts as a write.
- any(files, .ext == ".env") refuses any touch of a .env file
- tool.server == "jira" and tool.effect == "write" keeps Jira read-only
- http.host endsWith "example.com" names one site
- initiator != "person" and tool.effect == "write" lets nothing write while you are away
- A misspelt field is an error when you save, not a rule that quietly never matches
Test It Against Your Own History First
Before you save a rule, run it against what has already happened. The report counts the past calls it would have refused and names up to fifty of them, each with the rule that decided it. Then switch the rules to dry run: they decide, the record shows what they would have refused, and nothing is stopped. Enforce comes last, once the dry run has been quiet for a while.
- Test against history runs on the unsaved draft
- Dry run records "would deny" and lets the call through
- Enforce refuses, and the AI is told which rule, why, and not to retry
- One judge runs in all three, so a test cannot disagree with the live rule
Deny First, Then Allow, Then Fail Closed
Deny rules run first, in order, and the first match refuses. Then allow: once you have written any allow rules, a call must match one of them, and a broken allow rule is not a match. A rule that cannot be read refuses and names itself. Rules apply to every starter, workflows and dashboards included; a rule that means to exempt a workflow says so in its own text.
- Deny before allow, always
- A rule with an error denies instead of silently passing
- With no allow rules, only deny applies
- Sits beside each tool's On, Off and Blocked switch, never instead of it
What It Is Not
It is a record and a rule, not a box the AI runs inside. A denied call is refused before it runs; a permitted one runs with the same access Plexon always had. Nothing in the record reaches the AI's instructions, so it adds nothing to a message. The one sentence the AI can read is the refusal on a denied call.
- Not a sandbox: it does not wall the AI off from your computer
- The record is bounded; the oldest rows go first, and the panel says how many were trimmed
- Values that look like passwords or keys are blanked before a row is written
- A power cut in the instant between the two rows can lose a line; that was chosen over slowing every call
Under the Hood
One Record, Two Doors
Every built-in tool and every connected app call reaches the record at the one place it actually runs, so a tool registered there is recorded with the rest.
Nobody Watching
One filter for what ran without you: workflows, dashboards, handoffs, the pet, and anything Plexon could not attribute.
Dry Run Before Enforce
Test a rule against your history, watch it in dry run, then enforce it. The same judge decides at every step.
Fails Closed
A rule that cannot be read denies. A row that cannot be written stops the call. An unknown starter is written as unknown, never as you.
Connects to
Nothing here works alone. See the whole map for how the pieces fit together.
What feeds it
App Connectors feeds this.
A call to a connected app is written down before it runs and again when it ends, with the app named on the row.
Dynamic Workflows feeds this.
Every tool a workflow step runs lands in the record with the workflow named as the one that started it.
Dashboards feeds this.
A widget's tool call lands in the record with the dashboard named as the one that started it.
Plexonaki feeds this.
What the pet does on its own is recorded with the pet named as the starter, and shows under Nobody watching.
Customization feeds this.
Tool rules are written in Settings under Tools, beside each tool's On, Off and Blocked switch.