Plexara
What you will take away from this lesson
A saved script runs. There is no approval step and no state in which a script exists but nothing may execute it: the version you saved is the version that runs, whichever of three triggers asks for it. This lesson covers the three, what each one records, and the guarantees a schedule makes about the runs it produces.
The runs in the two previous lessons were all asked for from a session. Here the same script gets a Monday morning cadence on the demo tenant, and the answer the platform gave when it was set is the shape of everything a schedule promises.
Learning Objectives
- 01Run a script from any session with one call, and read a long run’s result later by its run id.
- 02Run it from the script’s page, where Run and Dry run sit above the editor and one form built from the parameter contract serves both.
- 03Set a cadence in the portal’s builder or with the agent, in a timezone, and read it back in words.
- 04Use ${fire_date} and explain why the script has no clock of its own.
- 05State what a schedule guarantees: one schedule per script, one fire is one run, an overlapping fire is recorded as skipped, a gap produces one run for the latest fire, a failed scheduled run emails its owner and is never retried.
- 06Read the Scripts page, the Runs tab, and a script’s run history, and know why a script’s schedule lives in Plexara while a prompt’s schedule lives in the agent.
Where this lesson sits
The script from 602 writes the outputs from 603. This lesson is about what makes it run: the three triggers, the cadence that turns a script into an automation, and the record every run leaves. The next lesson covers the authority each of those runs carries.
600 Series: Automations
- 601Do not spend AI on what a script can doThe automation gap, what integration platforms and laptop scripts each cost, and the division of labor: a script for the deterministic part, the model for writing it and for judgment.
- 602The agent writes the first scriptThe loop from create to save, what validate and a dry run report, the dialect’s deliberate absences, the traps that fail a draft, and the script’s page in the portal.
- 603Outputs: feeds, reports, and dashboards that refresh themselvesOutput identity across runs, tables and documents, the semi-dynamic dashboard and its data region, the referencing pattern, version caps, and delivery to a bucket drop.
- 604Running it: by hand, from the portal, and on a scheduleThree triggers, the cadence builder, the pinned fire date, what a schedule guarantees, and the run history with every trigger, duration, output, and log.
- 605What a run may do, and the record it leavesThe authority a run carries, what a save refuses, why the language cannot reach out, the lifecycle, ownership and transfer, and the administrator’s view.
- 606Scripts as skills: the weekly review the agent runs on your businessThree scripts attached to one prompt, the agent running them and reading the outputs against the knowledge graph, and a weekly list of action items with the figures behind them.
The 600 series picks up the registered table from the 500 series and the prompt mechanics from the 400 series. It is the last numbered series in the curriculum.
Three triggers, one run
A run is asked for in one of three ways, and the run itself does not care which. The platform executes the latest saved version, as the script’s own principal, and records which trigger asked.
Three triggers, one run
From any session
trigger: toolAnyone the script is visible to, through the agent
You ask for it in plain language and the agent calls run_script with the script’s name and its parameters. The values are checked against the contract before anything is queued, and the call waits for the result.
From the script’s page
trigger: portalThe script’s owner, or an administrator
Press Run on the script’s page. The form is built from the parameter contract, so a date gets a date picker, an enum gets a choice, and a connection gets the set the script may reach.
On a schedule
trigger: scheduleNobody; the cadence fires it
A cadence, a timezone, and the values every fire binds. When it is due, Plexara runs the latest saved version with those values, whether or not anyone is connected.
The three execute identically. Every run executes the latest saved version as the script’s own principal, presenting the roles its author held at the save, and the only difference in the record is the label saying which trigger asked. A script taken out of service, disabled, deprecated, or superseded, is refused by all three in the same words.
Running one from a session
The common case is a person who wants the output now. You say so to the agent, the agent calls the script by name with the values it needs, and the answer comes back with the run’s record: the version that ran, how long it took, the outputs it wrote, and the log. The trace below is the first real run of the 602 script.
One run from a session, with the real answer
What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it.
run_script
name acme-supplier-margin
args {"month": "2025-12-01", "conn": "acme"}
wait_seconds 120
-> status succeeded
trigger tool
version 3
duration_ms 8542
run_id dpx_88dfb063…
outputs supplier-margin-by-category asset 871da875… version 1 (csv, 50 rows, 3,404 bytes)
supplier-margin-feed asset 589855b4… version 1 (json, 1 row, 27,660 bytes)
log supplier margin review for 2025-12-01 to 2026-01-01
categories quoted: 50, weighted cost change 2.57%
largest increase: Flowers & Plants 14.800%
at-risk SKUs under 20% projected margin: 25
coverage: 400 of 450 quotedThe call waits up to two minutes by default and at most five. A run that outlives its window keeps going: the answer carries the run id with a pending status, and the agent reads the result when it finishes with manage_script get_run. Asking for a run that should not wait at all queues it and returns at once. Either way the run executes on Plexara, so a long report does not hold the agent’s session open and a run in progress survives a platform upgrade.
Running one from the script’s page
The owner of a script runs it from the script’s own page, without an agent in the loop. Everything the run needs is already on that page: the saved code, a form built from the parameter contract, and the history the run will appear in.
Running from the script’s page
- 1
Run and Dry run sit above the editor
Run executes the saved version. Dry run executes what is on screen, as you, with tighter limits and nothing persisted. Both are on the page the owner already reads the script on.
- 2
One form serves both
The parameter form below the editor is built from the script’s contract: a date picker for a date, a choice for an enum, the set of reachable connections for a connection parameter. It supplies the values for a run and for a dry run alike.
- 3
The history re-reads itself
The run appears in the history under the code and updates as it progresses, re-reading while anything is pending or running and stopping once nothing is. A run may take ten minutes; the history is where it is followed.
A run asked for here and a run asked for by the agent are the same run in every respect except the trigger label. The page cannot widen anything: the run is authorized at every call against the roles captured at the script’s last save. And it cannot run what the platform would refuse, so a disabled or retired script says so instead of offering a button that cannot work.
The cadence
A schedule is what turns a script into an automation: a cadence, a timezone, and the parameter values every fire binds. It is set on the script’s page, in a builder that asks for the cadence the way a person has it in mind, or by the agent in one sentence. Both produce the same row, and the Scripts page states it in words either way.
Setting a cadence: the builder, or a sentence to the agent
- Hourly, daily, on weekdays, on chosen days of the week, or on a day of the month
- A time, and the timezone the time is read in
- The values every fire binds, checked against the parameter contract when the schedule is saved
- A Custom field for an expression the builder cannot express; an expression the agent wrote opens there as itself
What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it.
manage_script command=schedule_set
name acme-supplier-margin
cron 0 7 * * 1
timezone America/Los_Angeles
args {"month": "2025-12-01", "conn": "acme", "mode": "refresh"}
-> enabled true
cron 0 7 * * 1
timezone America/Los_Angeles
next_run_at 2026-08-31T14:00:00Z
missed_fires 0
message "The platform will run the latest saved version on this cadence,
with these parameters, as the script's own principal presenting
your captured roles."The portal asks for a cadence in the terms a person has it in and derives the expression, showing it rather than asking for it; the Scripts page then states it in words, as “Every Monday at 7:00 AM, America/Los_Angeles”. The agent sets the same thing with a cron expression or a descriptor such as @daily, and the answer above is what came back on the demo tenant. A cadence is read in its timezone, so a report stays on its wall clock across a daylight-saving change. A script has at most one schedule; setting it again replaces the cadence in place. Pausing and resuming are their own actions, and a schedule is never deleted, only disabled, so the runs it produced keep the row that explains them.
The date of the fire
A scheduled report almost always needs to know what day it is. The dialect deliberately gives a script no way to ask, and the schedule supplies the answer instead.
Pausing and resuming
A schedule is paused and resumed from the header of the Schedule section on the script’s page, or by the agent. Pausing is its own action rather than a field of the cadence, so resuming does not re-base the fire it resumes on, and nothing is ever deleted.
What a schedule guarantees
Seven rules govern the runs a schedule produces. They are what let you trust a number that arrived on a Monday morning nobody was watching.
What a schedule guarantees
- 01
One schedule per script
Setting it again replaces the cadence in place and keeps the run history that points at it. A second cadence over the same code is a second script.
- 02
One fire is one run
A fire produces exactly one run, however the platform is scaled underneath. Nothing about a fire is duplicated.
- 03
An overlapping fire is recorded as skipped
A fire arriving while the previous run is still going does not queue behind it. It is recorded as a skipped run, so the skip appears in the history rather than as silence.
- 04
After a gap, one run for the latest fire
When fires could not be materialized for a while, one run is produced for the most recent fire that has come due, and the fires before it are counted as missed on the schedule. A catch-up burst of stale reports would be worse than a visible gap; a backfill somebody wants is a run by hand with the parameters they want.
- 05
A paused schedule resumes on the fire it was parked on
While it is paused it reports no next run. The fire it resumes on collapses to one run under the same rule as a gap.
- 06
A failed scheduled run emails its owner
The mail carries the run id, the failure, and the tail of what the script printed. A run asked for by hand is not mailed, because its failure is already in the answer its caller is reading.
- 07
A failure is never retried
The same version on the same inputs fails the same way, so a retry would multiply the cost and change nothing. The fix is to correct the script, dry-run it, and save the correction. A run that could not start because of a platform fault, rather than a script error, is a different case and is retried on its own.
The record a run leaves
Every run, whichever trigger asked for it, records the same things, and the portal shows them at three levels: the Scripts page for the state of everything, the Runs tab for every run newest first, and a run’s own page for one run in full.
What one run records
- Trigger
- tool, portal, or schedule: which of the three asked for the run.
- Version
- The saved version that executed, which is the version that was latest when the run was queued.
- Duration and outcome
- When it started, how long it took, and whether it succeeded, failed, or was skipped as an overlap. A failure carries the error and the line it failed on.
- Outputs
- Each output by name, linking to the asset version it produced. An output delivered to a drop names where it was written instead.
- The log
- What the script printed, kept to 64 KB with the head preserved.
A year of run history is kept. A script’s page shows its most recent runs with a rollup in the header: the share that succeeded, how many failed or were skipped, and the median duration. The Runs tab shows every run across every script you own, newest first, with the reason a run failed in the row rather than behind it. The agent reads the same records with manage_script command=runs and get_run.
Why a prompt’s schedule lives in the agent and a script’s lives in Plexara
Lesson 404 said that scheduling a prompt is not a Plexara feature at all. This lesson has just described Plexara scheduling a script. Both statements are true, and the difference between them is the difference between the two kinds of saved work.
Scheduling a prompt, scheduling a script
- Who keeps the clock
- Your agent: an in-session loop, headless plus cron, a desktop task, a cloud routine.
- Plexara. The cadence is a row on the script, fired by the platform.
- What a fire needs
- A model. A fresh session starts, connects to Plexara, and runs the prompt by name.
- Nothing. No model, no session, no tokens; the platform executes the saved version.
- What varies between fires
- The model’s reading of the instruction, which is the point of a prompt.
- Only the data. The script contributes no variation of its own.
- Where the record lives
- In the asset the prompt saved, and the agent’s own session log.
- On the run: trigger, version, duration, outputs, log, kept for a year.
Lesson 404 explained why a prompt’s schedule lives in the agent: a prompt is an instruction, and running one needs a model to read it. A script needs none, which is why its schedule lives in Plexara and why the 606 capstone puts the two together: a schedule keeps the scripts’ outputs fresh, and a prompt tells the agent what to make of them.
From a run to its authority
Three triggers, one schedule, one record. The script on the demo tenant now fires every Monday at seven, refreshes its dashboard, and writes a run record nobody has to be awake for.
Key terms
Five terms cover how a script comes to run and what it leaves behind.
Key Terms
- Trigger
- Which of the three producers asked for a run: tool for run_script from a session, portal for the Run button on the script’s page, schedule for a fire. Recorded on the run; the three execute identically.
- Cadenceschedule
- A cron expression or a descriptor, a timezone, and the values every fire binds. One per script; set in the portal’s builder or by the agent; paused and resumed rather than deleted.
- Fire
- The moment a cadence comes due. One fire is one run. A fire arriving while the previous run is still going is recorded as skipped; after a gap, one run is produced for the latest fire.
- ${fire_date}
- The one token a schedule’s bound values may carry. It expands to the date of the fire in the schedule’s timezone and is recorded on the run, which is why the script needs no clock.
- Run record
- Trigger, version, duration, outcome, outputs linking to the asset versions they wrote, and the log. Read on the script’s page, on the Runs tab, and by the agent; kept for a year.