Prompts that learn from production, not playgrounds.

The problem

Most prompts are written once and eyeballed.

Someone iterates in a playground until the output looks right, pastes the prompt into the codebase, and moves on. Maybe there's an eval suite that runs before deploys. Then the prompt meets real users, whose requests look nothing like the test cases, and nobody goes back to find out whether a different wording, a different example, or a different model would have done better.

An AI product is a stack of these choices: the system prompt, the few-shot examples, the temperature, which model serves which request. Each one moves quality, latency, and cost. And the ground shifts underneath them, because every model update changes how the same prompt behaves. Hand-tuning can't keep up.

How most tools approach this

Versioning, playgrounds, and offline evals.

Prompt-management platforms give you version control, a playground, and eval suites: write test cases, compare variants side by side, promote the winner. That's regression testing, not optimization. It tells you a new prompt didn't get worse on the cases you thought of. It can't tell you which prompt performs best on the requests you didn't think of, and it can't tell you that the best prompt for one kind of request is the wrong one for another.

A/B testing prompts in production gets closer, but the variants are still written by your team, and each test occupies an engineer who has better things to do.

How we do it

Continuous experiments, with rewards that mature in minutes.

We connect Curious to the surfaces you want optimized: the system prompt on your support agent, the instructions in your summarization pipeline, the model tier and parameters behind each endpoint. We define the reward together. Eval scores, thumbs ratings, task completions, and regenerate rates count for or against. Latency and cost become constraints the system can't cross.

Curious generates prompt variants, each built on a different hypothesis about what will help: tighter instructions, different examples, a reordered context. Then it tests them through a contextual bandit that learns which configuration works for which kind of request. Support tickets about billing might get a different prompt than tickets about bugs, and a cheap model where it holds quality, a frontier model where it doesn't.

This is the fastest surface we optimize. A purchase takes days to observe. An eval score or a thumbs-down arrives in minutes, so experiments conclude in days instead of weeks. We manage the whole loop and send you a weekly report: what improved, for which request types, and what it did to your quality, latency, and spend.

What you get

Managed end to end.