Workbench: version control for prompt engineering.

version control for prompts. the thing every AI team needed but no one had built.

FutureAGI Workbench is the structured environment where AI engineers and prompt engineers write, iterate, test, and evaluate their prompts before those prompts reach production. It treats the prompt the way software teams treat code: as something with structure, versions, intent, and a standard for what "good" means.

Before Workbench, every AI team had some version of the same informal system: prompts in a shared Google Doc, a Notion page called "last working version — DO NOT TOUCH," testing by pasting into a playground, and no reliable way to answer "is this version actually better than the last one?" Workbench replaced all of it with a single connected workflow.

three personas, one shared problem.

Research surfaced three personas, each hitting the prompt management gap differently. All technical, all blocked by the same missing structure.

1. 01

   Prompt Engineer

   Writes · iterates · owns the prompt

   Needs to version prompts without custom scripts or Notion backups, and fix a broken prompt in minutes by diffing against the last working one.

2. 02

   ML Engineer

   Receives handoffs · changes prompts · breaks things

   Inherits someone else's prompt and needs the intent behind each decision, so they don't break behavior that was built in on purpose.

3. 03

   Technical PM

   Makes deploy calls · needs evidence

   Decides whether a prompt ships, and needs side-by-side quality scores to deploy or hold on evidence, not intuition.

every team had the same informal system. it broke the same way.

Before Workbench, prompt management wasn't a solved problem with imperfect tooling. It was an unsolved problem with improvised workarounds. The same four absences appeared in every team we spoke with, regardless of company size or AI maturity.

• Version history, anywhere

  "I spent two hours on Thursday trying to get back a prompt that was working on Tuesday." Every team had a version of this story. The fix was a Notion doc, a Slack DM, or a manual backup, all of which broke eventually.

• Scalable testing without a script

  Testing a prompt against one input was easy. Testing against 500 representative inputs, the kind that reveal edge cases, required a custom script every time. No team had a standard way to do it.

• Shared source of truth for the prompt

  Prompts lived in text files, Google Docs, or directly in the model playground. When two engineers worked on the same agent, there was no single authoritative place for what the prompt currently said, or why.

• Objective quality bar for "better"

  Teams iterated constantly but couldn't answer "is this actually better?" without running manual side-by-sides. There was no automated measure of improvement, just intuition and spot-checks against familiar examples.

9 sessions. 23 support tickets. four problems hiding under one surface complaint.

Discovery ran across 9 user sessions (~40 min each) with AI engineers, prompt engineers, and PMs at teams shipping production AI products, plus an audit of 23 internal support tickets related to prompt issues. Competitive analysis covered Portkey, Braintrust, PromptLayer, and Galileo. The same four pain points surfaced in session after session, each one mapping directly to a design decision.

"I used to keep a Notion doc called 'last working version — DO NOT TOUCH.' I just archived it."

— Prompt engineer during session 4, on their first week using Workbench

1. 01

   Problem: No version history, ever

   Solution: Commit system with required message

   Every team had a manual backup that eventually broke. A first-class commit flow, capturing prompt text, model, parameters, and a required "why," made versioning feel as natural as saving a file.

2. 02

   Problem: Can't test at scale without a script

   Solution: Variables + dataset import + bulk run

   Teams tested against the same 3 examples repeatedly, the cases they already knew worked. A variable system with AI-generated inputs and dataset import gave teams 500-row test coverage without a line of code.

3. 03

   Problem: Handoff broke at every seam

   Solution: Structured role editor — system / user / assistant

   Intent behind every prompt decision lived in the original author's head. Separate panels for each role, plus required commit messages, made the architecture of the prompt visible to anyone who inherited it.

4. 04

   Problem: No quality bar for "better"

   Solution: Eval entry point from output + compare mode

   Improvement was judged by intuition. One-click eval from any output, carrying full context into the evaluation system, gave teams a score and a reason instead of a gut feeling.

every other tool treats the prompt as an input to something else.

Workbench's positioning came from understanding what existing tools were optimized for, and what they consistently left unaddressed. Each competitor solved an adjacent problem well and left the prompt itself unowned.

• 

  Portkey

  Gateway and observability layer

  Excellent for routing, caching, and logging. The prompt passes through Portkey but lives somewhere else.

  Gapthe prompt has no home

• 

  Braintrust

  Evaluation-first platform

  Strong eval primitives. But evaluation is the output of a well-managed prompt, not a substitute for managing one.

  Gapassumes the prompt is already good

• 

  PromptLayer

  Prompt logging and history

  Captures what was sent, not what was intended. History without intent is an audit log, not version control.

  Gaphistory without context

• 

  Galileo AI

  LLM quality and analytics

  Great at surfacing quality signals in production. Assumes the prompt is already stable.

  Gapmonitors but doesn't help improve

architecture first. screens second.

The biggest structural question before any screen was what mental model to give the prompt. It had to be more than a text field and less than a full code editor. The answer was the role system: system context, user turn, assistant reply, each with its own panel, its own edit surface, and its own meaning. That structure became the foundation everything else was built on.

Pillar 01 · Structured editor

system. user. assistant. not one textarea.

Most teams wrote prompts in a single block of text. Workbench surfaces the three-role structure that every LLM conversation actually has, making each role independently editable, labeled, and visually distinct. Variables turn static prompts into parameterized templates with real-time fill state.

• System

  How it should behave

• User

  What the user wants

• Assistant

  The model's reply (optional)

1. 01

   Separate panels, explicit structure

   One textarea blurs system context and user input. Labeled panels show the prompt's architecture to anyone who opens it, even six months later.

