402 - Letting the agent write the prompt

• 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.

1. 1

   The session that just worked

   An hour of back and forth ending in a report you are happy with. The full record of what was tried, corrected, and kept is in the conversation.
2. 2

   You ask for the prompt

   "Write a reusable prompt that produces this report for any period and region, and save it." One instruction, no transcription.
3. 3

   The agent drafts it

   It distills the conversation into a template: the steps in the order that worked, the gotchas as explicit instructions, the values that changed as named arguments.
4. 4

   You review and save

   You read the draft, fix anything off, and confirm the save. It is stored as your personal prompt, ready to run by name.

{
  "name": "annotated-sales-review",
  "display_name": "Annotated Sales Review",
  "description": "Year-over-year sales review for a period and region, annotated with US public holidays and any known store-closure events for the period.",
  "content": "Produce an annotated sales review for {period} in the {region} region.\n\n1. Pull revenue for {period} and for the same period one year earlier; align them for a year-over-year comparison.\n2. Annotate the timeline with US public holidays from the calendar reference.\n3. Recall any store-closure events affecting {region} during {period} from memory and mark them on the chart with a short label.\n4. Build an interactive dashboard, not a chat reply.\n5. Save it as an asset named '{period} {region} annotated sales review'.",
  "arguments": [
    { "name": "period", "description": "The period to report on, e.g. Q2 2026 or May 2026", "required": true },
    { "name": "region", "description": "Sales region name, e.g. Southwest", "required": true }
  ],
  "category": "analysis",
  "scope": "personal",
  "source": "operator",
  "enabled": true
}

• It knows the order that worked. You may remember the report; the agent remembers that it pulled the prior-year figures before the current ones because the join was cleaner that way. Order is half of a good procedure.

• It knows the gotchas, because it hit them. The correction you made on the second pass is in the conversation. A hand-written prompt three weeks later is unlikely to include the mistake you have since forgotten you made.

• It can tell a constant from a variable. The agent just saw which values you changed across tries (the period, the region) and which stayed fixed (the annotation sources, the output shape). That is exactly the line between an argument and a hard-coded step.