Building a visual agent workflow builder: what we tried, and what we learned
Madhuri Ganta is a frontend developer at ProvenMap, building user interfaces with React and Next.js. She also works on cloud infrastructure using AWS CDK.
A note on this post. This is an engineering retrospective, first published in August 2025 under our original name, ContextDx. We are now ProvenMap. The visual agent-workflow builder described below was a prototype from that period — it is not part of the ProvenMap product today, and nothing here describes a feature you can use. We are keeping the post up because the type-safety and composition problems it works through are still interesting, and the lessons shaped what we did build. For what the product actually does now, start here.
A visual orchestration tool that generated type-safe agentic workflows — and what building it taught us.
The idea: architects composing AI workflows visually
We wanted to democratize AI workflow creation for software architects, business teams and other stakeholders, in the context of providing architectural understanding and automating the more mundane tasks around it. The premise was that users should be able to compose agents that understood their specific domain — either generated automatically as they worked, or assembled visually when they needed something bespoke.
"The challenge? Different teams need different ways of extracting architectural understanding. Some might want to monitor discussion channels and diagrammatically depict the outcome. Others research markets and adapt architecture to respond. Or assess technical debt."
What we built: an adaptive graph builder
The prototype generated agents on the fly as a workspace was set up, hydrating it with purpose-built agents based on context. Where automatic generation could not resolve something, the builder let you step in and edit the flow directly, then evaluate it — in the most type-safe way we could manage.
Automatic agent generation
- Context-aware creation during workspace hydration, based on the architecture patterns and team structure it found
- Workflow composition selected from the analysis scope and the roles involved
Managing generated agents
- Visual editing interface for refining auto-generated agents and tuning behaviour for specific cases
- Comprehensive evals layer where you could validate an agent's logic and verify that its steps actually reached the conclusion it claimed
- Manual editing for when generation failed — for example, when a dependency could not be resolved
The composition model
- Component-based composition — building workflows by connecting nodes representing tools, data sources and logic
- Tool binding — alongside nodes for API calls, data processing, analysis and human review points, we prototyped binding external tools over MCP
- Real-time validation feedback, highlighting issues as you composed
- Type-safe connections, checking data compatibility across the workflow at design time
From visual to executable
On deploy, the visual workflow compiled into a LangGraph graph executed on our Node.js backend. The builder validated input/output types for each node, inferred schemas when integrating dynamic APIs, and handled MCP-compatible tool integration.
The technical layer underneath this is described in detail in the companion post on type-safe LangGraph workflows.
The scenarios we prototyped against
These were the workflows we designed for. They are illustrative of the prototype's intent, not capabilities of the current product.
Discussion-channel intelligence
Agents that parsed team conversations, extracted decisions, and drew the evolution of architectural thinking — including spotting when a new decision contradicted an earlier one.
Market-responsive architecture
Agents that monitored industry patterns and technology adoption, then suggested architectural responses.
Technical debt assessment
Agents that analysed codebases, tracked dependency health, and prioritised debt reduction by its actual drag on delivery.
What we learned
Visual composition is seductive, and the type-safety work behind it was genuinely valuable — that layer survives in the product today. But the builder asked users to think about how to assemble an agent before they had any answer to the simpler question: what is actually in my system, and what will this change break?
That turned out to be the more valuable problem, and it is the one ProvenMap solves now. The workflow builder was the right engineering, aimed one step too far ahead of where teams actually are.