Plexara
What you will take away from this lesson
A procedure only pays off when it runs. A saved prompt runs two ways: at your keyboard, when you want the report now, and on a schedule, when you want it to arrive on a cadence without being asked. This last article covers both.
Running by hand is the common case and takes a sentence. Running on a schedule is a feature of your agent, not of Plexara: you point your agent’s scheduler at the saved prompt, and when it fires, a fresh session runs that prompt by name. Plexara stores the procedure; the agent keeps the clock.
Learning Objectives
- 01Run a saved prompt three ways: by naming it to the agent under any handle it knows, by picking it in the List Prompts app, and from the portal’s copyable invocation.
- 02Pass arguments at run time, and let the agent ask for any required value you leave out.
- 03Understand where scheduling lives: in your agent, not in Plexara. The prompt is a saved instruction; the agent is what runs it on a clock.
- 04Pick a scheduling mechanism your agent offers, from an in-session loop to a cloud routine that runs when your machine is off.
- 05Know that a scheduled run saves its result to the asset portal like any other run, then finish the job: a predictable name, a share that puts real email in front of the right person, and a look at the run counts that tell you the schedule is still firing.
Where this lesson sits
This is the capstone of the 400 series. The procedure has been authored, shared, and kept correct. All that is left is the part that produces value: running it, at the keyboard and on a cadence.
400 Series: Prompts as SOPs
- 401Prompts are the new SOPsThe difference between what your organization knows (memory and insights) and how one specialized job gets done (a prompt). When a perfect report is a recipe worth keeping, not institutional knowledge.
- 402Letting the agent write the promptThe agent that just did the work is the best author of the prompt that repeats it. It still holds the gotchas, the tool order, and the values worth turning into arguments. You review the draft, then save it.
- 403Sharing prompts, and closing the loop with feedbackHand a prompt to one teammate by email, or promote it to a whole role through the admin review queue. Then let feedback threads tell you what to fix, and fold the good corrections back into the catalog.
- 404Running prompts, by hand and on a scheduleRun a saved prompt at the keyboard three ways, or on a cadence using your agent’s own scheduling: an in-session loop, headless plus cron, a desktop task, or a cloud routine. Scheduling lives in the agent, not Plexara.
The 400 series builds on the prompt mechanics from 308. If the words prompt, argument, and scope are new, read that first.
Running one by hand
The common case is a person who wants this report now. There are three ways to do it, and they differ only in how you pick the prompt and hand over its arguments. The instruction that runs underneath is identical.
Three ways to run a saved prompt at the keyboard
Ask the agent by name
In any chat session, say "run the annotated sales review for Q2 2026, Southwest." The agent resolves that against your library with manage_prompt use, which accepts any handle you happen to have: the exact name, the display name, or a description of the one you mean. You never type a scope prefix. It substitutes the arguments you gave, asks for any required value you left out, and runs the resulting instruction. This works in every client, whether or not it has special prompt support.
Pick it in the List Prompts app
In a host that renders MCP Apps, asking to see your prompts opens the built-in List Prompts browser inside the conversation: search-as-you-type, collection and tag filters, and a detail view with a form generated from the prompt’s argument specs. Fill the form, press Run, and the rendered prompt lands directly in the chat. You type no instruction, and clients that draw no UI lose nothing, because the browser reads the same calls whose plain results those clients already get.
From the portal
The portal’s Prompts page is where you read a prompt carefully and check its arguments before committing to a run. Each prompt page carries a copyable invocation in plain language, built from that prompt’s stable name and its required arguments. Paste it into any connected client and you are back on the first path, with the name spelled the way the library stores it.
All three resolve the same record and substitute the same arguments. The only difference is how you pick the prompt and how you supply the values. A required argument you omit is not an error; the agent asks for it. Lesson 208 covers the resolution rules and the app itself in detail.
Running one on a schedule
When you want the report to show up on a cadence rather than because you asked, the scheduling does not happen in Plexara at all. Plexara stores the prompt; your agent runs it. Scheduling is a capability of the agent or client you connect to Plexara with, and capable agents already offer several ways to do it. When the schedule fires, a fresh session starts, connects to Plexara as usual, and runs your saved prompt by name.
The options below are Claude Code’s, which is a useful concrete example because it spans the full range from a quick in-session loop to a cloud routine that runs when your laptop is closed. If you use a different client, look for its equivalent; the shape is the same.
Where scheduling actually happens: in the agent
An in-session loop
Your machine, session openClaude Code’s /loop runs a prompt or slash command on a repeating interval while the session stays open. Best for quick polling during work; it stops when you close the session.
Headless plus cron
Your machine, no sessionRun the agent non-interactively (claude -p "run the annotated sales review for ...") and let your system cron or CI fire it on a clock. The scheduler is the operating system; each run is fresh and independent.
A desktop scheduled task
Your machine, app openThe Claude Code Desktop Routines page runs a saved instruction on a cadence (hourly, daily, weekly, or a custom interval) as a fresh local session. It persists across app restarts and fires while the app is open and the machine is awake.
A cloud routine
Managed cloudA routine runs a saved instruction on a schedule, or on an API call or a GitHub event, on managed infrastructure, so it fires even when your own machine is off.
These are agent features, not Plexara features. In every case the scheduler fires a fresh session, that session connects to Plexara the same way your interactive ones do, and it runs your saved prompt by name. Plexara never sees a clock. The four options above are Claude Code’s; see its scheduling docs for the details, and check your own client for the equivalent.
The output lands in the portal, the same as any run
A scheduled run is not a special case for output. Because the procedure ends by saving its result as an asset, the way the 402 example does, a scheduled run lands a dashboard or report in the portal like every other run, already viewable, shareable, and stored in your own bucket. The asset system from the 300 series is its home; there is no separate destination to wire up. What a run nobody is watching needs is a little extra on top, and most of it is one sentence in the prompt or one action in the portal.
Five things that turn a schedule into something people read
A report that arrives on a cadence and sits unopened is worse than no report, because you now trust a number nobody checked. These five close that gap. The middle three are recent: sharing an asset with a colleague mails them, with your note in the message, and the portal keeps a record of what was sent and how often each prompt has run.
What a run nobody is watching needs
A name each run produces the same way
Have the procedure name and tag its asset from a fixed pattern so successive runs sort next to each other instead of scattering across the library. The other good shape is one long-lived asset the run updates in place: the version history keeps every run, and a link you sent months ago still opens the current one.
A share, which is a real email now
Share the result with the colleague who needs it and Plexara mails them: your note quoted in the message, a link that opens the work, and a way in even if they have no account. This is the half of an unattended run that used to be yours to invent. Share the asset once and update it in place on a cadence, or share each run’s output as it lands, whichever suits how often you look.
A record of what was actually sent
Recent notifications, in your Settings, lists the notifications addressed to you with their subject, category, and delivery status, directly beneath the preferences that govern them. Delivery is the recipient’s call, not yours: a colleague on daily digest reads your share tomorrow morning, and one who turned shares off reads it never. Both look identical from your side, so ask about their delivery mode before you conclude the mail is broken.
A check that the schedule is still firing
A scheduled prompt that quietly stopped running looks exactly like one nobody needed. The portal’s Prompts page carries the evidence: every row shows a run count and a last-run age, sortable, and a prompt that has never run, or has gone 60 days unused, wears a badge naming that condition. A nightly report whose last run was three weeks ago is the schedule telling you it died.
A result the run refuses to save when it is wrong
Tell the prompt to flag an empty or out-of-range result rather than saving a broken report quietly. Nobody is in the session to notice, so the procedure has to do the noticing. One sentence in the prompt buys it.
Two of these live in the prompt (the naming and the guard), and three live in the portal (the share, the delivery record, and the usage columns). None of them is a setting to hunt for. Lesson 303 covers sharing, the note, and delivery preferences end to end.
The end of the series, and the start of the habit
The whole series points at one small, high-return change in how a team works with the agent: when a session turns out to be a procedure, save it as one. Everything else, authoring, sharing, feedback, scheduling, follows from that first act.
Key terms
Four terms close the series: the act of running a prompt, and the three pieces that turn a by-hand run into a scheduled one.
Key Terms
- Invocation
- Running a saved prompt: by naming it to the agent under any handle it knows, by picking it in the List Prompts app, or by pasting the portal’s copyable invocation into a session. All three resolve the same record and substitute the same arguments.
- In-session loop/loop
- Scheduling inside an open agent session. Claude Code’s /loop reruns a prompt or slash command on a repeating interval while the session stays open. Stops when the session closes.
- Headless runclaude -p
- Running the agent non-interactively so an external scheduler can fire it. Put claude -p in a system cron job or CI schedule; each run is fresh and independent.
- Scheduled task / routine
- A saved instruction the agent runs on a schedule on its own: a Claude Code Desktop task on your machine, or a cloud routine that runs on managed infrastructure even when your machine is off.