MvR Digital Workforce - Proces Quest

Every UiPath project, starts with a project intake where doing triage on whether it is suitable for automation is the starting point. We help to teach triage to new consultants using agents.

Comment

Devpost — MvR Digital Workforce - Agentic Proces Intake

Inspiration

Every automation consultancy knows the pattern: clients automate their way into the wrong project. A process gets picked because someone shouted loudest, the intake happens in a spreadsheet nobody enjoys filling in, and three months later an RPA bot is fighting a process that should have been an agent — or shouldn't have been automated at all. Meanwhile, citizen developers who could triage their own processes bounce off the abstract world of systems thinking.

At MvR Digital Workforce we already had the cure on paper: a battle-tested Proces Intake Template that scores volume, complexity, risk, feasibility and ROI. The problem was never the model — it was that nobody wants to fill in a spreadsheet, and a fixed questionnaire can't follow up when an answer is vague.

So we asked: what if the intake felt like a 16-bit RPG, and instead of a filled-in spreadsheet you walked away with a running first draft of your automation — a BPMN 2.0 flow, designed by an agent, ready to open in UiPath Maestro?

What it does

Process Quest turns process intake into a game, and the game's loot is a real Maestro flow. The whole experience is a four-stage quest laid out on a pixel-art quest map, hosted by Rex — the Structural Wizard of the Automation Guild. Each stage unlocks the next.

  1. Meet Rex (the briefing). Rex greets you as your Architect, introduces himself across a few dialogue boxes, and lays out the path: profile your company, sit down for a deep intake interview, then forge a Maestro-ready BPMN flow. No spreadsheet in sight.
  2. Profile your company. A short form — Architect name, industry, company size, digital maturity, and the systems you run (SAP, Salesforce, Outlook…). This isn't busywork: it becomes the context seed that lets the intake agent skip the generic warm-up and tailor every question to your organisation.
  3. Have the intake conversation. Instead of clicking through a fixed questionnaire, you talk to Rex, powered by our ProcessIntakeSpecialist agent — a conversational LangGraph agent running on python in UiPath. It interviews you one chat bubble at a time, grounds every question in MvR's real intake template via UiPath Context Grounding, offers clickable suggestion chips, shows a "…thinking" bubble while it reasons, and — crucially — judges whether your last answer actually answered the question, re-asking when you're vague instead of nodding along. When it has enough, it emits a structured IntakeResult: swim lanes, tasks with performers, decision gateways, exception paths, and a Low/Med/High RPA assessment. You're returned to the quest map, with the Flow Forge stage now unlocked.
  4. Read your verdict, then forge the flow. The Flow Forge stage opens on a verdict scorecard: the IntakeResult is scored into five dimensions and plotted on a Volume × Complexity matrix, landing in one of four quadrants — RPA Hero 🦸 (classic RPA fit), Agentic Boss 🤖 (agents + Maestro orchestration), Side Quest 🧭 (easy, but watch the ROI) or Trap ⚠️ (don't — ship a PDD instead). A process character sheet shows the five stat bars, and the agent's own justification becomes the verdict's rationale. Hit Forge and our second agent — the AutomationDesigner, also a coded LangGraph agent on UiPath — turns the intake brief into a structured automation design: connectors, branch conditions, exception paths, HITL checkpoints, each with a per-field confidence score so the UI can highlight what's a grounded fact versus an educated guess. A deterministic serializer renders the design as BPMN 2.0 XML with full diagram layout, shown on the in-app bpmn-js canvas and ready for UiPath Maestro. The quest map celebrates with a trophy — your blueprint is forged.

Behind the game, the whole thing ships as a UiPath Coded App, and its two key steps — the intake interview and the design — are themselves agents orchestrated on UiPath. The tool that forges Maestro flows is itself an agentic process, traceable server-side.

Key metric from our lean canvas: a short conversation → a first BPMN. No spreadsheet, no fixed 10-question form — just a grounded interview that stops as soon as it has what it needs.

How we built it

  • Frontend: React + TypeScript + Vite, Zustand for state, Phaser for the overworld (bridged to React via a single event bus), bpmn-js for the Flow Forge canvas, all wrapped in a 16-bit pixel theme (nes.css + custom CSS variables), including a Factorio-inspired conveyor layout for the flow view.
  • Deployment pipeline — local-first, shipped by CLI. We develop against a mock-first local app (npm run dev, Vite at localhost) where every external dependency is a deterministic mock behind an adapter seam, so the app runs fully offline. The deployed artifact is a second src/ tree — the UiPath Coded App — where the same adapters are wired to live UiPath services, env-gated by VITE_* vars and talking to Orchestrator and Maestro through the @uipath/uipath-typescript SDK. Shipping to a tenant is one command (Deploy-Tenant.ps1) that drives two CLI surfaces, because a coded app can't live inside a .uipx: uip solution pack/publish/deploy ships the Maestro flows + the AutomationDesigner agent into Shared/ProcessQuest, and uip codedapp pack/publish/deploy ships the web app into its folder — live at hackathon26_512.staging.uipath.host/process-quest, not a localhost demo. Re-pointing the same script at a fresh tenant (folder key + OAuth clientId) redeploys the whole thing.
  • Two agents, not one.
    • ProcessIntakeSpecialist is a conversational coded LangGraph agent (isConversational: true) with a ground → converse graph. It retrieves from a ProcesIntake Context Grounding index and drives the interview with llm.with_structured_output(TurnDecision) — a typed turn decision (answeredPrevious, reply, suggestions, intakeComplete, intakeResult) that forces the model to grade each answer and re-ask on a non-answer rather than parsing free text with regex.
    • AutomationDesigner is a coded LangGraph agent with an assemble → ground → design → validate → repair → finish graph. It takes the JSON design brief in and returns a validated AutomationDesign out, with Pydantic models mirroring the TypeScript types on the app side.
  • The seam between them: services/intakeMapping.ts converts the agent's IntakeResult into the AgentDesignBrief the designer consumes — mapping the Low/Med/High assessment into the five scored dimensions and the matrix quadrant, inferring Integration Service connectors from mentioned systems, and passing the full intake (tasks/gateways/exceptions) through as a design seed. This is exactly the seam that let the conversational intake replace the original 10-question triage without touching the design-or-BPMN pipeline.
  • Orchestration: both agents run on UiPath as part of one solution alongside the supporting Maestro BPMN flows (ProcessQuestDesigner, ProcessQuestBpmnGenerator, ProcessQuestBackbone) — shipping them together is what auto-allocates agent runtime (standalone agent deploys failed with "Agent runtime capacity not allocated").
  • BPMN stays deterministic: the LLM produces typed structure, never XML. A rule-based serializer renders BPMN 2.0 with the full DI layout (shapes, edges, waypoints) so bpmn-js renders cleanly and Maestro imports it.
  • Architecture for a hackathon team: everything external sits behind adapter interfaces (intake agent, design agent, BPMN generation, RAG discovery). Each adapter degrades gracefully to a deterministic mock, gated by env vars — so the demo never dead-ends, teammates integrate by swapping one implementation, and the app runs fully offline for development. We carry two parallel src/ trees — a mock-first local dev app and the deployed Coded App with the live UiPath adapters — kept hand-in-step.
  • AI pair programming: we built much of this with Claude Code and the UiPath skills/CLI toolchain, which let one developer ship the agents, the flows and the app in parallel.

Challenges we ran into

  • Making the agent say "no, answer the question." A free-text conversational agent is agreeable — it accepts vague or off-topic answers and moves on. We fixed it by switching the converse node to structured output (TurnDecision with an explicit answeredPrevious boolean), forcing the model to judge every turn whether the user actually answered, and re-ask the same question when they didn't.
  • The conversational invocation contract. A coded agent run as a process returns classic job output, and each job is stateless. So the app keeps the whole conversation as wire messages and re-sends the entire array every turn, polling the job to completion and reading {reply, intakeComplete, intakeResult, suggestions} back. Latency is ~30–60s/turn (serverless cold start + LLM + grounding), so the chat shows a "…thinking" bubble.
  • Reading the design agent's answer back. The documented "global variables" endpoint 404s for orchestration instances and classic job output returns {}. We initially routed the design step through a Maestro flow and kept hitting an unreadable read-back; the fix was to point the design step at the AutomationDesigner agent directly (same proven start → poll → getOutput path as the intake agent) and harden every read in try/catch so a 404 degrades to "no readable design," not a raw error banner.
  • The packer and the runtime want opposite things. UiPath's solution packer validates agent-call activities against design-time bindings, but the Maestro runtime needs literal releaseKey/folderId values. We built a splice pipeline that injects literal runtime context after binding-backed packing — and learned the call contract the hard way (type: "string" literals or your agent receives empty inputs).
  • Browser ↔ UiPath plumbing. Three separate silent failure modes: the SDK must be force-initialized on app load or every Maestro call 401s without an error; browser calls must hit staging.api.uipath.com (the API subdomain) or CORS kills them with a bare "Failed to fetch"; and OAuth redirect URIs needed slash-normalization plus registering both variants on the external app, or login silently no-ops.
  • Agent runtime allocation. Deploying the agents standalone failed with "Agent runtime capacity not allocated"; deploying them as part of the solution allocates runtime automatically. So the agents always ship via the solution, not as loose processes.
  • BPMN that actually renders. Generating BPMN XML is easy; generating the DI layout deterministically so bpmn-js renders a clean diagram and Maestro imports it took careful coordinate bookkeeping. We deliberately kept layout out of the LLM's hands.

Accomplishments that we're proud of

  • End-to-end and deployed. From "walk up to the Process Intake desk" to "agent-designed BPMN open in Maestro" — live on a UiPath tenant, not a localhost demo. And it's re-deployable: one Deploy-Tenant.ps1 command stands the whole thing up on any tenant.
  • A real conversation, grounded in real methodology. The intake is a genuine LLM interview grounded in MvR's actual Proces Intake Template via Context Grounding — and it refuses to let you skate past a question. The game is a skin over a real consulting instrument.
  • Two cooperating agents. A conversational intake specialist captures structure, hands a typed brief to a design agent that validates its own output and runs a repair loop before returning. The UI shows per-field confidence so humans review the guesses, not the whole design.
  • A demo that cannot dead-end. Every external dependency — both agents, BPMN generation, RAG — degrades to a deterministic fallback. Auth down? Agent unreachable? The quest continues.
  • The intake tool is itself an agentic process. A Coded App whose own intake and design steps are agents orchestrated on UiPath. We're in the Maestro track with a project built on UiPath agents and Maestro.

What we learned

  • Conversation beats questionnaire — if you make it strict. Replacing the fixed 10-question form with a grounded, structured-output interview changed who finishes an intake and how honestly they answer — but only once we forced the agent to grade answers instead of accepting everything.
  • Agents should output structure, not artifacts. Having the LLMs produce a typed IntakeResult and AutomationDesign, and keeping BPMN serialization deterministic, gave us reliability an "LLM writes XML" approach never would.
  • Stateless agents, stateful client. Treating each conversational agent run as stateless and re-sending the whole transcript per turn is simpler and more robust than trying to keep server-side session state.
  • Seams first, integrations second. Adapter interfaces with mocks on day one let a hackathon team build the experience, the agents, the flows and the RAG pipeline in parallel — and let the intake agent slot in to replace the triage behind a single adapter.
  • A lot of very specific UiPath platform knowledge: coded-app auth lifecycles, conversational-agent invocation, solution-level agent runtime allocation, Maestro instance APIs, and how to read an orchestration's outputs when the obvious endpoints won't talk to you.

What's next for MvR Digital Workforce - Agentic Proces Intake

  • Real process discovery (RAG) on the Quest Board. Extend the Context Grounding work beyond the intake template: index the client's SharePoint/Confluence corpus so the Quest Board fills itself with real candidate processes, and the design agent grounds on actual documentation and MvR coding standards.
  • Act 2: the Code Review dungeon. MvR's Code Review Template (focus areas A–I) becomes a post-build quality dungeon run on the forged flow, with Valid Dev and Valid Lead sign-offs as the two bosses.
  • PDD export for the "Trap" quadrant — when the verdict is "don't automate yet," ship a structured Process Definition Document instead of a flow, so every quest ends with an artifact.
  • Richer intake signals — let the conversation probe trigger type and per-system access to sharpen the designer's connector inference, while keeping the interview short.
  • Guild progression — leaderboards and shared XP across a client's citizen-developer community, turning the intake backlog into a quest log the whole organisation plays through.
Share this project:

Updates