Agent Workbench
Agent Workbench is how OutSystems customers build AI agents. Version 1 launched at OutSystems ONE 2025, and more than 2,000 certified developers built agents in the first week. But as context engineering became the norm, its model of agents living inside apps fell behind. I led the research into what was holding agents back, pitched a new direction to senior leadership, and became design lead for Agents 2.0: agents as a top-level asset with their own editor, runtime, governance and monitoring.
- Role
- Lead, then Principal Product Designer; design lead for Agents 2.0
- Timeline
- 2025 → 2026
- Team
- AI value stream: several engineering teams and 7 product designers
- Status
- Agents 2.0 launches Q4 2026
- Product page
- Agentic AI Workbench ↗
- AI Products
- Product Design
- User Experience
- Agent Experience
- Design Engineering
Context
In 1.0, developers created agents inside their apps in ODC Studio, with structured inputs and outputs, tool calling, memory and grounding in company data. Adoption was fast, and dozens of agents reached production.
I joined right after launch, designed the testing and guardrails experiences, and interviewed the teams building on it. What made 1.0 fast to launch was starting to hold them back.
Problem
In 1.0, an agent was a logic flow inside an app. Its context, from grounding data and messages to the system prompt, tools and memory, was put together by generic server actions, so context engineering happened in code. Research with early access teams and a follow-up survey confirmed 17 problems, ranked by severity. A deeper round of 15 interviews showed which ones came up most:
Execution time limits
Long reasoning hit timeouts and broke in production
An independent agent runtime with async calls
Black-box behavior
No way to see what the agent did or why it failed
Execution traces and testing while you build
Coarse access control
Once a model was set up, anyone could use it
Permissions for people, agents, data, tools and models
Deployment friction
Agents tied to apps meant manual release orders
Agents deploy and roll back on their own
Fragmented authoring
Building meant juggling Studio and Portal
One dedicated Agent Editor
Prompt iteration
Changing a comma meant redeploying the app
Configuration you publish without recompiling
Cost visibility
No warning before a test loop ran up a bill
Usage visibility and limits per agent
"I've been working probably 10 hours just for the prompting, and still not as I wanted. It's also difficult to test and compare. How did it make those decisions?" — developer, research interview
Key decisions
With the problems mapped, we looked outward: how agent platforms were maturing, the rise of context engineering, and open standards like MCP and A2A. That left one big decision: where agents should live. We compared keeping agents inside apps with making them a platform asset, judging each on first value, scale, iteration, governance, orchestration and ecosystem. I pitched the resulting direction to senior leadership, and it became the plan for 2026.
| Inside appsAgents stay app elements, as in 1.0 | Platform assetChosenAgents sit next to apps and workflows | |
|---|---|---|
| First value | Very fast for one agent in one app | Needs a strong editor and good defaults to feel as fast |
| At scale | Leads to one app per agent | Built for many agents across many teams, with a central catalog |
| Iteration | A prompt fix means redeploying the app | Agents get their own versions, tests and rollback |
| Governance | Policies and audit trail follow the app | The agent is the unit of governance and cost |
| Orchestration | Agent logic buried in app workflows | Workflows orchestrate, agents reason |
| Ecosystem | Sharing an agent means sharing an app | Agents plug into open standards like A2A |
Inside apps
Agents stay app elements, as in 1.0
- First value
- Very fast for one agent in one app
- At scale
- Leads to one app per agent
- Iteration
- A prompt fix means redeploying the app
- Governance
- Policies and audit trail follow the app
- Orchestration
- Agent logic buried in app workflows
- Ecosystem
- Sharing an agent means sharing an app
Platform assetChosen
Agents sit next to apps and workflows
- First value
- Needs a strong editor and good defaults to feel as fast
- At scale
- Built for many agents across many teams, with a central catalog
- Iteration
- Agents get their own versions, tests and rollback
- Governance
- The agent is the unit of governance and cost
- Orchestration
- Workflows orchestrate, agents reason
- Ecosystem
- Agents plug into open standards like A2A
We chose the platform asset. It's slower to start with, so the Agent Editor had to make building one as fast as building an agent inside an app.
Agents become a top-level asset
Agents sit next to apps and workflows, with their own runtime, versions, owners and audit trail.
One conceptual model for the whole system
I designed the model that defines an agent, how it runs and how it's monitored, so several teams could build those parts in parallel.
A dedicated Agent Editor
A web-based editor for developers and business experts alike, because the people who know if an agent is right are often not developers.
Agents as users too
Everything people can do gets a structured equivalent, so other agents can build and run agents without going through screens.
First sketch
Early working board
Input parameters
Prompt
Instructions and data
Model and settings
Memory
Tools
Other agents, actions and data fetching
Output
Structured or JSON
Test
Final model
What an agent is made of in Agents 2.0
Identity
Name, owner, revision and default role
Contract
Input parameters and response format
Configuration
Behavior, capabilities, memory and policies
Testing
Test chat and execution trace
Agent
Intake
Checks the new loan request
Person
Document check
Invalid documents go back to the customer, who has 30 days
Agent
Enrichment
Adds credit and profile data
Agent
Underwriter
Applies the lending policies
Person
Final decision
Approves or rejects the request
Agent
Communicator
Writes the decision, checked by a person before it's sent
Deliveries
Agents 2.0 is a large initiative, and each of the seven product designers owns part of it; colleagues designed areas like evaluations. These case studies cover the two I designed end to end, as the only designer: Agent Guardrails, already live for every agent, and the Agent Editor, where agents are built.
Outcome
Agents 2.0 was shown at OutSystems ONE 2026 and launches in Q4 2026. The conceptual model became the shared foundation for the teams building agent definition, runtime and monitoring.
These are the measures we set to judge it once it's in customers' hands:
More agents reach production
Teams move from experiments to agents that run for real users.
Faster iteration
A prompt or tool change becomes a published revision without redeploying an app.
One place to build
Agents are built in one editor instead of across Studio, Portal and separate test apps.
Trust in what runs
Teams can see what an agent did and why, through traces, logs and guardrails.
Looking back, the pitch worked because it rested on evidence the teams already trusted: problems counted across interviews, and both directions judged side by side on the same criteria. Next time I'd bring engineering into the conceptual model from its first draft, so it starts out shared.