What problem is this lesson trying to solve? It asks a simple question with a hard answer: when should an AI system be a knowledge tool, a co-pilot, an agent, a workflow, or a mix of these?
That question matters because the pattern choice sets the shape of the whole system. It affects cost, complexity, review, maintenance, and how much trust the user can place in it.
Start with the job, not the agent
A common mistake is to begin with the agent idea. That sounds modern, but it often skips the real decision. The better starting point is the work the system must do.
Some work is about finding and summarizing known facts. Some work lives inside another product and should stay quiet and helpful. Some work needs the system to act on its own. Some work needs a fixed process with human checks. Real products often use a blend.
That is the core shift in AI-native design. The question is no longer, “Can we build an agent?” The question becomes, “What pattern fits this task?”
The five patterns, in plain language
The first pattern is knowledge assistance. This is the simplest shape. A user asks a question, the system retrieves useful documents, and the model turns them into a clear answer. It works well for support bots and internal knowledge bases. It is usually lower cost and easier to evaluate. The trade-off is that it does not reason deeply or act on its own.
The second pattern is the co-pilot. This lives inside an existing app, like an editor or a developer tool. It suggests changes instead of making hard changes by itself. That makes it feel safe and familiar. The downside is that it can be hard to wire into the product, and it is harder to prove how much it helped.
The third pattern is the autonomous agent. This one makes decisions, calls tools, and carries out steps without constant human direction. It can run all day and all night. That gives it reach. It also brings more risk, more debugging work, and more need for oversight.
The fourth pattern is workflow orchestration. Here, the steps are explicit. The system follows a set order, and human review can be built into the path. This is useful when the process must be auditable or safe by design. It is also less flexible than a free-running agent.
The fifth pattern is the hybrid platform. This combines pieces of the other four. Many serious products end up here because real work is messy. Part of the task may need retrieval. Part may need editing help. Part may need a review gate. The mixed pattern is often the honest answer.
Why the pattern choice changes everything
Pattern choice is not a cosmetic decision. It changes the size of the system and the kind of work around it.
An agent-heavy design brings more debugging pain and more liability concerns. A co-pilot brings integration work and harder measurement. A workflow brings more structure and more steps. A knowledge system stays simple, but it gives up autonomy. The same user problem can be solved in several ways, but each way pulls the system in a different direction.
This is where a lot of hype falls apart. Teams often talk about “adding AI” as if that were one thing. It is not one thing. It is a design choice with trade-offs attached.
A small example: support replies in a product
Picture a company that wants help with customer support. One option is a knowledge assistant that looks up policy pages and drafts a reply. That keeps cost low and behavior predictable.
Another option is a co-pilot inside the support agent’s inbox. It suggests a reply, but the human sends it. That can fit a team that already trusts the inbox as the place where work happens.
A third option is a workflow. The system classifies the issue, drafts a reply, routes sensitive cases to a person, and logs each step. That is slower than an agent, but it leaves a clear trail.
If the same company tried to make a full autonomous agent answer every customer on its own, the system would gain speed and lose some control. That may be fine for one kind of ticket and wrong for another. The point is not that one pattern wins. The point is that each pattern matches a different risk shape.
What this says about architecture maturity
Earlier AI work often focused on components. What model? What tool? What memory? Those questions still matter. But they are not the last question.
Module-style thinking at this stage asks for architecture. That means choosing the right coordination pattern before building the rest. It is a more mature habit. It stops teams from forcing one design onto every problem.
A strong system design answer does not pretend every task wants autonomy. Some tasks want support. Some want review. Some want strict steps. Some want a blend. Good architecture starts by naming that difference.
The lesson behind the lesson
A useful AI system is judged by fit, not by flash. If the work is mostly retrieval, build retrieval. If the work sits inside an app, design for that setting. If the work needs action, accept the cost of control. If the work needs auditability, build the review into the flow.
That is the main skill this topic checks. It is not only about coding a model call. It is about seeing the shape of the problem and matching it to the right system pattern.
Software engineering maturity arrived when teams stopped asking, “How do I code this?” and started asking, “What architectural choice is right.” AI engineering is at that point now.
The next useful step is to practice pattern matching on real examples. Take one business task and ask which pattern fits, what it gives up, and what it makes easier to measure. That is the kind of judgment Module 7 is built to test.
That is also the kind of practical thinking The Dravelo Field Notes tries to make easy each edition: one practical technical idea, one learning decision, and one useful network resource each edition.