Andrew Ng's Agentic AI Course in Plain English: Three Blocks and One Secret

Andrew Ng's agentic AI course, offered through Deep Learning AI, condenses a field that has generated thousands of competing frameworks and more buzzword debates than almost any other area of technology into three building blocks and one practical path. What follows is that path extracted into a playbook for building your first business-grade agent, based on the principles Ng teaches and applied to the specific context of a small or mid-size business.

I am Madhuranjan Kumar. The three building blocks are models, tools, and evaluations. Most people know the first two exist and skip the third. The eval is the part that determines whether the agent is actually working or just seems to be working, and it is the part that almost nobody implements until something breaks visibly. This playbook covers the full path from the first design decision to the autonomy question that every production deployment eventually faces.

Write out the task the way a human would do it by hand

The first step in building an agent is not to open any AI tool. It is to sit down and write out, in plain language, how a human would perform the task step by step.

Take patient email management at a dental practice. A front desk coordinator handling a reschedule request goes through a specific sequence: read the email and identify that it is a reschedule, find the patient's existing appointment in the scheduling system, check for open slots in the patient's preferred time range, respond with two or three specific options, and update the booking when the patient confirms. That is five steps, each with a specific input and a specific output.

This exercise is valuable for two reasons. First, it forces precision about what the task actually involves. Most people describe their workflows at a level of abstraction too high to build from. "Handle scheduling emails" is not a buildable brief. "Read the email, find the existing appointment, check availability, offer options, update on confirmation" is a buildable brief, because each step can be mapped to a specific model capability or tool call.

Second, it reveals the edge cases. When the coordinator writes out the human steps, they notice: what happens if the patient's appointment is not in the system? What happens if no slots are available in their preferred window? What happens if the email is unclear about which appointment they mean? Identifying these cases during the human-step exercise means handling them in the agent design rather than discovering them when a patient receives a confused reply.

For a business building its first agent, the human-step document is the most important deliverable of the entire project. Everything else follows from it. Write it before you open Cursor, before you write a system prompt, before you look at any documentation. Write it as if you were training a new employee who had never done the job and needed every step spelled out.

Map each human step to a model call and the tool it needs

Once the human steps are documented, each one maps to either a model call, a tool call, or both. This mapping is the architectural design of the agent, and it is simpler than most people expect.

A model call is used when the step requires reasoning, interpretation, or generation. Reading an email and classifying it as a reschedule request is a model call. Drafting a reply that matches a specific tone and includes the right appointment details is a model call.

A tool call is used when the step requires acting on an external system. Looking up a patient's appointment in the scheduling software is a tool call that queries the scheduling API. Checking available slots is a tool call. Updating a booking is a tool call. Sending an email is a tool call.

Most steps are a model call followed by a tool call, or a tool call that feeds its result to a model call. Read the email and identify the appointment (model), look up that appointment (tool), check available slots in the requested window (tool), draft a reply with those options (model), send the email (tool).

Anthropic's Model Context Protocol standardizes how tools are declared in a system prompt so the model knows what capabilities are available to it. Instead of writing custom integration code for each tool, you declare the functions in a standard format and the model knows to call them when appropriate. This is directly relevant for any business building on top of Claude or any other model that supports MCP.

For the dental practice, the tool inventory for the email agent is: read-email, lookup-appointment, check-availability, send-email, update-booking. Each declared in the system prompt. The model reads the incoming email, identifies what it needs, and calls the right tools in sequence. Building a similar mapping for a web-crm workflow, whether for sales follow-up, customer onboarding, or renewal outreach, follows the exact same pattern.

Add a reflection pass to every writing step before it leaves the agent

One of the most reliable quality improvements in any agentic system is a reflection step: after the model produces a draft, ask it to critique the draft and produce a revised version. This runs entirely within the model, costs a few extra tokens, and consistently produces better outputs than a single pass.

For the dental practice's email agent, this means the agent produces a draft reply, then runs a reflection prompt: "Review this draft against our practice's communication standards. Does it include specific time options? Does it avoid clinical terminology in a patient-facing message? Is the tone warm but professional? What would you change?" The revised version is what goes to the patient.

The reflection step is more powerful than it sounds because it separates the task of generating content from the task of evaluating content against specific criteria. A model asked to write a reply and be polite and include specific times and avoid jargon all at once will trade off between those goals. A model asked to write first and then evaluate separately can focus each task and produce a result that meets all criteria.

For any agent that produces written output, whether that is a proposal, a product description, a customer support reply, or a headline for a google-ads campaign, the reflection step should be a default, not something to add later if quality is a problem. The additional cost in time and tokens is small. The quality improvement is consistent and compound: a draft that gets a reflection pass improves not just because the model catches errors but because the evaluation step surfaces criteria the initial prompt did not make explicit.

The reflection pattern is also a diagnostic tool. By logging the before and after of each reflection, you can see what the model consistently identifies as needing improvement in its first drafts. Those patterns tell you where your system prompt needs more specificity. If the model consistently changes the tone in reflection, the system prompt is not giving enough tone guidance. If it consistently adds information in the second pass, the system prompt is not prompting it to check completeness.

