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: a draft run that records its calls, tests that replay the recording, the tests run, then the save, which is refused until the tests pass, reach the code, and read every output. 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 traps that fail a draft; typed parameters; and the script’s own page in the portal with its Flow, Source, and Tests tabs. 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, JSON, JSON-lines, or Parquet feeds, and can be registered as a table in the same call; a string body becomes a markdown, HTML, or JSX document; sheets become an Excel workbook. 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 with its cause and is never re-run on its own. And the run history that records every trigger, duration, output, result, 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 requires one format, work in main(), the structural rules, and tests that pass, reach the code, and read the data, and refuses a credential-shaped literal. A new version is replayed against recent successful runs, and one that changes what the automation does waits for the person’s agreement to a plain-language summary. The dialect has no network, no filesystem, no clock, and no imports beyond pinned libraries, so everything a script does is a platform call audited under the script’s own identity. The lifecycle, who sees what, state and checkpoints on a failed run, 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.
607 - Events in: a webhook source, its table, and an automation that reads it
How an event another system sends becomes a row an automation acts on. An administrator creates a webhook source in the portal; the sender proves itself with a signature, a token, or basic credentials, and a secret rotates without dropping an event. The sender is answered only after its events are stored, the events are queryable as one table from that moment, and each window is compacted into a de-duplicated Parquet file kept for the period the source’s page shows. The Webhooks page shows request volume, each source’s health, and every rejected request. And an automation on the demo tenant that keeps a watermark, so each run reads only what is new and neither misses nor double-counts an event.
608 - Results out: notification channels and signed delivery to other systems
How a result leaves the platform, to people and to systems. An administrator creates channels in the portal: an email list, a Mattermost channel, or an incoming webhook, the last two delivering through an API connection that holds the credential, so whoever may reach the connection may send. A person sends through the agent, an automation sends as itself, and an administrator sends a test. Every message is queued, shown in the delivery history, and retried on a fixed rule. A webhook channel in JSON format posts an envelope a system dedupes on and routes by, signed by its connection with the secret never in a script or a recording, and received on the demo tenant by a webhook source as one row per delivery.
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.