Overview
Author, version, and ship prompts from Trodo — structured messages, typed model config, declared variables, and MCP tools — fetched at runtime by name so a prompt change never needs a redeploy.
Prompt Management keeps your prompt text out of your codebase. You author and version a prompt in Trodo, attach a deploy label like production, and your app fetches it at runtime by name. To ship a change you move the label to a new version — no code change, no redeploy.
It's the top of the loop: you author a prompt here, iterate on a single case in the Playground, batch-test it across cases as an Experiment over a Dataset, then point production at the version that won.
What a version stores
Unlike a plain string registry, a Trodo prompt version stores everything needed to make the call:
Messages
A real chat array with system / user / assistant roles — not one blob of text.
Model config
Provider, model, temperature, max tokens — versioned atomically with the content.
Variables
Declared with optional defaults — a missing value falls back to its default, or empty.
Tools
MCP servers attached by reference, resolved to live tool schemas at run time.
Rendering happens locally in the SDK — compile() fills the variables and returns a ready-to-send payload, so there's no extra network round-trip to render a prompt.
The data model in one breath
A prompt is a named container your app fetches by. Each save cuts an immutable version. A label like production is a movable pointer to one version — deploying is moving the label. Tags organise prompts across versions.
prompt: refund-agent (tags: support, billing)
├── v1
├── v2 ← staging
└── v3 ← production your app fetches "refund-agent" → gets v3Concepts covers the full model and the exact data structures your app receives — read it once and the rest is detail.
Why manage prompts this way
- Ship without deploying. Fix a prompt's wording and move
productionto the new version. Your running app picks it up within one cache window — no build, no release. - Roll back instantly. A bad prompt is one label move away from the previous good one. The old version is never deleted while a label points at it.
- Catch typos before the model. Because variables are declared, passing a value for one that does not exist (a
{{compnay}}slip) throws at compile time instead of silently sending a wrong prompt. A missing value simply falls back to its default, or empty. - Stay up when we're down. The SDK caches prompts and serves a stale copy (or your fallback) if Trodo is unreachable, so a prompt fetch on your hot path never takes your app down. See Caching & availability.