Build the minimum version and run it against twenty real examples

The course's most practically useful single instruction is to build something rough and run it against real examples before you optimize anything. The reasoning is direct: you cannot predict your failure modes in advance. The ones you imagine will not be the ones that actually matter. The ones that actually matter are the ones your examples reveal.

For the dental practice, the minimum version of the email agent reads an email, looks up the appointment if it can find an identifier, and drafts a reply that either offers alternatives or escalates to human review if it cannot resolve the request. It does not handle every edge case. It does not have a polished prompt. It runs on the twenty most common types of emails the practice receives.

Run those twenty emails through the agent. Look at every output. Categorize the failures: this type of email consistently gets misclassified; that type of reply is missing a key piece of information; this edge case produces a confused response. You now have a real failure inventory from real examples rather than a hypothetical one from imagination. That inventory drives every subsequent improvement decision.

The twenty-example standard is not arbitrary. Fewer than ten examples will not surface enough variety to distinguish patterns from one-offs. More than fifty before the first round of improvements is overinvesting in evaluating a version you have not yet optimized. Twenty is the count that gives you enough signal to prioritize improvements without burning the evaluation budget on a draft.

For any business deploying an AI agent in a customer-facing or revenue-critical workflow, this habit is load-bearing. Running twenty real examples before going live is not a delay. It is the minimum responsible step before exposing the agent to actual customers whose experience you cannot undo.

Build your first eval around the failures you actually find

After running twenty examples, you have a failure inventory. Your first eval is built around that inventory, not around failures you anticipated in advance.

An eval is a systematic check that runs automatically every time you change the agent. It tests whether the specific failures you found in your twenty examples still occur in the new version. An eval is not a general quality check. It is a regression test for problems you have actually observed.

The course provides a useful framework for categorizing evals on two axes. Some checks are objective: either the agent included specific time options in the reply or it did not. Either it escalated the email to human review when no appointment could be found, or it sent a confused reply. These run as code checks with a pass or fail result.

Other checks are subjective: whether the tone matches the practice's communication standard, whether the reply feels appropriate for a nervous new patient. Subjective checks cannot run as code. They run as a model-as-judge: a second model evaluates the output against a specific rubric. The rubric needs to be precise: not "is this professional" but "does it avoid medical jargon, does it address the patient by first name, does it include a clear next step."

The dental practice's first eval after the twenty-example run might check three things: did every reply with an identifiable appointment successfully reference it, did every reply offering alternatives include at least two specific time options, and did no reply include clinical terminology in the patient-facing text. Those three checks run on every build. They tell you immediately whether a change to the system prompt made the agent better or accidentally introduced a regression.

Building the eval around actual failures rather than hypothetical ones is what makes the eval useful. An eval built around what you imagined might go wrong will test for problems that do not appear in practice and miss the ones that do. Your failure inventory is the only honest source of what to test.

Set the autonomy level based on what the eval proves the agent can handle

The final stage is not a technical step. It is a governance decision: how much autonomy does the agent get in production, and on what basis does that autonomy increase over time.

Ng's course positions autonomy on a spectrum rather than as a binary. An agent that drafts replies for human review before sending sits at the low end of the autonomy spectrum. One that sends replies automatically sits higher. One that updates the scheduling system without human confirmation sits higher still. Each step up the spectrum requires demonstrated reliability at the previous level.

The eval is what provides the evidence for moving up. If the three checks run over a hundred examples and pass at 98 percent, the practice has quantified evidence that the agent handles those cases reliably. That evidence justifies increasing autonomy for those specific cases, while keeping human review for the cases the eval shows the agent struggles with.

This approach keeps autonomy decisions grounded in demonstrated capability rather than intuition or confidence. The businesses I work with who run meta-ads campaigns do not allocate budget based on which audience segment feels right. They run tests, read the data, and allocate based on what performed. The same discipline applied to agent autonomy produces the same quality of decision: the agent earns each level of autonomy by proving it can handle the previous level, and the proof is in the eval scores.

For the dental practice, the realistic progression starts with the agent drafting every reply for human review. After a month of operation with consistent quality across the eval checks, it earns the right to send straightforward reschedule replies automatically while escalating anything it cannot confidently resolve. After another period of demonstrated reliability on that subset, the set of auto-send cases expands further. The practice always knows why the boundary is where it is: because the eval results at that level justify it.

This is also how you avoid the all-or-nothing mistake. Most early agent deployments are either too restricted to be useful, requiring human approval for every action, or too permissive, running fully autonomously before the eval shows it is ready. The spectrum framing with eval-based advancement is what makes the middle path navigable. Start conservative. Let the data tell you when and where to loosen the leash.

Madhuranjan Kumar works with businesses on the full path from the human-step document through production deployment: designing the tool inventory, building the eval framework, choosing the right autonomy level for each workflow, and expanding it as the agent proves itself. If you want to build an agent that holds up in production rather than one that works in a demo and breaks on real cases, that is exactly the kind of work worth doing properly the first time.