How Corpus and RouteDeck rebuilt SaaSToAgent as an agentic workbench
SaaSToAgent hit a familiar trap: a promising graph and action system wrapped in a product shell that still behaved like chat plus buttons. The reset was not cosmetic. We separated responsibilities so RouteDeck became the graph-backed runtime/store layer for agentic UI and Corpus became the central SaaSToAgent product agent that consumes that state, selects legal operations, and drives the workbench experience.
The problem we had to correct
SaaS-to-agent products drift when they expose interfaces instead of intent. A graph can exist. Tool schemas can exist. Eligible actions can exist. The product can still feel wrong if the user cannot tell what the system can do now, what the agent is doing now, what is blocked, what needs approval, and what evidence supports the next move.
The reset was driven by one rule: do not turn eligible capabilities into the default UI. Show agent-authored proposals, initiated work surfaces, and diagnostics instead.
That is why the architecture was tightened around three clear owners: the graph kernel commits truth and guards invariants, RouteDeck projects runtime state and legal operations into UI surfaces, and Corpus remains the primary product agent that chooses within those allowed bounds.
The Agentic UX contract that shaped the rebuild
Our workbench UX research established that SaaSToAgent should feel like an operating surface, not a generic chatbot with side panels. The operator should always be able to answer a small set of questions without opening dev tools or reading raw JSON.
The operator questions
- What can SaaSToAgent do now?
- What is Corpus doing now?
- What setup or approval is blocking progress?
- What evidence, source data, tool state, or trace supports the output?
- How can the user correct, take over, approve, or save a learning?
The patterns we kept
- Chat is the intent spine, not the whole product.
- Capability boundaries must be visible.
- Progressive disclosure is the power model.
- Failure and manual recovery are first-class UX.
- Approvals and tool scope belong in the core interaction.
The RouteDeck + Corpus contract
The anti-drift architecture became simple enough to reason about and strict enough to defend. RouteDeck is the runtime/store layer for agentic UI. Corpus is the SaaSToAgent product agent that consumes RouteDeck state. The graph kernel owns persistent truth, validation, approvals, and recovery context.
RouteDeck owns runtime projection
- State projection from graph truth into surfaces.
- Typed legal operations and surface contracts.
- Presentation state, navigation commits, and reusable hooks.
- Read-only diagnostics and introspection.
Corpus owns product behavior
- Conversation, prompt policy, and platform proposals.
- Selection of legal operations instead of raw state edits.
- Selection of allowed surface variants within the graph contract.
- Visible agent behavior grounded in evidence and approval posture.
Corpus decides intent. The graph commits state. RouteDeck projects state into surfaces and diagnostics. React renders the projected result around Corpus.
Concepts we established to stop product drift
Runtime truth and legal operations
- Everything is graph-owned, but not everything is graph-visible.
- No direct graph mutation: Corpus chooses typed legal operations.
- Safe graph or navigation operations may auto-run in a turn.
- Side effects use proposal plus action or approval flow.
- Blocked operations stay hidden from default agent context.
Surfaces, evidence, and recovery
- Visible choices are Corpus-authored proposals, not raw eligible menus.
- Capability state, approval posture, and evidence are core product UI.
- Diagnostics and meta tools share the same read-only introspection layer.
- Surface variants are sticky, but presentation state remains ephemeral.
- Failure paths and manual recovery are treated as normal workbench states.
How we built the foundation that powers Corpus
The work did not stop at philosophy. The RouteDeck refactor turned the app graph into a reusable state-management contract instead of a SaaSToAgent-specific navigation DTO. That gave Corpus a stable runtime to consume and kept product-specific behavior out of the reusable framework layer.
Research the operator workbench
We defined the operator questions, capability states, approval surfaces, and evidence expectations that the product must answer.
Reset the ownership model
We separated graph truth, RouteDeck projection, and Corpus behavior so the product could stop drifting into an action router.
Build the runtime/store layer
RouteDeck became the graph-backed runtime and store that powers state, legal operations, diagnostics, and surface selection.
Open the next Corpus lane
With the foundation in place, Corpus can move into OpenAPI ingestion, generated tools, approval-aware execution, and per-agent corpus generation.
What this unlocks next for SaaSToAgent
The next lane is not generic chat polish. It is a product system where every SaaS Agent owns its API connections, generated actions or tools, execution traces, RAG corpus, memory, QA evidence, and channel context within a clean boundary.
Near-term product lane
- OpenAPI and REST schema upload with inspection surfaces.
- Generated tool catalogs with risk, auth, and write posture.
- Plan artifacts, approval requests, and trace summaries.
- Execution evidence visible directly in the workbench.
Corpus generation lane
- Per-SaaS-Agent retrievable knowledge isolated by agent identity.
- Corpus built from OpenAPI specs, generated actions, traces, and uploaded docs.
- Citations back to specs, actions, docs, and execution evidence.
- Governed learning candidates instead of silent behavior drift.
That is why this case study matters: Corpus is not another chatbot feature. It is the product interface sitting on top of a graph-governed runtime that can finally support real SaaS-to-agent execution.
Need the same kind of reset for your SaaS product?
If your agent initiative is drifting between chat, tools, and workflow state, start with the operating model. We help teams map hidden business logic, define legal operations, and build approval-ready workbench surfaces before rollout.