Plexara
What you will take away from this lesson
The 500 series ended with a supplier price sheet that is a table, a join that works, and a dashboard the merchandising lead reads. Next month the sheet arrives again, and the month after. Each time, somebody opens a session and asks the agent for the same join, the same cast, the same margin figure, and the agent works it out again from the beginning.
That is the gap this series is about. The logic was settled the first time; every later run spends tokens re-deriving it and produces a slightly different answer. The fix is not to stop using the agent. It is to let the agent write the script once, and to let Plexara run the script from then on.
Learning Objectives
- 01Name the automation gap: settled logic re-derived on every run, at a token cost, with a little drift each time.
- 02Describe what an integration platform costs in expertise, and why a one-off analysis never crosses that bar.
- 03Explain why the scripts an agent writes on a laptop are lost, and what that loss costs a team.
- 04State the division of labor: a script for the deterministic part, the model for writing the script and for judgment about its output.
- 05Define a managed script: authored in a session, executed unattended, versioned, governed, run by Plexara on demand or on a schedule.
- 06Place scheduling correctly: a prompt is scheduled by your agent because it needs a model; a script is scheduled by Plexara because a run needs none.
Where this lesson sits
The first lesson of the 600 series, and the argument the other five rest on. It assumes the 500 series: the supplier price sheet is registered as a table, the agent knows what its columns mean, and the margin join has been worked out once.
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.
The report that gets rebuilt every Monday
Automation has always been the hard part of putting AI on a data system. The first session is worth its cost, because that is where the judgment happens: which tables, which definitions, which corrections. The problem is every session after it. The same logic is re-derived from a description, at model speed and model cost, and it comes out a little different each time.
The report that gets rebuilt every Monday
The first session
An hour of real work: finding the right tables, agreeing what margin means, casting the text columns, correcting the first draft. Worth every token, because the judgment happened here.
Every Monday after
The same queries, re-derived from a description of them. The join is rediscovered, the cast is rediscovered, the threshold is guessed at again. Ten minutes of model time on logic nobody needs to think about.
The drift
Week three rounds differently. Week five picks a different threshold. Nobody can say which Monday’s number is comparable to which, because no two runs executed the same procedure.
The insight The report that runs without the agent makes the argument at length. This series is the workbook: how the script gets written, what it produces, how it runs, and what it is allowed to do.
Three ways a recurring job gets done
There have been two answers to this for years. An integration platform automates the job properly, but it is built and kept by a platform expert, so the analyst files a request and the one-off analysis never becomes a flow. An agent on a laptop does the job in a session, but everything it built is gone when the session ends. A managed script is the third answer, and the ledger below is what it keeps from each of the other two.
Three ways a recurring data job gets done
- Who builds it
- Integration platformA platform expert who knows the flow builder, its connectors, and its failure modes. The analyst files a request and waits.
- Agent on a laptopThe agent, in a session, on the analyst’s machine, against a file it was given a path to.
- Managed scriptThe agent, in a session, from the work it just did. The analyst reviews the draft and the dry run.
- Where it runs
- Integration platformOn the integration platform, with credentials it holds for each system it touches.
- Agent on a laptopOn the laptop, under the person’s own credentials, only while the session is open.
- Managed scriptOn Plexara, as the script’s own principal, presenting the roles its author held at the save.
- What survives the session
- Integration platformThe flow, once somebody has built and tested it.
- Agent on a laptopNothing. The scripts were temporary files; the next session starts from a description.
- Managed scriptThe script, every version of it, every run’s record, and every output as a versioned asset.
- Who can see it
- Integration platformThe platform team. The analyst sees the output, if it was wired to a place they look.
- Agent on a laptopOne person, on one machine.
- Managed scriptThe owner and administrators see the script; anyone the output is shared with sees the output.
- What it can reach
- Integration platformWhatever the connectors were configured for, with the credentials the platform holds.
- Agent on a laptopWhatever the person’s credentials reach, with no record of what was reached.
- Managed scriptExactly the connections and tools its author may use, checked on every call, recorded in the audit log.
- Cost per run
- Integration platformZero model time; the setup is the cost, and it is paid in weeks.
- Agent on a laptopA full session of model time, every time, plus the person’s attention.
- Managed scriptZero model time. A run takes seconds and no agent has to be connected.
Workato, n8n, and Apache NiFi are the integration-platform category, and they automate well once a flow exists. The problem is the bar: a flow is built by somebody who knows the platform, so a job that only an analyst and their agent understand never gets one. The managed script keeps what the platform offers (it runs unattended, under held credentials, with a record) and drops the bar to the session that already did the work.
What vanishes on a laptop
The laptop answer deserves its own look, because it is what most teams are doing today and it feels productive while it happens. A person hands the agent a 100 MB CSV, the agent writes scripts to parse it, and an hour later there is an answer. Four things were true of that hour that nobody noticed.
What vanishes when the agent works a file on a laptop
The file lives on a laptop
A 100 MB CSV does not fit an agent’s context, so the agent needs the file on local disk and permission to read it there. The data never reaches anywhere a teammate could reach it.
The scripts are temporary
To parse the file the agent writes scripts, runs them, and discards them. Next week’s file starts from a description of what the scripts did, not from the scripts.
It ran as the person, with no record
Whatever the scripts reached, they reached with the person’s own credentials, and nothing recorded what was read or written.
The team gets nothing
No output anyone else can open, no procedure anyone else can run, no history to compare against. The work was real and it evaporated.
Upload the same file to Plexara and let the agent write the script there instead, and every one of these reverses: the file is in the library with a description, the script is saved and versioned, the run is recorded under the script’s own identity, and the output is an asset the team can open. Next week the new file is uploaded and the script is run, by a click or by asking.
The division of labor
The series runs on four rules. They are not about using the model less. They are about pointing it at the part of the job only a model can do, and letting a script do the part a script does better.
The division of labor
- 1
Do not spend AI on what a script can do.
Extracting, joining, computing, calling an API, and delivering a file are deterministic. A model doing them is slow, costs tokens, and drifts. A script does them the same way every time.
- 2
Do not write a script when the agent can write it.
The agent that just solved the problem in a session holds the tables, the casts, and the corrections. Writing the script is a sentence to it, and a review from you.
- 3
Spend the model on judgment about the output.
What the numbers mean for the business, given what the organization knows, is the part only a model can do. Point it at the script’s output and the knowledge graph, not at the raw tables.
- 4
Keep the scripts, the prompts, and the knowledge.
A saved script, a saved prompt that runs it, and a knowledge page the review cites mean every session starts further along than the last one.
What a managed script is
A managed script is the unit this series is built around. Six facts about it are enough for now; the lessons that follow fill each one in.
What a managed script is
- A small language
- Scripts are written in Starlark, a Python-shaped dialect with no imports, no clock, no network, and no filesystem. Everything a script does is a call to a Plexara tool, so what it reaches can be read from its source.
- Authored in a session
- The agent drafts it from the work it just did, validates it, dry-runs it against real data with nothing persisted, and saves it. The saved version is the version that runs.
- Runs as itself, with your reach
- A run executes as the script’s own principal, presenting the roles you held when you saved it. It can never do unattended what you could not do at the keyboard.
- Versioned and recorded
- Every save is a version with an author. Every run records its trigger, duration, queries, outputs, and log, and a year of that history is kept.
- Run by Plexara
- On demand from any session, from the Run button on the script’s page, or on a schedule in your timezone. No agent has to be connected for a run to happen.
- Outputs are assets
- A CSV feed, a JSON feed, a markdown report, or an HTML dashboard, each a versioned asset in the portal with the same sharing every asset has.
The product page Automations describes the same thing in a page. The next five lessons take it apart: authoring, outputs, running, authority, and the review that composes several scripts into one job.
Where the schedule lives
The 400 series drew a line worth restating here, because scripts sit on the other side of it.
What the rest of the series covers
The agent is the developer during the session and the analyst afterward, and it gets better at both with every session, because the scripts, the prompts, and the knowledge persist. The next lesson starts with the developer half.
Key terms
Five terms carry through the series: the script itself, a run of it, a version of it, the schedule that fires it, and what a run produces.
Key Terms
- Managed script
- A small Starlark program the agent writes in a session and Plexara stores, versions, runs, and schedules. It reaches only Plexara tools, and only the ones its author may use.
- Run
- One execution of a script’s latest saved version, by a call from a session, by the Run button on its page, or by a schedule. Each run records its trigger, duration, queries, outputs, and log.
- Version
- What a save creates. Each version carries its author and the roles a run of it presents. The latest saved version is the one that runs.
- Schedule
- A cadence, a timezone, and the parameter values every fire binds, set on the script. A script has at most one, and Plexara fires it.
- Output
- What a run writes: a CSV or JSON feed, or a markdown, HTML, or JSX document, each a versioned asset in the portal under a name the script chose.