Pick the right mode. Pick the right product.

The first thing most people try with any AI product is a single prompt. Ask for a draft. Ask for a summary. Ask for a plan. For some tasks, that is genuinely enough. The mistake is assuming that if a model can answer one good prompt, the prompt is the system.

Single-prompt thinking breaks in three predictable situations.

First, the task has multiple dependent steps. “Summarize this document” can be a prompt. “Summarize this document, then draft three follow-up emails, then check them against our style guide, then stage them in drafts” is not a prompt anymore. It is a process. Once steps depend on one another, you are in workflow territory whether you admit it or not.

Second, the task recurs with variation. Weekly reporting, inbox triage, vendor comparisons, customer research. These are not one-off asks. They are repeated patterns. If you rewrite the same setup every time, output quality drifts because your setup drifts. That is a sign you need a reusable structure, not a better one-liner.

Third, the task needs to act in the world. Drafting text is one thing. Reading files, searching, checking a system, routing work, staging an email, or posting an update are different capabilities. A prompt can describe those actions. A prompt by itself cannot reliably perform them.

If you have ever written a three-paragraph prompt because you were trying to cram a whole operating procedure into one message, you have already discovered the boundary. The problem is not your prompting skill. The problem is mode selection.

There are four modes that matter here, and most confusion comes from people using the words interchangeably.

Chat is the simplest mode: one ask, one response, no real persistence, no planned execution. It is right for quick questions, one-off drafts, fast exploration, and low-friction back-and-forth.

Workflow is a defined sequence of steps. You know the steps in advance. The system runs them in order. Workflows are predictable, auditable, and relatively easy to debug because the structure belongs to you. They are also rigid. If the situation changes mid-run, the workflow does not improvise unless you redesign it.

Agent is a system that figures out the next step itself. You provide the goal, the boundaries, and the tools. The system decides what to do first, checks results, then decides what to do next. That flexibility is why agents are powerful and why governance matters more once you start using them.

Multi-agent is two or more agents working on parts of a larger problem. This becomes useful when one agent does not have enough context or when the work naturally breaks into specialized roles. It also adds handoff failures, coordination overhead, and much more debugging surface.

The useful rule is simple: if you can write a deterministic function, write the function. If you know the steps, use a workflow. If the steps are not knowable in advance, use an agent. If one agent is not enough, then and only then consider multi-agent.

You do not need to memorize the table. You do need to get comfortable asking one question: do I know the steps in advance?

The framework only becomes useful when you run it against your actual work. Not a hypothetical future workflow. Not a toy example. The real tasks that took your time in the last month.

Pick three tasks. Make them recent. Make them real. Make them varied. If you pick three versions of the same task, you will learn less than you think.

Now classify each one using four questions in order.

Could this be handled as chat? If a single interaction would genuinely do the job, it is chat. People often over-classify because the task felt annoying by hand. Annoying does not automatically mean agentic.

If not chat, are the steps knowable in advance? If you could draw the sequence on paper right now, that is workflow territory. If the sequence depends on what the system discovers mid-run, it is not a workflow anymore.

If the steps are not knowable, can one agent handle the whole thing? If one role with the right tools could carry the task end to end, a single agent is probably enough. If the task requires distinct specialized handoffs, then multi-agent becomes reasonable.

Could this be a function instead? This is the most important honesty check in the whole path. Sometimes the right answer is “do not use AI for this.” That is not a failure. It is good mode discipline.

If all three of your tasks end up classified as agents, pause and re-check. That is the most common overreach. If all three end up as chat, you are probably missing the repeated or multi-step structure in the work.

Every mode has a governance cost, and the cost scales with capability. This is the part most people skip until something breaks.

Chat has the lowest cost because the scope is small: one question, one answer, usually no persistence and no actions. Governance here is mostly about what is allowed in the prompt and what is allowed in the output.

Workflow adds step state, tool use, and real-world actions. That means you need an audit trail for each step, approval gates for consequential actions, and a way to stop the process when something goes sideways.

Agent adds unpredictability. The system decides what to do next, so you cannot pre-authorize every step. That forces you to narrow permissions, introduce approval on higher-risk actions, and think much harder about memory boundaries because the agent carries state from one run into the next.

Multi-agent adds coordination overhead on top of everything else. Handoffs between agents become failure points. Audit surfaces multiply. Debugging gets harder because you are no longer just tracing one decision stream, you are tracing interactions.

The useful operating principle is brutally simple: choose the lowest-capability mode that solves the problem. It is cheaper to govern, easier to debug, and harder to misuse. The boring answer is often the correct one.

This is where the framework becomes a product decision. Go back to the three tasks you classified in Unit 3. Pick one. Ideally it is the one you are most ready to act on this week.

If you picked chat, the landing spot is usually AI Agent. It is the right surface for quick drafts, one-off summaries, personal research, and low-friction daily work with memory and tools.

If you picked workflow, the answer is often AI Workers, especially when the work is recurring, team-shaped, or approval-sensitive. If it is a tiny solo workflow, AI Agent may still be enough, but most operational workflows want the structure Workers provides.

If you picked a single agent, the answer is usually AI Workers in team or business contexts, because the role-shaped execution, approvals, and auditability matter more as stakes rise.

If you picked multi-agent, the answer is either AI Workers for well-defined team systems or Secure AI when the work touches regulated data, enterprise-grade controls, or organization-wide coordination.

If you picked “should be a function instead,” honor the answer. Do not use AI just because you can. Mode discipline includes choosing not to use AI when a deterministic tool is the better fit.

Now add the governance layer from Unit 4. Heavy audit requirements, strict approval gates, or sensitive data will push the answer up the ladder from Agent to Workers to Secure AI. Product choice is not separate from governance. Governance narrows the choice.