Chat interfaces work fine for single-turn questions. They break down when agents execute multi-step workflows, call external tools, or need human approval before committing changes. Marble OS’s recent demo surfaces a question the industry is wrestling with: what does a production agent GUI actually need?
The problem is not cosmetic. When an agent runs a 12-step workflow involving file edits, API calls, and database writes, a linear chat thread hides the decision tree, buries intermediate state, and offers no clear intervention point. You get a stream of tokens, not a control surface.
What Chat Interfaces Hide
Conversational UIs collapse everything into a single dimension: time. You scroll up to see what happened. You can’t see:
- Which tools the agent called and in what order
- What state it’s holding between steps
- Where it branched based on a conditional
- What files or resources it touched
- Where you could safely pause or rollback
This works for summarization or code generation. It fails for orchestration, especially when money, production systems, or compliance are involved.
Marble OS’s Approach
The demo shows a workspace model instead of a chat thread. Key primitives:
- Visible file tree: Shows which files the agent is reading or modifying in real time.
- Tool panel: Exposes active tools and their invocation history.
- Task list: Breaks workflows into discrete steps with status indicators.
- Output pane: Separates final results from intermediate logs.
This is closer to an IDE than a chatbot. The agent’s work becomes inspectable. You can see what it’s doing before it finishes.
State Management and Intervention Points
The hard part is not layout. It’s deciding what state to surface and when to let humans intervene.
State Visibility Trade-offs
| Approach | Visibility | Cognitive Load | Use Case |
|---|---|---|---|
| Chat thread | Low (linear log) | Low (scroll to read) | Single-turn tasks, summarization |
| Workflow graph | High (full DAG) | High (must parse graph) | Complex orchestration, debugging |
| Task list + logs | Medium (step status) | Medium (scannable steps) | Multi-step automation, approvals |
| Canvas (spatial) | Variable (user arranges) | Variable (depends on layout) | Exploratory workflows, prototyping |
Marble OS picks the task list model. Each step is a collapsible card. You can expand to see logs, tool calls, or intermediate outputs. This balances visibility with scannability.
Intervention Primitives
Production agents need more than a stop button. Useful intervention points:
- Approval gates: Pause before destructive actions (delete, deploy, charge card).
- Step replay: Re-run a single step with different inputs.
- Branch override: Manually choose a path when the agent hits a conditional.
- State inspection: View the agent’s working memory or context at any step.
- Rollback: Undo the last N steps if the agent went off track.
Marble OS shows approval gates in the demo. Before the agent commits a file change, it surfaces a diff and waits for confirmation. This is table stakes for production use.
Comparison: Chat vs. Workflow Tools
Existing agent UIs lean heavily on chat:
- ChatGPT, Claude Projects: Pure conversational. No workflow visualization. Tool calls appear as inline messages.
- Replit Agent: Chat with a side panel showing file diffs. Better, but still linear.
- Cursor, Windsurf: Chat + IDE integration. You see code changes in the editor, but orchestration logic is hidden.
Workflow tools go the other direction:
- n8n, Zapier: Visual DAG editors. Great for seeing the full graph, terrible for natural language input.
- Temporal UI: Workflow execution history with step-by-step replay. Powerful for debugging, but assumes you already built the workflow in code.
Marble OS sits between these. It accepts natural language input but renders execution as a structured task list, not a chat log.
Architecture Sketch
A production agent GUI needs these components (typical stack for state persistence and event-driven UI updates):
┌─────────────────────────────────────────────┐
│ User Input (NL or structured) │
└──────────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ Planner (breaks input into steps) │
│ - Generates task DAG │
│ - Identifies approval gates │
└──────────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ Executor (runs steps, calls tools) │
│ - Maintains state snapshot per step │
│ - Emits events for UI updates │
└──────────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ State Store (step history, outputs, logs) │
│ - Indexed by workflow ID + step ID │
│ - Supports rollback and replay │
└──────────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ UI Layer (task list, file tree, logs) │
│ - Subscribes to executor events │
│ - Renders intervention controls │
└─────────────────────────────────────────────┘The key is the state store. Every step writes a snapshot: inputs, outputs, tool calls, errors. The UI can reconstruct the workflow at any point. This enables replay, rollback, and debugging.
Observability and Failure Modes
Chat interfaces hide failures. You get an error message in the thread, but you can’t see which tool call failed or what state the agent was holding.
A structured GUI should expose:
- Failed tool calls: Show the request, response, and error code.
- Retry attempts: How many times did the agent retry? What changed between attempts?
- Timeout indicators: Which steps are taking longer than expected?
- Resource usage: Token count, API quota, execution time per step.
Marble OS’s demo doesn’t show all of this yet, but the task list structure makes it possible. Each step can have a status badge (running, success, failed, waiting) and an expandable detail pane.
Deployment Shape
A production agent GUI is not a standalone app. It’s a layer on top of an orchestration engine. Likely deployment:
- Frontend: React or similar, subscribes to workflow events via WebSocket.
- Backend: Orchestration engine (Temporal, Inngest, custom) that executes steps and emits events.
- State store: Postgres or similar for step history, outputs, and logs.
- Auth layer: Role-based access for approval gates (who can approve deploys, payments, etc.).
The frontend is stateless. It renders whatever the backend sends. This keeps the UI responsive even if workflows run for hours.
Security Boundaries
Approval gates are a security primitive. Before the agent can:
- Delete a resource
- Charge a credit card
- Deploy code to production
- Send an email to a customer
It must surface the action and wait for human confirmation. This requires:
- Role-based approval: Different users can approve different actions.
- Audit log: Every approval or rejection is logged with timestamp and user ID.
- Timeout policy: If no one approves within N minutes, the workflow fails or pauses.
Marble OS shows a simple approval gate in the demo. Production systems need the full RBAC and audit stack.
When Chat Still Works
Not every agent needs a structured GUI. Chat is fine for:
- Single-turn tasks (summarize this document, write a function)
- Exploratory questions (what’s in this dataset?)
- Low-stakes automation (draft an email, generate a report)
If the agent doesn’t touch production systems, doesn’t need approval, and finishes in under 30 seconds, a chat interface is simpler.
Technical Verdict
Use a structured GUI if:
- Your workflow has more than 3 sequential steps
- The agent calls external APIs or modifies production resources
- You need approval gates before destructive actions (delete, deploy, charge)
- Users must pause, replay, or rollback individual steps
- Observability is required for debugging, auditing, or compliance
- Multiple agents or tools run in parallel within a single workflow
- You’re building for teams where different roles approve different actions
Stick with chat if:
- Tasks are single-turn or purely exploratory
- No external side effects (read-only operations, content generation)
- Users don’t need to inspect intermediate state
- Workflow completes in under 30 seconds with no branching logic
- Simplicity and speed matter more than granular control
- You’re prototyping or running low-stakes experiments
Marble OS’s demo is a useful proof of concept. The task list model is more scannable than a chat thread and easier to build than a full workflow graph editor. The missing pieces are rollback, replay, and deeper observability. But the core question is right: if agents are going to run production workflows, we need interfaces that expose the plumbing, not hide it.