2. 02

   Variable state, live

   Every variable shows {{empty}} red when unfilled and {{filled}} green when ready. No scanning the text for gaps.

3. 03

   Role labels stay pinned

   On long prompts, System / User / Assistant labels stay sticky, so you always know which role you're reading.

Pillar 02 · Testing at any scale

from one input to five hundred, no custom script required.

Testing a prompt against one input is easy. Finding the edge cases requires testing against inputs that represent the full distribution of what users will actually send, and those inputs are hard to come up with manually. Workbench gives teams three paths to test data: AI-generated variables, dataset import, or typing directly. All three run the same bulk parallel execution.

• AI-generated variables break the same-3-examples pattern. Teams repeatedly tested against the cases they already knew worked, confirming existing behavior instead of finding new failure modes. AI generation produces diverse, realistic inputs across the full variable distribution, including edge cases the team wouldn't think to write themselves.
• Dataset import maps columns to variables automatically. If a dataset column is named customer_name and the prompt has a {{customer_name}} variable, they're matched automatically. The best test inputs are already in the team's production data; import connects to them directly without export/re-import.
• Manual inputs cover the quick one-off case. Not every test needs a dataset or AI generation. Typing values directly into the variable panel stays available for a fast, single check, the same panel and fill-state feedback as any other run, just without the setup.
• Every run is a complete record. The output panel shows the full response alongside token count, latency, and model used, not just the text. Any run can be committed, added to a dataset, or sent to evaluation in one click. Running is never a dead end.

Pillar 03 · Version control

commit. compare. recover. the three things teams were doing manually.

A commit in Workbench captures the full configuration at a point in time: prompt text across all roles, model, parameters, and a required commit message, the "why," not just the "what." Every version is recoverable. Compare mode puts two or three versions side by side with diff highlighting to answer "is this actually better?" with a visual, not an argument.

• The commit message is required, not optional. The discipline this creates, writing the "why" for every change, is worth the friction. When an ML engineer inherits a prompt six months later, they can read the full commit history and understand every decision that was made and rejected. The commit log is the long-term memory of the prompt's evolution.
• Compare mode answers "is this better?" with a visual. Diff highlighting shows exactly what changed between versions. The score delta shows which version won. The argument about "which is better" is replaced by a visual.
• Any version is one click from being current. When a prompt breaks, restoration is immediate, no hunting through Notion docs, no copying from Slack threads. The version with the last known good behavior is always in the history, always restorable in one click.

Pillar 04 · Compare

compare, side by side. prompts, models, parameters, outputs.

Users can compare prompts, change models, change parameters, and see side by side outputs.

Pillar 05 · Evaluation connection

one click from output to eval. the quality loop, closed.

The moment a prompt produces an output, the next question is always: is this good? Workbench surfaces that question as a single "Evaluate output →" button that carries the full context, prompt, variables, model, output, into the evaluation system automatically. No copy-pasting. No re-entering inputs. No context lost in the handoff. The result comes back with a score, a verdict, and a plain-language reason.

• One-click handoff carries full context. Every eval launched from a Workbench output arrives pre-filled: prompt text, variable values, model, parameters, and the output to evaluate. The engineer never re-enters anything. The context loss that happens in a manual copy-paste workflow is eliminated entirely.
• The reason is the product. A pass/fail score tells engineers what happened. The reason tells them what to change. The reason is a design brief for the next prompt iteration, not a red dot to dismiss.
• Eval results feed back into the commit. A Context Adherence failure points directly to a system prompt fix. An Instruction Adherence failure points to an instruction that needs strengthening or a few-shot example that needs adding. The eval result isn't a verdict on the finished prompt, it's the input to the next version.

we put Workbench in front of engineers running their own production prompts.

Each participant used their own production prompt and got one task, with no guidance: commit a version, run it against 20 inputs, compare it with the previous version.

"The commit message thing, I was annoyed by it at first. But then I opened v3 two days later and the message said 'switched from GPT-4-turbo, testing latency difference' and I immediately knew why the output style had changed. I would have spent 20 minutes figuring that out otherwise."

— ML engineer, prototype session 6

1. 01

   The biggest fans weren't the target users

   Built for prompt engineers, embraced by PMs and ML engineers. The basics did the most work: a place to write, a way to save, and trust that yesterday's prompt still works.

2. 02

   PMs stopped waiting on engineers

   Compare mode gave PMs enough context to run their own comparisons and make deploy calls. A capability shift, not a UX tweak.

what teams got from treating the prompt as the product.

the Notion doc got archived. the prompt finally had a home.

• archived

  "Last working version" Notion docs

  Replaced by commit history. Restoring a version takes one click.

• 0

  Custom scripts for scale testing

  500-row runs with no code, covering the full range of inputs, not the familiar 3.

• new

  PM-led deploy decisions

  PMs compared versions on their own and decided on scores, not intuition.

• instant

  Handoff comprehension

  Commit history showed every decision. Intent survived the handoff.

• ↑

  Non-technical adoption

  PMs and ML engineers became the biggest fans of the basics.

• closed

  The write → evaluate loop

  One-click eval showed whether a change was better, and why.

three things I'd do differently. one I felt within the first week of beta.

Three gaps showed up in early usage, before the beta ended.

1. 01

   Set eval baselines before beta

   Teams scored v2 at 0.71 with nothing to compare it to. A baseline should have been the tool's first prompt, not a tip in the docs.

2. 02

   Bring non-technical users into round one

   PMs and ML engineers joined late. Their plainer words for what was broken would have sharpened the problem before design, not after launch.

3. 03

   Require commit messages from day one

   Added late and nearly cut as friction, it became the most praised feature. What feels optional early is often table stakes.