Here is the question nobody asks early enough in an agent deployment: where does the human actually work?
The default answer is chat. Slack bot, Teams bot, some conversational interface where the worker types a request and the agent responds. And chat works beautifully for ad hoc retrieval — summarize the last five meetings, prep me for this call, tell me about this account. But chat is not a workflow surface. It is not a prioritized task queue. It is not a place where you review a drafted email, see your open tickets ranked by revenue impact, and hit send on a follow-up — all without switching tabs.
The real interface for agent-driven knowledge work is a custom micro app. Not a general-purpose dashboard. Not your CRM's constrained UI. A purpose-built application where the agent surfaces context, the human reviews and acts, and the results flow back to the systems of record. Think of it as a role-specific operating surface — here is where I start my day, here is what needs my attention, here is where I take action.
This is where agent deployments quietly become custom software development. The agent handles orchestration, retrieval, and execution. But the interface — the thing the human actually touches — has to match how that specific team works. A CX team's single pane of glass looks nothing like a sales team's. The fields are different, the prioritization logic is different, the actions are different. No off-the-shelf tool gets this right because the whole point is that it is shaped to your workflow, not someone else's abstraction of it.
The good news is that building these interfaces has never been cheaper. Vibe-coded micro apps, purpose-built for a specific role, connected to agents that do the heavy lifting underneath. The hard part is not the UI. The hard part is defining the workflows clearly enough that you know what the interface needs to show and what actions it needs to support.
Chat and custom UI are not either-or. You will end up with both — the micro app for structured daily work, chat for the questions that have not been hardened into a view yet. But if you start with only chat, you will wonder why adoption stalls. The answer is that knowledge workers need a cockpit, not a command line.
Related Essays
Start With Workflows, Not Roles
Role-based agents start with the hardest version of the problem. Workflow-first agents start small, ship in a week, and compound into something larger.
What Workflow-First Looks Like in Practice
A customer success team, five fragmented systems, and a workflow agent that ships in a week. How small scoped wins compose into something that looks like a role.
The Primitives Are the Same Across Roles
Sandbox, tools, prompts, governance — the primitives are universal. Engineering agents and GTM agents share the same engine. Only the body changes.
Key takeaways
- Chat is great for ad hoc queries but fails as the primary interface for structured daily workflows.
- The single pane of glass for agent-driven work is a custom micro app built around how the team actually operates.
- Every agent deployment eventually becomes custom software development because the interface has to match the workflow.
FAQ
Why isn't a Slack bot sufficient as the main agent interface?
Slack works for quick retrieval and single actions, but it cannot serve as a prioritized task queue, a review surface for drafted emails, or a dashboard showing daily productivity. Structured workflows need a structured interface.
Does building a custom interface for agents defeat the purpose of buying agent infrastructure?
No. The agent platform handles orchestration, context, and execution. The custom interface is the thin layer that matches the specific team's workflow. The platform does the hard work; the micro app is the last mile.