Prompt Studio
Turning scattered prompt work into one product workflow.
One place to trace, evaluate, and simulate every decision your agents make.
Netra helps the teams building them see what their agent is doing, catch problems, and make it reliable.
Prompt Studio is one part of Netra — the part I worked on.
So — what is Prompt Studio?
A single place for developers to create, run, compare, test and release the prompts behind their AI agents — instead of writing in one tool, testing in another, and keeping track of versions by hand.
What I worked on — and who for.
My focus wasn’t the individual screens. It was understanding the workflow, finding where people got stuck, and connecting it all up — so creating, testing, comparing, releasing and reverting a prompt feels like one flow instead of six.
I came in when the product was already underway, and shaped Prompt Studio as we worked out the wider prompt-management flow.
The scattered, disconnected journey.
The same thing kept coming up when I talked to people across roles — our product engineers and the developers building agents: one prompt, dragged through a dozen tools, breaking at every step.
Where the solution came from.
Once I understood where the journey kept breaking and where the other tools came up short, the direction got pretty clear. So instead of copying how prompt tools already look, I started from a simpler question — what does a prompt actually need across its whole life? — and built the workflow around that. Everything below is that, stage by stage.
Keep creation in the flow.
Write a first prompt from a plain description and refine it with AI right where you test it. Drafts auto-save, and a quick Run shows you the output before you commit to a full evaluation.
Compare to find the best prompt.
Line up candidate prompts side by side and see their results together — so picking the best one is something you look at, not something you have to remember.
Prove it holds up, at scale.
Run the prompt across models and repeated executions to find the best setup and see how reliable it is. Starting a run stays simple; the results open with the overall outcome first, then let you drill into models, evaluators and individual runs.
Publishing is a decision, not a save.
Draft → Published → Production. A draft you can change however you want; publishing locks in a fixed, read-only version; production just points at whichever one is actually live.
A safe way back.
Every published version sticks around, so production can drop back to an earlier one the moment something breaks — which closes the loop from create all the way to recover.
