Plexara
What you will take away from this lesson
A prompt that only you can run is a private habit. A prompt your team can run is shared infrastructure. This lesson is about crossing that line in both directions: getting a good procedure into other people’s hands, and getting their experience of running it back to you so the procedure improves.
Plexara gives you two distinct ways to distribute a prompt and a structured channel for feedback on it. They are easy to confuse and worth keeping straight, because they have different audiences, different controls, and different people who can set them up.
Learning Objectives
- 01Pick the right way to get a prompt to other people: a direct share to one named teammate, or a promotion to a whole role or the whole company.
- 02Understand that a direct share serves the live prompt, not a copy, so your edits reach the recipient and there is no forked version to keep in sync.
- 03Follow a promotion through the admin review queue: an owner requests a shared scope, an admin approves or rejects, and only then does the scope change.
- 04Use feedback threads to learn what to fix, including the validation step that lets a subject-matter expert confirm or dispute a correction.
- 05Close the loop by folding a good correction into the knowledge catalog, and retire an old prompt cleanly with the deprecate-and-supersede lifecycle.
Where this lesson sits
402 left you with a reviewed, parameterized prompt scoped to you. This lesson is about everything that happens after a procedure stops being yours alone: distributing it, hearing how it performs in other hands, and keeping it correct over time.
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.
Sharing one person versus sharing a role
There are two distinct mechanisms, and choosing between them is mostly about reach. A direct share hands the prompt to a named individual and you can set it up yourself. A promotion makes the prompt available to an entire persona or to everyone, and because that is a decision about shared content, it goes through an admin.
Two ways to get a prompt to other people
Direct share
- Who sees it
- One named teammate, by email address.
- Who can set it up
- You, the owner. No admin required. The prompt stays personal scope; sharing it does not change its scope.
- Controls
- Each recipient gets viewer or editor permission, with an optional expiration. You can list who you have shared with and revoke at any time.
- Good for
- Handing a procedure to a specific colleague: the analyst covering for you next week, the new hire learning the quarterly review.
Promotion to a shared scope
- Who sees it
- Everyone in a persona (a role), or every user of your Plexara (global).
- Who can set it up
- You request it; an admin approves it. Only an admin can move a prompt into persona or global scope.
- Controls
- The promotion request records the scope and personas you are asking for. The change is applied only when an admin approves; until then the prompt stays personal.
- Good for
- Turning a procedure into a team or company standard: the finance team’s close narrative, the company-wide weekly KPI prompt.
The dividing question is reach. A direct share is for a person; a promotion is for a role or the whole company. The admin gate on promotion is the same persona and access model that governs the rest of the platform, because a shared prompt is shared content and someone owns that decision.
What the recipient actually gets
The most important property of a direct share is the one people assume wrong. Sharing does not copy the prompt. The recipient runs the same live record you own, so improvements you make show up on their side without a re-send, and there is never a forked version quietly going stale in someone else’s list.
Promotion goes through review
Making a prompt a team or company standard is not something you do unilaterally, and the platform reflects that. You file a request naming the scope you want; an admin reviews it; the scope changes only on approval. The request is a signal, not the act itself, which keeps a half-considered prompt from becoming the company default because one person clicked a button.
How a promotion request moves through review
- owner
Request promotion
You ask to move your personal prompt to a shared scope, naming the target: persona (with at least one persona) or global. This flags the prompt for review. Its scope does not change yet.
- admin
Review in the queue
An admin sees the pending request in the review queue. They read the prompt, check the requested scope and personas, and confirm the shared name is free.
- admin
Approve or reject
Approve moves the prompt to the requested scope and personas, marks it approved, and stamps the admin. Reject clears the request and leaves the prompt personal and unchanged.
The request only sets a signal; the scope changes on approval. If an admin edits the prompt’s scope by hand while a request is pending, the stale request is discarded rather than silently re-scoping the prompt.
Feedback is a structured thread, not a comment box
Once a procedure is in other hands, the people running it know things you do not: where it is brittle, what it assumes, which annotation it is missing. Plexara captures that as feedback threads, and a thread carries more than text. It has a kind, a status, and a validation state, which together let a real correction be tracked to a decision instead of scrolling away.
The fields of a feedback thread
kind- What the thread is: a comment, a question, a correction, a rating. Tells the owner whether someone is asking, suggesting, or just noting.
status- Where the thread stands: open, answered, resolved, acknowledged, or wont_fix. The lifecycle of the conversation, not of the prompt.
validation_state- Whether a correction has been confirmed: none, pending, validated, or disputed. This is the field that turns an opinion into a checked fact.
requires_resolution- A flag that marks a thread as needing a decision before it is dropped, so a real correction is not lost in a scroll of comments.
Feedback threads attach to assets, collections, and prompts, and there is a shared general channel for anything else. The agent works them through one tool, Manage Feedback (manage_feedback), which lists, reads, replies, resolves, and runs the validation step. Threads on a prompt are reached by targeting that prompt and are admin-scoped, which fits: the prompt is shared content, and feedback on it is a curation responsibility.
The loop that makes feedback trustworthy
The risk with any feedback channel is that the loudest comment wins. The validation step is the answer. Before a correction changes the procedure, it can be routed to someone qualified to confirm it, who records the result as validated or disputed. A disputed correction re-opens rather than disappearing, and a correction that turns out to be a durable fact about your data can graduate out of prompt feedback and into reviewed knowledge.
From a comment to a checked, captured fix
- 1
Someone files a correction
A teammate runs the shared prompt and notices the holiday list is missing a regional observance. They open a thread of kind correction on the prompt.
- 2
Request validation
Rather than acting on it blind, the owner routes a validation request to the right person: request_validation sends it to the thread author or a subject-matter expert to confirm.
- 3
Validate or dispute
The expert responds: respond_validation records validated or disputed, with an optional reason. A dispute re-opens the thread instead of quietly closing it.
- 4
Fold it into knowledge
If the correction is a durable fact, capture_insight with the thread id promotes it into the knowledge loop and resolves the thread, so the fix outlives this one prompt.
The validation step is what separates this from a comment box. A correction is not acted on because it was loud; it is acted on because someone qualified confirmed it. And when the fix is really about your data rather than this one procedure, it graduates from prompt feedback into reviewed knowledge.
Retiring a procedure without breaking its users
Procedures change. The holiday source is replaced, the report grows a section, a better version is written. The wrong way to handle that is to delete the old prompt and let everyone who relied on it hit a wall. The lifecycle exists so you do not have to. You deprecate the old version to signal it is on the way out, and you supersede it with a pointer to its replacement.
The prompt lifecycle: draft, approved, deprecated, superseded
draftA prompt being shaped. The starting state before it is promoted into a shared scope.approvedPromoted and live for its scope. Reached only on admin approval; this is the state a shared, in-use prompt sits in.deprecatedStill runnable, but on notice. Marks a prompt as obsolete so people stop reaching for it, without yanking it out from under anyone mid-quarter.supersededReplaced. Records the name of the prompt that takes its place in superseded_by, so a run lands on the current version instead of a dead end.
Transitions run one way: draft moves to approved or straight to superseded; approved moves to deprecated or superseded; deprecated moves to superseded. You do not delete a team-standard procedure out from under its users. You deprecate it, point it at its replacement, and let the runs migrate.
From distributed to running
Authored, shared, and improving: the procedure is now real shared infrastructure. The remaining question is the most practical one, which is how it actually gets run, by a person and, where it makes sense, on a schedule.
Key terms
Five terms cover this lesson: two ways to distribute a prompt, the feedback thread and its validation step, and the supersede mechanism for retiring one.
Key Terms
- Direct share
- Sharing a personal prompt with a named teammate by email, as viewer or editor, with an optional expiration. The recipient runs the live prompt, not a copy. Revocable by the owner.
- Promotion requestrequested_scope
- An owner’s request to move a personal prompt into a shared scope (persona or global). It flags the prompt for the admin review queue; the scope changes only on admin approval.
- Feedback thread
- A structured conversation attached to a prompt (or asset, collection, or general channel), with a kind, a status, and a validation state. Worked through the manage_feedback tool.
- Validationrequest_validation / respond_validation
- The step that confirms a correction. The owner routes a validation request to an expert, who records validated or disputed. A dispute re-opens the thread.
- Supersedesuperseded_by
- Retiring a prompt by pointing it at its replacement. Part of the draft, approved, deprecated, superseded lifecycle that lets a shared prompt be replaced without breaking its users.