Start with what the user needs to do
When an executive asks me whether a new use case needs an agent, I start with what the user needs to do. Looking at a recurring set of numbers, following a defined approval process and investigating an open-ended question are different activities. They may use the same data, but I would not expect them to need the same interface or degree of autonomy.
My starting point is the simplest mechanism that lets the person do the work reliably. A dashboard can be the right answer even when the organization has the resources to build an agent. A defined workflow can be more useful when approval order matters. I reserve autonomy for tasks where the system needs to choose a path and the team can evaluate those choices.
Start with predictability, frequency and consequence
Ask three questions about the task: how predictable is it, how often does it occur, and what happens if the result is wrong? A recurring comparison with stable definitions points toward a dashboard. A sequence with known approvals points toward a workflow. An exploratory task where the next step depends on what you find may justify an assistant or agent.
The consequence question matters most in regulated settings. Credit decisions, patient-facing communications and anything touching regulatory reporting deserve designs where every step can be explained to an examiner or auditor after the fact.
Dashboards and workflows still earn their place
A dashboard is right when many people need the same agreed measures on a regular rhythm. It gives a weekly business review or a liquidity monitoring process a common starting point. The real work is choosing definitions, comparisons and exception thresholds. Adding a chat interface does not remove that work. If every participant asks the same opening questions each week, publishing those answers consistently beats asking everyone to reconstruct them conversationally.
A workflow fits a task with recognizable stages and clear handoffs, such as gathering information, a reviewer decision and an approved update to another system. Explicit stages make ownership and exception handling easy to explain. AI can assist within a stage without controlling the whole sequence. Design the inconvenient paths too: missing data, an approver who never responds.
Use an agent where the next step genuinely varies
An agent is useful when a task requires choosing among tools or revising a plan based on intermediate evidence. That flexibility brings real questions about boundaries, cost and review. Specify the tools it may use, the work it may attempt, and the conditions that require a human. Natural language is not a reason to grant broad authority.
Separate analysis from execution. Identifying a variance, drafting a response or assembling a review list does not imply authority to change a business record. For consequential actions, the reviewer must understand the intended effect before approving it. In my experience CISOs and model risk teams become far more comfortable with agentic AI once this boundary is explicit and enforced through existing permissions, whether the trigger is a button, a workflow screen or a conversation with Claude over MCP.
Combine interfaces without changing meanings
Practical designs often combine all three. A dashboard shows a recurring signal; an assistant helps investigate it; a workflow routes the proposed response for approval. The critical test is whether definitions, permissions and context stay consistent across the handoffs. If "net revenue" means one thing on the dashboard and another in the chat, you have built a reconciliation problem, not an intelligent enterprise.
A single business process may need more than one interface. A dashboard can show agreed metrics, a defined workflow can handle approvals and an assistant can help investigate exceptions. Keep their definitions and permissions aligned. Ask users to walk through a normal day with the proposed design before adding another component, and note where switching between them would create avoidable work.
Prototype two designs, then decide on evidence
Take one representative task and sketch it in two plausible designs. Compare steps, review burden, failure recovery and user effort, using a simple prototype or walkthrough before any broad build. Ask participants where they would get confused or need another person. The better design is often the one with fewer chances for misunderstanding, even if it looks less autonomous in a demonstration.
Record why the chosen design fits, what it cannot do and what would justify revisiting it. Start with the smallest design that completes the work responsibly, and leave a clear path to improve it.