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.