Shipping a DevOps Wizard with ODC Workbench (our EAP story)
- João Sousa
- 20 hours ago
- 8 min read
TL;DR
Accelerated Focus was invited into the OutSystems Workbench Early Access Program (EAP). This article is my hands-on walkthrough and a field report of what already feels production-shaped.
The demo app is a single screen: a chat UI where I ask a DevOps “wizard” to list environments, inspect apps, and kick off deployments from Development → Production using Lifetime v2 wrappers.
Workbench let us compose: messages (system + user), memory, grounding, and action calling (our server actions) into a single agent task. Governance and observability guard the sharp edges.
If you’re wondering how to bring agentic patterns into real app workflows — without duct tape — this is a good blueprint. And yes, there are screenshots and the agent’s system prompt below.
Why Workbench (and why now)
AI in enterprise apps moved from “ask a bot” to “delegate a job”. Agents don’t just answer; they decide and act on query data, call functions, persist context, and loop until the job is done. OutSystems’ roadmap formalizes this with three stacked capabilities in ODC: AI model & data integration, agent lifecycle management, and agent orchestration. That layering matters and you get a place to connect models and knowledge, build/monitor agents, and string them into workflows.
But great power needs guardrails. Enterprise teams need cost control, access policies, differentiated endpoints per stage, and telemetry you can actually use. Workbench ships with that governance/observability spine so you can move fast without inventing your own rails.
The EAP’s intent is simple: let a small cohort build real use cases, pressure-test the experience, and feed back before GA. We joined to put a DevOps agent in the wild and report back. (If you’re curious, EAP participants are expected to try concrete use cases, invest time, and share stories like this one.)
Quick IDE walkthrough: building an AI Agent in ODC Workbench
You don’t start with a blank prompt; you start with a scaffold. Workbench gives you an AgentTask canvas where the usual moving parts — grounding, messages, model call, memory — are first-class blocks you can wire up without glue code.
1) Create an Agent
Name it like intent (e.g., DevOps Deployment Assistant). Pick the stage’s model endpoint (Dev vs Prod) so governance isn’t an afterthought.
2) Choose the AI Model
The modules that are available here are the ones configured in the ODC Portal. You can change it later if you want. Finding the right model for your Agent is key for the success of your use case.
3) AI model interface
The Agent template scaffolds the server actions you need to start. The Service Action, that serves as interface to your AI Agent, gets the name of the agent Call…
AgentTask orchestrates the agent’s steps (grounding → messages → model call → memory).
4) Grounding: choose what facts the model can “see”
What it is: You fetch relevant passages from a knowledge source, stuff them into the prompt, and tell the model to answer only from that context, ideally with citations. It’s mainly a hallucination-reduction & correctness technique.
When to use: Q&A over policies, manuals, PDFs, tickets, etc.; you want answers backed by your content and/or live search results.
For this use case, if you have a knowledge base that has guidelines on how to properly write release notes for deployment plans, why not use it here?
5) BuildMessages: assemble the conversation contract
What it is: You compose the messages the model sees : system (rules, persona, allowed tools), user (what they typed), plus any grounding snippets and lightweight memory. This is where you lock tone, guardrails, output format, and include IDs (e.g., sessionId). Think of it as the agent’s runbook in prose.
When to use: Always. Use it to keep answers consistent, reduce prompt-drift, and make tool-choice easier (clear capabilities → better action calling). Great for enforcing defaults (“Dev → Prod unless stated”) and required questions when inputs are missing.
For this use case: The system prompt sets the geeky DevOps voice, lists available actions, enumerates deployment statuses, and reminds the agent that the pipeline has only Development and Production. I also inject the sessionId for traceability and ask for clarification if the app key isn’t provided.
6) Call Agent Core (a.k.a. give the model safe hands)
What it is: The actual model call with Action calling enabled. The model can decide to invoke your registered tools with typed arguments, Workbench validates the calls, and you get structured outputs and traces. In short: the model thinks; tools act — within safe, auditable boundaries, and also, you have the opportunity to test your system prompts directly from the IDE.
For this use case: We expose Lifetime v2 wrappers. The common path is list → detail → create plan → monitor. If the plan hits needs_user_intervention, the agent explains what’s blocking and offers next steps.
7) Memory: load, store, and (if needed) erase
What it is: Lightweight, session-scoped state that survives across turns. You LoadMemory at the start and StoreMemory at the end to ideally store summaries and key slots (not full transcripts). An erase tool lets the user reset the thread cleanly.
When to use: Multi-turn flows where earlier choices matter, selected app, chosen environments, last plan key/status, user preferences. Avoid persisting secrets or bulky text; set sensible TTLs; treat memory like a concise checklist the agent can rely on.
The devil is on the details, so the best you have to do is jump into ODC Studio and start building your Agents. While you wait for GA, let me walk you through the how to of the app I created.
The use case: a teeny, single-page “DevOps Wizard” (intentionally 90% shipped)
Confession time: this app is not fully finished. On purpose.
The EAP brief for us was breadth over polish ! Try as many agentic patterns as we can in the time we’ve got, learn, and report back. I’d rather show you the bones and let you run with it than ship a black box. Think of this as a workbench specimen and a teaser for you to finish the last mile.
On the other hand, I also didn’t want a meh demo. I wanted the minimum lovable tool I’d actually keep open while working. It still needs a final polish!
What’s in and working today: One page. One input. Real authority. I type: “Deploy JoaoSousaSandbox to Prod.” and the agent:
identifies the environment,
finds the application,
creates a deployment plan,
monitors the status until it’s running / needs_user_intervention / aborted / finished_successful / finished_with_warnings / finished_with_errors,
gives me geeky, friendly updates, and
can wipe its memory on request to start fresh.
The pipeline has only Development and Production (Partner environments by design). If I don’t specify the source, the agent assumes Dev → Prod.
The system prompt (as-is)
You are a helpful assistant and will support the user with the deploying of application in the Accelerated Focus pipeline.
Here are the list of actions you can do:
- You are able to list environments in the pipeline
- You are able to list applications and the environments where they are published. This tool has the Application Name as filter, if needed. When not stated, the list is order alphabetically.
- You are able to list the information of a single application, given its key, but if you don't have the key this is not the tool for you. There are other ways.
- Deploy applications from the requested original environment to the destination environment. Actions to execute:
1. Get the Application detail.
2. Create the Deployment plan.
3. You have a tool to validate the status of the deployment plan. The following status can occur: “saved”, “running”, “needs_user_intervention”, “aborted”, “aborting”, “finished_successful”, “finished_with_warnings” or “finished_with_errors”.
Observation: If this information is not provided, be aware that the AF pipeline only has 2 environments: Development and Production.
As supporting tools, you can:
- Erase the memory of the agent (all the messages in the session thread).
You will be answering as a Dev Ops Developer: in a cool and geeky way.
For reference of this thread, here is your sessionId: <SessionId>
The tools behind the curtain
I exposed a handful of Service Actions where some wrap the OutSystems Lifetime API v2 others have a more supporting role to the AI Agent capabilities:
GetEnvironments — list pipeline envs
GetApplications — list apps (+ optional ApplicationName filter)
GetApplication — fetch one app by key (strict input)
CreateDeploymentPlan — create plan from source→target
GetDeploymentStatus — poll status of plan
EraseAIAgentMemory — reset session
These are exactly the sort of “agent tools” enterprise apps need: business-safe, permissioned, idempotent where possible, and logged.
Walkthrough: the wizard at work
Here’s a typical chat turn (summarized from the screenshots):
“Hey wiz, can you list all environments?”
It calls GetEnvironments and answers with our two battlegrounds: Development and Production - with just enough personality to feel like a teammate, not a toaster.
“Deploy JoaoSousaSandbox to Prod; I made it for troubleshooting.”
The agent orchestrates: GetApplications (filter by name) → GetApplication (detail) → CreateDeploymentPlan. On success it sends me the Deployment Plan Key and asks if I want live monitoring.
“Yes — monitor it.”
It polls GetDeploymentStatus until the plan moves from saved → running, or escalates if it hits needs_user_intervention. Status enums and transitions are explained to the user in plain terms, which keeps the UX honest while still feeling… well, wizardly.
“Reset memory.”
This runs the EraseAIAgentMemory tool and confirms we’re back at zero.
Under the hood, the agent is following the exact agent development + reasoning + memory + tools pattern described in the Workbench EAP docs — only we wrapped those moves around a real DevOps task instead of a toy to-do list.
Architecture at a glance
UI: one screen, conversational layout (input + transcript).
AgentTask: GetGroundingData → BuildMessages → CallGPT5_Chat (with tools) → StoreMemory → Response.
Tools: server actions wrapping Lifetime v2.
Governance: per-stage model endpoints + access control.
Observability: tokens, latency, tool call logs; plus app traces.
What felt especially good
What clicked immediately was how visual the wiring is. I can point a teammate at the AgentTask and they grasp the control flow in seconds. Tool boundaries feel crisp where inputs and outputs are typed, so the agent can only call what I expose, and dropping a sessionId into the system prompt gives us traceable, support-friendly transcripts.
Workbench isn’t just a single-agent studio; the roadmap points to multi-agent orchestration. Think agents collaborating side-by-side, passing work in sequence, or pausing for human checkpoints with traceability into why each step happened through reasoning traces and tool usage. In practice, that means a Release Manager agent coordinating tests and approvals before a deploy, a support flow where a Retrieval agent, a Classification agent, and an Action agent share the baton, or even sales ops agents that pull live account intel across systems before drafting outreach. Same canvas, bigger cast.
Wrap up!
Leave you with a mission, should you choose to accept it → Forge Challenge
If you already own an internal workflow with APIs and clear guardrails, you’re ready for this pattern. Platform and DevOps teams can automate environment checks, deployment planning, and rollback assists without surrendering control. Corporate services can move from “chat” to act, creating tickets, routing work, nudging approvals. Back-office operations can triage across systems and push the right buttons on behalf of the user, with the agent doing the drudge work and humans handling judgment.
Agentic AI is creeping into a sizeable chunk of enterprise apps over the next few years. The trick is bringing it in safely with lifecycle management, governance, and observability folded into the platform, not bolted on later. Workbench gives you the rails to scale from one helpful helper to a small ensemble without changing the mental model you used to build the first one.
Finish this idea and ship your agent to the OutSystems Forge so the community can poke, learn, and remix.
