What you will take away from this lesson
Article 306 covered the backward-looking question: how was this asset built. This article is the forward-looking version: how do I run that work again next month, next quarter, or for a different region, without re-typing the same instructions every time.
Plexara's answer is a first-class prompt object. The agent has a tool, Manage Prompts (manage_prompt), that lets you save an instruction as a template with named arguments, then call that template later by name. A saved prompt is a starting instruction, not a script. The agent still decides which tools to invoke when it runs the prompt, and the world has moved on since the last run. So this lesson covers what the prompt object actually is, how to write one that holds up, and where the honest limits of reproducibility are.
Learning Objectives
- 01See the Plexara prompt system for what it is: a way to save a reusable instruction template, with named arguments, that you or a teammate can run later with different values.
- 02Use Manage Prompts (manage_prompt) to create, list, get, update, and delete personal prompts from inside a chat session, the same way you already use the other tools.
- 03Read the shape of a prompt record: name, description, content with {arg} placeholders, arguments list, scope, owner.
- 04Pick the right scope for a prompt: personal for drafts, persona for role-based playbooks, global for team-standard workflows. Know which scopes you can set and which require an admin.
- 05Set honest expectations: running a saved prompt re-reads your template and hands it to the agent. It does not replay a session, does not pin the data, and does not force the same tool choices.
Where this lesson sits in the curriculum
306 covered the audit trail attached to an asset after it was built. 308 covers the input side: the saved prompt that started the session, and how to re-run it without re-typing it.
300 Series: getting more out of Plexara
- 301Creating reports and dashboardsHow to ask the agent for shareable work product instead of chat that scrolls away. The habits that decide whether your dashboard survives next week.
- 302Exporting dataWhen you need a spreadsheet a teammate can sort, or a data file for another system, instead of a view.
- 303Sharing your workTwo ways to share: a user share to a named teammate, or a public link anyone with the URL can open. Three controls on either: expiration, notice text, revocation.
- 304Creating collectionsBundle a dashboard, a summary, and the underlying data into one navigable briefing. Build it during the session via the agent, or by hand on the portal's Collections page.
- 305Editing what you already haveUpdate an asset in place so shared links keep working and history stays on one record. Metadata edits do not bump the version; content edits do; revert is append-only.
- 306How an asset was builtThe audit trail Plexara records at the MCP boundary: which tool calls the agent invoked, with what parameters, in the producing session. Captured at save time, readable by you or the agent.
- 308Reproducible promptsSave the starting instruction as a first-class prompt with named arguments via Manage Prompts (manage_prompt). Re-run it later with different values. Personal, persona, or global scope. What re-running does and does not guarantee.
The 300 series is practical recipes for working with Plexara day to day. It assumes the mental model from 205.
Why a saved prompt earns its keep
Three reasons cover most of the value. They are not abstract: each one tracks a habit that costs time and quality the moment a team's workflow becomes recurring.
Why a saved prompt earns its keep
Stop re-typing the same starting instruction
If you run a monthly close, a weekly pipeline review, or a quarterly board briefing, you have already typed roughly the same five-paragraph prompt into the agent a dozen times. The drift between this month and last month is real: a phrase you tightened the second time, a constraint you forgot the third time. Saving the prompt once means everyone (including future you) starts from the version that already works.
Change the variables, not the words
Most repeated work changes in small, named ways: a different quarter, a different region, a different customer segment. A saved prompt declares those as arguments. The agent reads the template, substitutes the values you pass, and runs the prompt with this quarter's numbers without you having to rewrite the surrounding language.
Make the working version the team version
When you have a prompt that produces good board-grade output, the second-most useful thing you can do (after running it) is hand it to your team in a form they can run themselves. A prompt scoped to your persona or shared globally shows up in everyone's prompt list with the same arguments and description you wrote.
The shape of a prompt record
A prompt is a small structured record with seven fields you usually touch and a few more the platform fills in. Knowing the field names makes the rest of the lesson easier, because the agent talks about them by name and the portal surfaces them in the same way.
The fields of a prompt record
name- Machine-friendly identifier. Lowercase letters, digits, hyphens, and underscores; up to 128 characters. The agent looks the prompt up by this name. Pick something stable; you'll be typing it.
display_name- Human-readable title for the same prompt. Shown in the portal's prompt list. Free-form; can include spaces and punctuation.
description- One-line summary of what the prompt does. Shows up in listings; the agent uses it to decide whether the prompt is the right one to run for a given request.
content- The template itself. Plain text with named placeholders in {curly_braces} or {{double_curly_braces}}. At run time, Plexara substitutes the argument values you pass.
arguments- The named placeholders, each with a name, a description, and a required flag. The agent uses the descriptions to know what to ask you for if a value is missing.
scope- Who can see and run the prompt: personal (you only), persona (users assigned to a matching role), or global (everyone in your Plexara). Personal is the default; the others require an admin.
owner_email- The authenticated user who created the prompt. Set by Plexara from your session, not from input. This is what gates the 'only edit your own' rule on personal prompts.
A prompt also carries timestamps (created_at, updated_at), an enabled flag (so admins can park prompts without deleting them), and an ID. Those are set by the platform.
Arguments: the part that changes between runs
The single feature that turns a prompt into a reusable template is the named argument. Inside the content field, you mark each value that will change between runs with a placeholder; at run time, the platform substitutes the value you pass for the placeholder.
How a template becomes a real instruction
Template (content field)
Generate a sales review for Q{quarter} {year}.
1. Pull regional revenue for the quarter from the warehouse
2. Compare against Q{quarter} of the prior year
3. Build an interactive dashboard with the year-over-year cut
4. Save it as Q{quarter} {year} sales review - by regionWhat the agent reads at run time (with quarter=3, year=2026)
Generate a sales review for Q3 2026. 1. Pull regional revenue for the quarter from the warehouse 2. Compare against Q3 of the prior year 3. Build an interactive dashboard with the year-over-year cut 4. Save it as Q3 2026 sales review - by region
Both {name} and {{name}} work as placeholders. Unfilled placeholders are left as-is in the rendered text, so a missing argument shows up as a literal {quarter} the agent can ask you about. Required arguments (flagged in the prompt definition) prompt the agent to ask for a value before running.
Three scopes: personal, persona, global
A prompt has exactly one scope. The scope decides who can see it (and therefore run it), and who can create it in the first place. Personal is the default and the only scope a non-admin can set. Persona and global both require an admin to create or move into.
The three scopes and what each is for
personal- Who sees it
- Only you (the prompt owner).
- Who can create or move into this scope
- Anyone. This is the default when you create a prompt without specifying a scope.
- Good for
- Drafts, experiments, prompts you are still tightening. The portal's create form forces personal scope; the agent path also defaults to it.
persona- Who sees it
- Users assigned to one of the personas listed on the prompt (the platform's role / persona system).
- Who can create or move into this scope
- Admins only. Non-admins cannot create or move a prompt into persona scope.
- Good for
- Role-based playbooks. A prompt for the finance team, a prompt for the data engineers, a prompt for the marketing analysts. Visible to the role, invisible to everyone else.
global- Who sees it
- Every user of this Plexara.
- Who can create or move into this scope
- Admins only.
- Good for
- Team-standard workflows that any user should be able to run: the company-wide weekly KPI prompt, the onboarding tour, the standard incident-report template.
The admin gate on persona and global scope is intentional. A global prompt is something everyone in the org will run, and a persona prompt is something an entire role will run, so authoring those is a shared-content responsibility, not an individual one.
Two paths to manage prompts: agent or portal
You can manage prompts during a chat session by talking to the agent, or on a dedicated Prompts page in the Plexara portal. Both paths read and write the same underlying record. The difference is when each one feels right.
Two ways to manage prompts
Agent path (Manage Prompts / manage_prompt)
- What it does
- During a session, ask the agent to save the prompt you just wrote, or to list the prompts you already have, or to update one. The tool supports create, update, delete, list, and get.
- Who can use it
- Anyone, for their own personal prompts. Admins can also set or change scope to persona or global. Non-admins cannot manage anyone else's prompts.
- What to watch
- The agent will follow your instructions about wording verbatim. If you want the template improved before saving, ask for the improvement first, then save. Once saved, the content is what the agent reads next time.
Portal path (the Prompts page)
- What it does
- The portal has a Prompts surface that lists personal prompts and available prompts (global, persona-matching, system) and lets you create, update, and delete personal prompts. The portal's create form pins scope to personal.
- Who can use it
- Anyone with a portal account, for their own personal prompts. Admins use a separate admin surface to manage persona and global prompts.
- What to watch
- The portal is the right place to copy-edit a prompt carefully (long content, multiple arguments). The agent path is faster when you are at the keyboard already.
The built-in workflow prompts
Plexara registers a small set of built-in prompts during startup, based on which toolkits your instance has connected. You do not have to author these; they are there waiting in your prompt list with category workflow. They are also a useful reference for how the built-in prompts are written.
What ships in the box
Before you write a single prompt of your own, Plexara registers a handful of workflow prompts automatically, conditional on which toolkits your instance has connected. They show up in your available list with category workflow. Each takes a single argument named topic (or dataset for lineage).
explore-available-dataDiscover what data is available about a topicData catalog accesscreate-interactive-dashboardDiscover data, build a visualization, and save it as a shareable assetData catalog, SQL warehouse, and the Plexara portalcreate-a-reportAnalyze data and produce a structured Markdown reportData catalog and SQL warehousetrace-data-lineageTrace where data comes from and what depends on itData catalog access
A workflow prompt that needs toolkits you do not have connected is silently skipped during registration. If your prompt list looks shorter than this, ask the team that runs your Plexara which toolkits are wired up. Your own personal and persona prompts appear alongside these.
What re-running a prompt does and does not do
This is the load-bearing honesty section, the one without which the rest of the article would oversell the feature. A saved prompt is a starting instruction. Running it is exactly equivalent to sending that instruction (with arguments substituted) into a fresh agent session. It is not a recorded macro; it does not pin the data; it does not force the agent's tool choices.
What re-running a prompt actually does
What re-running a saved prompt does
- Reads the latest version of the prompt content from the database.
- Substitutes the argument values you pass into the {placeholders}.
- Hands the resulting text to the agent as a fresh user message in the current session.
- Lets the agent decide, on its own, which tools to call to satisfy the instruction.
What re-running a saved prompt does not do
- Replay the original session, including its tool calls or responses.
- Pin the data: warehouse rows, catalog entries, and shared assets may have changed since the last run.
- Force the agent to use the same tools as before, in the same order.
- Guarantee the same output, the same numbers, or the same conclusions.
- Carry over your prior chat history or context unless you keep it in the same session.
A saved prompt is a starting instruction, not a recording. That is a feature for everyday work, because the data changes and you want today's answer, not last quarter's frozen one. It is a constraint when you need bit-for-bit reproducibility: for that, you combine the prompt (which fixes the instruction) with reading the prior asset's provenance (which captures the SQL the agent ran last time). Article 306 covers the provenance side.
A real prompt record
The abstract field list is easier to ground when you see one. The block below is the kind of record a quarterly-regional-sales-review prompt would carry once it has been saved and used a few times.
A real prompt record
{
"id": "prompt_8f3a91b2",
"name": "quarterly-regional-sales-review",
"display_name": "Quarterly Regional Sales Review",
"description": "Build the standard quarterly sales review dashboard for a given quarter and year, with a year-over-year comparison cut by region.",
"content": "Generate a sales review for Q{quarter} {year}.\n\n1. Pull regional revenue for the quarter from the warehouse\n2. Compare against Q{quarter} of the prior year\n3. Build an interactive dashboard with the year-over-year cut\n4. Save it as Q{quarter} {year} sales review - by region",
"arguments": [
{ "name": "quarter", "description": "Quarter number, 1 through 4", "required": true },
{ "name": "year", "description": "Four-digit year (e.g. 2026)", "required": true }
],
"category": "analysis",
"scope": "persona",
"personas": ["sales-analyst"],
"owner_email": "[email protected]",
"source": "operator",
"enabled": true,
"created_at": "2026-04-02T15:18:00Z",
"updated_at": "2026-04-12T09:33:00Z"
}A sales analyst on this team opens their agent and says “run the quarterly regional sales review for Q3 2026.” The agent finds this prompt by name, asks for quarter and year if they are missing, substitutes them, and runs the resulting instruction. The output is a new asset on the portal, with its own provenance for the catalog searches and queries that built it.
How a prompt connects to the assets it produced
A natural question after seeing the example: when this prompt produces an asset, is the asset back-linked to the prompt? The short answer is no, not directly. The longer answer is that the link you do get is your own naming convention plus the asset-level provenance from 306.
What this looks like in practice
A real session where the user runs a saved prompt and the agent surfaces an honest detail (the data drifted slightly since the prior run) rather than papering over it.
A saved prompt in use, including the honest hedge
You
Run the quarterly regional sales review for Q3 2026.
Agent
Loading the saved prompt quarterly-regional-sales-review with quarter=3 and year=2026. Pulling Q3 2026 regional revenue from the warehouse and comparing against Q3 2025. Building the dashboard now.
Agent
Done. Saved as portal/assets/Q3-2026-sales-review-by-region. Southwest is up 11% year over year; Northeast is flat. Note: the warehouse picked up two late-arriving September entries since I started, so the Q3 2025 comparison numbers are 0.4% higher than the last run of this prompt. Re-run with the same arguments if you want a clean re-render with the updated numbers.
You
Open the prior version. I want the numbers I sent to the board last week.
Agent
Last week's asset is at portal/assets/Q3-2026-sales-review-by-region in its version history; opening version 1, which is what you shared on the 9th. The Q3 2025 comparison numbers there are 0.4% lower than what just rendered. The SQL each version's provenance records is comparable across runs (same tables, same filters), which points at the source data as the cause of the drift rather than a different analysis.
Two things happened here that a less honest workflow would have papered over. The agent named the saved prompt and the arguments it loaded, so the action was inspectable. And when the re-run produced slightly different comparison numbers, the agent surfaced the drift instead of silently overwriting last week's narrative. Reproducibility lives in the prompt; honesty about what changed lives in how the agent answers.
Habits that make a prompt hold up
Three habits do most of the work. None of them are about the prompt format; they are about how you write and where you scope it.
Habits that make a prompt hold up
Write the prompt as a template before you save it. A prompt that has the next quarter hard-coded is going to mislead someone in three months. Replace every value that will change (dates, regions, customer IDs, periods) with a {named_argument} before you call save.
Name the prompt for the action plus the variables. "quarterly-regional-sales-review" reads better in a list than "sales-prompt-final-v2." If the prompt takes a date or a region, the name should hint at that without including the values.
Move from personal to persona to global deliberately, not by default. A prompt that only you run belongs in personal scope. A prompt your team runs belongs to a persona an admin sets up. A prompt the whole company runs is global and needs more wording care, because the audience is broader than the writer's head.
That wraps the 300 series
Eight articles cover the asset system end to end. There is no 309 to wait for; the next step is to apply this to one of your real recurring workflows.
Key terms
Six terms cover the vocabulary of prompts. The first three are the mechanics, the next two are the visibility model, and the last is the audit-trail field that gates who can edit what.
Key Terms
- Manage Promptsmanage_prompt
- The MCP tool the agent uses to create, list, get, update, and delete saved prompts. Non-admins can manage their own personal prompts; admins can also manage persona and global prompts.
- Prompt template
- The reusable instruction record itself: a name, a content field with {placeholder} arguments, and metadata. Stored in the platform database; loaded into the MCP server so the agent can run it by name.
- Argument
- A named placeholder in a prompt's content, declared with a description and a required flag. At run time, the agent substitutes the argument value into the {placeholder} or {{placeholder}} before reading the resulting text.
- Scope
- The visibility level of a prompt: personal (owner only), persona (users with a matching role), or global (everyone). Non-admins can only create personal prompts and can not move them to other scopes.
- Workflow prompt
- A built-in prompt the platform registers automatically based on which toolkits your Plexara has connected. Examples include explore-available-data and create-interactive-dashboard. Categorized as 'workflow' in your prompt list.
- owner_email
- The authenticated user who created a prompt. Set by the platform from the session, not from input. Used to enforce the "only edit your own personal prompts" rule.
