prompt engineering without guardrails.
As AI-assisted workflows matured at FutureAGI, power users and enterprise teams were iterating heavily on prompts, tweaking structure, variables, tone, and model parameters to improve outputs.
But there was no systematic way to track that iterative process. Prompts ended up hardcoded in application logic, buried in Notion docs, or duplicated across spreadsheets. Changes were untraceable, previous versions were unrecoverable, and there was no consistent way to measure which version actually performed better.
The goal: make prompt engineering repeatable, measurable, and collaborative, and turn Workbench into the canvas for AI experimentation on the platform.
what user sessions actually revealed.
Through interviews with AI engineers and tech teams actively using the platform, four patterns stood out and shaped the design direction.
Users regularly destroyed working prompts by editing without saving a copy first. No undo, no history, no fallback: whatever was there before was gone.
Teams had no way to see how a prompt changed over time. The reasoning behind an iteration disappeared the moment the page refreshed.
Comparing two versions meant multiple browser tabs and a spreadsheet. Nobody wanted to do it, so most decisions were gut-feel rather than evidence.
Engineers recognised the pattern immediately: "This is just version control for prompts." Non-technical users wanted the same safety, without the Git mental model.
These four patterns locked in the three design pillars: versioning, comparison, and evaluation. Every screen that followed was in service of one of those three things.
4 tools stopping at the same wall.
We mapped the four products with the closest surface overlap. Each does something right, but every one of them treats the prompt as a static artefact, not a living, versioned object that needs to be compared, evaluated, and connected to production.
Routes LLM calls across providers with caching, load balancing, and cost tracking. Excellent infrastructure layer for production deployments.
Not a prompt editor. You can log and route calls, but you can't build, version, or compare the prompts that generate them. The prompt stays opaque.
Strong post-hoc evaluation and dataset management. Captures production traces and scores output quality across defined metrics.
Evaluation-heavy, editing-light. You can score a prompt's output but you can't edit, commit, or compare prompt versions in the same interface. The creation and evaluation loops stay separate.
Closest to what we were building. Prompt versioning, usage analytics, and A/B testing across deployed prompt versions.
Weak on side-by-side comparison and no native evaluation library. Versioning is there, but there's no integrated way to answer "which version is actually better?" before you ship it.
Deep output quality monitoring: hallucination detection, RAG scoring, safety classification. Strong for teams who need to audit production outputs at scale.
Pure monitoring, not authoring. Galileo sees what prompts produce in production, but it doesn't help you build, version, or iterate on the prompts themselves.
Every other tool treats the prompt as a static input to something else: a call to route, a trace to log, a score to report. FutureAGI Workbench treats the prompt as the product. Version it, commit it, compare up to 3 versions side by side, evaluate outputs against 70+ metrics, then connect directly to Datasets, Simulation, Observability, and the SDK, all without ever leaving the same interface.
four principles to design toward.
four decisions, one unified workspace.
This is where the four rounds landed. Each decision maps to a pain point from research. Rather than a feature list, the design is a continuous workflow, from landing on a prompt, to editing, committing, comparing, and evaluating, with no dead ends.
Decision · 01the workbench editor: edit, run, and test in one place
What we did: Tried keeping prompt, model configuration, and evaluation as different tabs, with output below (inspired by Galileo and PromptLayer). This approach assumed users would primarily iterate on prompts and variables after configuring the model, with evaluations happening at the end.
Why we dropped it: Outputs differ across models, and side-by-side comparison is essential, and this design restricted the use to one model.
What we did: Tried keeping the prompt and model configuration side by side, with output below and evaluations added afterward. This simplified the workflow for iterating on a single prompt and model.
Why we dropped it: The design restricted users to one model at a time. Since outputs vary across models and configurations, side-by-side comparison is a core part of prompt iteration, making this approach limiting.
The core editing interface supports system, user, and assistant message roles, editable inline with support for media attachments. This mirrors the actual multi-turn structure of real AI conversations, not a simplified single-box editor.
- ·Variables via {{variable_name}} syntax: dynamic runtime inputs without re-opening the editor.
- ·Validation: at least one user message required before running, so there are no silent errors or wasted API calls.
- ·Multimodal: image and audio output types can be generated and previewed directly in the editor.
version history landing page: your prompt's full arc at a glance
What we did: Listed every version in the log with its variable values and timestamp shown inline, so users could scan what changed without opening each entry.
Why we dropped it: The inline variable tags cluttered the log at a glance and competed with the commit message. That detail mattered only after a version was opened, not before.
What we did: Tried filtering the log down to only committed versions, hiding intermediate autosaves so the history stayed short and easy to scan.
Why we dropped it: Hiding autosaves meant users occasionally couldn't recover a specific in-progress edit. We kept the full log and used tags to mark what was meaningful instead.
The landing page for any prompt shows all versions chronologically, each with a commit message and model details. For the first time, users could see how a prompt had evolved, and jump back to any point in that history.
- ·3-dot menu per version: Add/Edit tag, Edit Commit: common actions without navigating away.
- ·Default version always marked: no ambiguity about which version is live in production.
Git-style commits: version control for people who don't use Git
Every save prompts for a commit message, and users choose between two paths, designed to feel familiar to engineers without confusing everyone else.
- ·Just Commit: saves the version to history without changing what's live. Safe during active iteration.
- ·Commit & Add tag: saves and promotes the default version to production. Used when a prompt is ready to ship.
side-by-side comparison: up to 3 versions at once
What we did: Laid out each version as its own column with a single shared "Run prompt" action, so all versions executed together and outputs landed in matching rows below.
Why we dropped it: A single run action for all columns meant users couldn't test one version in isolation without re-running the rest, which wasted time and API calls once past 2 versions.
Instead of browser tabs and spreadsheets, users select up to 3 prompt versions and compare them in a single view. Each column shows output tokens, time taken, and cost, so the comparison is grounded in data.
- ·Sync: mirrors the base prompt structure across comparison columns, so users can isolate the change they're testing without rewriting from scratch.
workbench as a platform primitive.
The Workbench wasn't designed as a standalone tool. Every prompt becomes a reusable asset that connects to the rest of the FutureAGI platform, so a prompt in Workbench can be used anywhere.
Run any prompt against dataset rows to generate model outputs at scale.
Compare prompt versions on the same data before promoting to production.
Score outputs with 70+ built-in metrics: accuracy, tone, hallucination, latency.
Use prompts directly in agent simulations to test real-world scenario behaviour.
Link a prompt to production traces and close the loop between what you write and what you ship.
Fetch any versioned prompt programmatically, and deploy an update without touching application code.
beta results across ~150 users.
The Workbench shipped to beta. Across the cohort, the metrics showed users weren't just adopting the features. They were changing how they worked.
what this taught me about abstraction.
"Git for prompts" is correct technically, but the mental model had to be rebuilt for users who don't think in branches and commits. The two-button commit was the simplest version that still gave engineers full control.
Users started with "can I get my old version back?" Getting that answer to a confident yes was what made them trust the rest of the system.
Platform integration was a multiplier. A prompt in Workbench can be tested in Datasets, evaluated, used in Simulation, and fetched via SDK. That reusability made Workbench worth maintaining.
The Sync feature in comparison mode is a good example of balancing power-user precision with everyday usability. Power users needed it for isolation testing. Casual users needed it to be invisible. Both were true at the same time, and the design had to be both things simultaneously.