Plexara
Automations
601 - Do not spend AI on what a script can do
The report that gets rebuilt every Monday spends tokens on logic that was settled weeks ago and drifts a little each time. Integration platforms automate well but need a platform expert, so a one-off analysis never crosses that bar; an agent on a laptop writes scripts that vanish with the session. This lesson sets out the division of labor the series runs on: a script for the deterministic part, the model for writing it and for judgment about what it produced, and a managed script as the thing Plexara keeps, versions, runs, and schedules.
602 - The agent writes the first script
From a solved session to a saved script, with the loop the agent works through: create, validate, dry-run, patch, validate, dry-run, save. What a validate report says about the tools, connections, and destinations a script reaches; what a dry run measures without persisting anything; the dialect’s deliberate absences and the three traps that fail a draft; typed parameters; and the script’s own page in the portal with its source, Validate, Dry run, and versions. Grounded in a real script that reads the 500 series’ registered table.
603 - Outputs: feeds, reports, and dashboards that refresh themselves
What a run produces and where it lands. One script and one output name is one asset, and every run adds a version; a dated name builds an archive instead. Rows become CSV or JSON feeds; a string body becomes a markdown, HTML, or JSX document. A semi-dynamic dashboard is published once and has only its data region refreshed on later runs, so layout edits made in the portal survive. A dashboard can instead reference a file a script rewrites, capped versions keep an asset tidy, and a named bucket drop delivers the same bytes to another system.
604 - Running it: by hand, from the portal, and on a schedule
Three triggers, one run. From any session with a single call, from the Run button on the script’s page where the form comes from its parameter contract, or on a cadence set in the portal’s builder or by the agent, in a timezone, with the fire date pinned onto the run. What a schedule guarantees: 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. And the run history that records every trigger, duration, output, and log.
605 - What a run may do, and the record it leaves
A run presents the roles its author held at the save, every call is authorized at that moment, and narrowing the persona takes effect on the next run. A save refuses a credential-shaped literal and source that does not parse. The dialect has no network, no filesystem, and no clock, so everything a script does is a platform call audited under the script’s own identity. The lifecycle from active to disabled, deprecated, and superseded; who sees what; ownership and an administrator’s transfer; and the administrator’s view of every script and every run.
606 - Scripts as skills: the weekly review the agent runs on your business
The capstone. Three scripts (category velocity, the supplier quote margin review, regional weather context) attached to one prompt, so serving the prompt carries each script’s contract and last successful output and the agent runs them for fresh numbers instead of re-deriving them. The agent then reads the outputs against the seasonality calendar, the returns policy, the store formats, and the stock health bands, and produces the week’s action items: promote, discount, discontinue or renegotiate, watch, each with its figure. The scripts did the data work; the model did the judgment; neither is rebuilt next week.
500 · Spreadsheets as Tables
A file somebody receives by email becomes a table every agent on the team can join against the warehouse, and stays current month after month.
Up nextInsights
Editorial pieces on architecture decisions, comparisons against the alternatives, and where this market is going. Read in any order.