Agentic workflow course: build AI processes that work on their own

The eighth course in MONA's free AI course series, and the one we are most proud of in terms of ideas: agentic workflows: how to build machines that do real work for a business with AI plus code, instead of casual chatting or drag-and-drop no-code. The course follows a curriculum of nearly 6 hours that our team rates as among the most rigorous on this topic, localized and filtered for business people: from foundation concepts and the 5-piece framework of an agent, to the DOE framework that separates the "certain" part from the "flexible" part, then up to the cloud to run automatically on a schedule. One thing up front so you see why we like it: the course's philosophy matches the path MONA has walked for years: what needs absolute certainty goes to code, what needs judgment goes to AI, and the human keeps the final say. If you have taken the course vibe coding hay Advanced Claude Code then this will feel smooth; if you have not, you can still follow, because the course starts from concept zero.

Part 1: What an agentic workflow is, and how it differs from chatbots and old automation

It opens with a demo of the destination: a single command like "find 5 meal delivery companies near this area, find their emails, draft a note asking about a 3,500 calorie a day plan and send it." The AI finds, filters, drafts and sends real emails through a configured connection by itself. Work that would eat 20 minutes of manual effort takes under 15 seconds of human effort. That is an agentic workflow: the AI does not just answer, it acts across many steps until the job is done.

To position it properly, look at the three rungs of the knowledge-tool ladder that businesses have climbed:

• Document (the past few decades): static, one-way knowledge. Processes, handbooks, contracts: valuable because they never change, but they cannot do anything on their own.
• Chatbot (booming since the start of the decade): dynamic, two-way knowledge, but it stops at talking. Ask how to scan a customer list and it hands you a guide, while the doing is still on you.
• Agent: two-way and actually doing. Given the same brief, "scan 200 air conditioning business owners in the US", the agent checks the available scanning tools itself, runs a 25-row trial, sees the industry match rate is low and adjusts the filter on its own, runs the full job, pours it into Google Sheets, and adds emails and phone numbers: from start to finish nobody lifts a finger.

And compared with old drag-and-drop automation (connecting nodes, drawing wires, tangled if-else)? The difference is that anyone can read it and anyone can edit it: an agentic workflow is written in plain-language bullet points. "When someone replies to a sales email: look up the key points in the spreadsheet, quickly research the person who replied, draft a short friendly reply; if they decline, drop it." To change the behavior, add one sentence. No need to spend months learning some drag-and-drop platform. People in the trade call the gap between what AI can really do today and what most people actually use “overhang”: this gap is currently a living for early learners, and it will close gradually as the market catches on. If you are reading this, you are on the early side.

A slice of everyday life to show that an "agentic workflow" is not science fiction: the workflow from a sales call to a quote. The old way: replay the recording, pick out the key points, open the quote template, fill it in, check it, write the email: a whole afternoon. The agentic way: paste the call transcript in (or connect directly to the transcription service's API) and type "make a quote from this transcript." The agent finds the "draft quote" directive in the workshop, pulls the problem and budget from the call, asks if the client's email is missing, generates a quote document in the company voice, then sends a follow-up email through the configured email connection. The person who builds this workflow spends 15 minutes building it once; from then on each quote takes a few dozen seconds. Multiply that rhythm across a dozen workflows in the company and you can see where the "river of value" flows.

Part 2: Why now: three doors just opened at once

A fair question from business people: "AI has sounded great for a long time, so why can it only do real work now?" Three reasons, all measurable:

1. Model intelligence has crossed the working threshold. Top models (Claude, GPT, Gemini) now solve around 80% of the SWE-bench Verified set: a benchmark of real software bug fixing, the kind of work where a human engineer spends a whole day tracing the cause. It means the "brain" is smart enough for most office and mid-level technical work.
2. Connection standards have taken shape. MCP (the protocol that connects AI to outside tools) and frameworks like Claude Skills: the gear that links AI to email, spreadsheets and CRM now has a common standard, no more of every vendor having its own kind of wiring.
3. Prices have dropped far enough to turn a profit. Anthropic's strongest model generation has cut its price three times as soon as a new version launched; measured by cost per unit of intelligence, analysts estimate a drop of around 40x in a single year. The question "is it profitable to hire AI for this job" now usually comes out as yes.

And a way of thinking worth hanging on the wall about scale: don't dream of automating 100% of one person; automate 90% of a great many roles. The loom did not turn the tailor into thin air: it turned the tailor into the operator of ten thousand garments a day. What is different now: that "loom" can be rebuilt with a few lines of plain language, in a few minutes.

Part 3: Dissecting an agent: the five PTMRO pieces

Every decent agent, whatever platform it runs on, cycles through five pieces. Grasp these five and you can read any "agent" tool on the market without being dazzled by jargon:

1. Planning: break a big goal into steps, put them in order, and fix the plan when things change. A critical note: a model's planning ability is currently not perfect, so the big-picture direction must be set by a human. A ship that leaves port one percent off lands a hundred kilometers off on the other shore: human judgment should be placed exactly here.
2. Tools: the agent's hands: calling APIs, running code, reading and writing data, browsing the web. A valuable tip: don't wait for anyone to build tools for you: have the model write the tools it needs to use itself, because models are trained to be very good at programming.
3. Memory: three layers: short-term memory while thinking, memory within a conversation, and long-term memory through files (rule files, config files). Intermediate data should be pushed out to files or an external database and loaded back in only as needed. Don't make the model hold it all in its head.
4. Reflection: the agent grades its own output, spots errors, and corrects course. Without this piece the system breaks at the first error, just like the dead-stop scripts of classic automation.
5. Orchestration: the conductor layer that moves information between the four pieces above, looping until the job is done.

Part 4: The Achilles heel: a probability machine doing work that demands certainty

This is the most valuable theory in the course, and the thing we wish every business owner understood before signing any "AI automation" contract. An LLM is, at its core, a probability prediction machine: the same question in five chat windows gives five different answers. Meanwhile business needs certainty: an invoice must come out the same every time, a process must produce exactly one result.

The sobering math: a 5-step process where each step is 90% accurate gives a whole chain that is only 59% correct 59% of the time (0.9 to the power of 5). Ten steps: 35%. Twenty steps: 12%12%. That means a long chain run purely on "AI cleverness" will almost certainly break somewhere. And for customers, being wrong 1 time in 20 does not mean "5% impact": one wrong invoice is enough for a customer not to come back a 21st time.

The answer is NOT to sit and wait for smarter models. The answer is to build a frame around the model: like bumpers on both sides of a bowling lane, so even a crooked ball bounces off the rail and still hits the pins. Concretely: deterministic work (calling APIs, transforming data, writing files) is turned into code, run a million times with one result; work that needs judgment and handling ambiguity is left to the AI. The curriculum has an unforgettable comparison: having an LLM sort a list with its "innate intelligence" takes 15-30 seconds; calling one line of sort code takes 53 milliseconds, several hundred times faster and nearly free. Making an LLM do deterministic work is like hiring a PhD to count the warehouse. The golden rule to carve in stone: use AI for judgment, use code for execution. It is also why MONA has always built automation software with production code rather than stacking AI prompts on top of each other: not because we are conservative, but because that is how probability math works.

Part 5: The DOE framework: directive, orchestration, execution

From the principle "AI judges, code executes", the curriculum builds a working framework called DOE, and the best thing about it is that it is just a folder structure plus one rules file, not software you have to buy.

• The directive layer (directives/): one markdown file per workflow, written in plain language: "scan prospects", "draft a quote", "enrich email data". A decent directive has four parts: a clear goal goal; inputs needed; steps in order (which step calls which script); and a definition of "done" so the agent can grade itself (such as "success when there is a Google Sheet link with at least 100 rows"). Plus two valuable extras: tricky cases already met (which API's known quirks, and how to avoid them) and fallback options ("if service A fails, switch to service B": write exactly one line, no if-else diagram). Because it is all plain language, non-technical staff can read and comment on it: the company's processes stop being a black box.
• The orchestration layer: this is the AI agent itself, playing the role of a good department head: it takes the task, reads the directive, decides which tool to call and when, and diagnoses errors instead of crashing. The deadly difference from wire-drawing automation: the path is decided at runtime based on the situation, not hard-drawn at build time.
• The execution layer (execution/): code scripts (usually Python), each script does exactly one thing: scan data, pour into a spreadsheet, send email. Absolutely deterministic: same input gives the same result, testable, improvable over time. A subtle point: scripts can still call AI inside (for example, a script reads each spreadsheet row and asks the model to write a personal greeting): the difference is that the AI is called within a set frame, not an AI taking the wheel freely.

It comes with two files familiar to you if you have followed this course series: the master rules file (AGENTS.md, and copies named CLAUDE.md and GEMINI.md with the same content so it runs on any model) that tells the agent how to understand the framework, how to handle errors, and how much to decide on its own; and the .env file that holds all API keys: never inside code, so you can share directives freely without leaking secrets. The real power of this framework is in how fast knowledge replicates: the curriculum tells of a service company with around 2 million dollars in annual revenue that needed only 15 minutes to load its internal process library to set up a working agentic framework that handles most of a manager's tasks, with an operational error rate after tuning of around 2-3%.

You will notice what we like most: DOE is the "democratized" version of the architecture that serious software shops build for clients: the process layer separated from the execution layer, with control and logs. The remaining difference between the do-it-yourself version and the industrial one is load capacity, multi-user permissions, and who is accountable: we draw that boundary at the end. And if by now you are thinking "this is exactly what our company needs but we have no one to build it": call 1900 636 648, and the MONA team will listen to you describe the workflow in 15 minutes and tell you straight how long it takes to build, how much it costs, and which parts you can do yourself for free.

Part 6: Hands-on: setting up the workspace, the first workflow, and the lesson of "two ways to connect a CRM"

The sequence for building your first workshop, as the curriculum demonstrates:

1. Create a new folder, paste in the AGENTS.md rules file (a free template is included in the course materials), open the agent and type: "set up the workspace following the rules file". The agent builds the full DOE folder tree with directives, executions, and a sample .env.
2. Give a high-level voice command for the first workflow, for example: "onboard new clients using this email: send a company intro with a link to book a kickoff meeting." The agent asks a few follow-up questions (what to send with, where is the company info), then writes the onboard_client.md directive and the email-sending script itself, and even walks you through creating a Gmail app password to put into .env.
3. Want to change the email template? Say one sentence. The agent edits both the directive and the script, and uses the new template by default from then on. From that point the workflow is an asset, not one employee's memory.

The second valuable exercise: connect the agent to a CRM (the curriculum uses ClickUp) and build two ways to compare: way one uses ClickUp's official MCP: plug it in and it runs right away, but hits a ceiling when you need to manipulate custom fields: MCP is off the rack, not made to measure. Way two has the agent write its own API scripts for ClickUp (create, read, update, delete): a bit slower, but it can do everything the API allows. The lesson stressed again and again: there is no absolutely better way, try both and keep the one that runs: it sounds simple, but it is what separates people who do the work from people who read ads.

For a company that already has a standard operating procedure (SOP) book: this is a gold mine waiting to be dug. Drag the SOP file into the workspace and command "convert this into directives and scripts following the DOE framework": an SOP already has goals, steps, inputs and outputs, so it converts very smoothly. If your company's SOP is the "ask Ms. Bay in accounting" kind: the very process of the agent pressing on every vague spot forces the company to make its processes explicit, a side benefit we often find more valuable than the machine itself. And if you have nothing yet, don't hesitate: saying it out loud in bullet points, as if explaining to a new colleague, is enough. For example, here is a verbatim brief that ran well in the curriculum: "Scan prospects by the industry and area I specify. Check that 80% match the target market before scanning in full. Where emails are missing, enrich them with a secondary service. Pour everything into a shareable Google Sheet and send me the link."

For a real run on that foundation, the curriculum builds a lead scanner from LinkedIn Sales Navigator: the real results scanned 231 profiles and enriched 139 valid emails, and the hardest test: open a completely new session, with the machine's memory wiped clean, and run it again from the start with a different query: it still returned 45 of 66 profiles in 4 minutes. A workflow only counts when it lives independent of old session memory; one that runs because it "happens to remember" does not.

The course also skims Claude Skills: DOE's cousin made just for the Claude family: each skill is a folder with a SKILL.md file (with a header section so the model reads only a summary, saving tokens) plus accompanying scripts. If you took the advanced Claude Code course you have met this; the one thing to remember: Skills package neatly for sharing within the Claude ecosystem, while DOE is neutral and runs with any model: choose by the ecosystem you stand in.

The Skills demo in the curriculum is worth retelling because it shows how down-to-earth the tool is: building a skill for periodic reports from a PDF template. Drag a designed report template into the chat box and command "every week pull weather data and fill it into exactly this template." The agent builds the skill structure, writes the data-fetching script, and, the loveliest detail, midway it finds the data source it planned to use is paid, so it switches to an equivalent free source by itself and tells you. Swap "weather" for "revenue by branch" and you can already picture how your company's weekly report would run itself.

Four techniques for widening your bandwidth with an agent, which the curriculum stresses throughout and which we have each confirmed: talk instead of type (read long briefs aloud, and the model understands small typos on its own); ask in reverse before building ("give me the 3 best ways to do X with pros and cons" and then choose: far cheaper than building the first way that comes to mind); paste instead of describe (API docs, search links, sample files: just throw them in whole, don't sit summarizing them from memory); and "just do it": when the model politely hands you a guide like "here are the steps for you to do yourself", reply with exactly those words: it has hands, let it work, and you only approve.

Part 7: MCP done right: the standard plug, and the price nobody mentions

MCP is called "the USB-C port of the AI world": a common standard for AI to plug into outside tools (Gmail, Drive, CRM, data-scanning tools), proposed by Anthropic in late 2024 and now followed by the whole industry. An MCP server serves three things: data, tools (functions the agent can call), and prompts that guide how to use them. When needed, go to mcpservers.org or mcpmarket.com to browse the catalog.

But here is the part few people say honestly: MCP takes up room in the model's head. Each declared tool eats roughly 300 tokens of description; plug in 5 servers with a dozen tools each and fifteen thousand tokens evaporate before the agent does any work: and the more junk in the model's memory, the lower the quality. The curriculum measured it on a real machine: a few simple MCP connections already took nearly a tenth of the context window. The MCP rule boils down to three lines: use it when you need to share with a team, when it is a widely adopted standard everyone uses, or when you need to plug in and run right away; for the core workflow that runs daily, your own API scripts are usually leaner, cheaper and better controlled. And a warning: the MCP marketplace is a mix of gold and brass, with many servers thrown together to chase the trend and with poor error reporting: plugging unknown things into your workshop brings in variables.

To be fair, MCP has some very satisfying moments: the Gmail connection in the curriculum is just one sentence, "install Gmail MCP to send email on request": the agent finds the authentication available on the machine, adds the configuration, opens a browser to sign in, and after a restart you can send email by voice command. And when you need an MCP server nobody has built, no need to wait: have the agent write its own MCP server: building one takes about 10 minutes, without opening a single doc page. The spirit of the whole course repeats here: when a tool is missing, the machine builds the tool, and you only need to know what you want.

Part 8: The operator's craft: self-annealing, testing with real data, and knowing when a human hand is needed

Building it is only halfway. The other half is operating it so the workflow hardens over time, and this part collects the most valuable principles:

• Self-annealing. Borrowing the image of tempering steel: heat then cool slowly so the crystals settle more firmly. Build a four-beat loop into the rules file: hit an error → diagnose → fix → update both the script and the directive so the error does not recur. After a few months of running, a directive that started as a few sketchy bullets becomes a battle-hardened workflow: with a re-check step, fallback options, and a stop point awaiting human approval. Just like a good employee: handle everything you can before bothering the boss, and write it down so the whole team does not step in the same hole.
• Test with real data, never with data the machine makes up. Having the model generate its own test data is meaningless: it generates exactly the shape it likes, so of course it runs. You must throw in live data: a real customer table, real search links. The curriculum also reruns from a completely new session, with the machine's memory wiped, to be sure the workflow can stand on its own and not live off old session memory.
• The 10x rule for optimization. Only overhaul when the improvement is 10 times or more on a key metric. A real example: enriching 2,000 rows of data sequentially took 20 minutes; fiddling with small optimizations got it to 15 minutes (25%, not worth the risk of new bugs); switching to parallel batch runs cut it to 1 minute: 20 times, worth doing right away. Small improvements of a few dozen percent are a time trap.
• Three parallel options. For a hard job where it is unclear which path is right: have the agent list 3 approaches with pros and cons, open 3 sessions running the 3 approaches in 3 separate scratch folders, compare the results, keep the winner, and merge the good ideas from the losers. It costs a few extra dollars, in exchange for a decision backed by evidence instead of a guess.
• Where a human hand is mandatory: decide with two axes. Axis one: how consequential the task is to the company. Axis two: sensitivity to errors: whether a small mistake can cause big damage. High on both axes means a human must approve before it goes out: a sales email sent to thousands of people (change two or three words and the feel changes entirely), financial documents (one extra zero and credibility is lost for good). Low on both (scanning data, generating drafts to choose from) can be left fully automatic. And some work should never be automated: having a machine pose as a person to phone and close customers: with even a one in a thousand chance that the customer realizes they are talking to a robot, the damage outweighs all the savings.

Three small operating habits that compound, before we get to the safety rules:

• For the first fifteen runs: watch with your own eyes. Each run is only 30 seconds to a minute, but watching the AI "think" a few times teaches you more than three days of letting it run blind. When you see the thinking start to drift, hit stop and steer right away: one correcting message is infinitely cheaper than an hour of running the wrong way.
• Set up a done chime. For long workflows, don't sit and watch: tell the agent "set up a chime for me when any session finishes" (Claude Code calls this a hook): it researches and installs it on its own. Open several parallel sessions and go wherever the chime rings: the rhythm of a foreman walking the workshop floor.
• Combine single workflows into a bigger chain. Once the single workflows run well, tie them into an "umbrella directive": one sentence, "trigger the new client intake workflow", pulls the whole chain of prospect scanning, email enrichment, greeting writing, and campaign launch running one after another: no more finishing step one and forgetting to press step two, wasting half a day.

We close this part with four mandatory safety rules to write into the rules file, drawn from a real accident told in the curriculum (a person let an agent run freely for two days with full system access, and it wiped the entire disk): one, stop and ask a human when API cost passes a threshold; two, never edit or delete API keys and login credentials; three, never carry secrets out of the .env file; four, log every self-modification. Four lines, ten minutes to set up, in exchange for sleeping well.

Part 9: Going to the cloud: run on a schedule, run on a signal, no machine left on

Once a workflow runs well in the workshop, the last step is to let it run on its own while you are away. The most important architectural principle of this part, and you will find it very MONA: when you take it to the cloud to run unattended, move only the deterministic scripts up and take the AI out of the run loop. The reason: the probabilistic nature of the model is an unnecessary risk at 3 a.m. with nobody watching: in the cloud, the workflow goes back to a fixed production line where each step leads to the next: trading flexibility for stability, exactly where stability is needed.

• Platform: the curriculum uses Modal (modal.com): a "serverless" platform that charges per run, and costs nothing when idle: a few weeks of testing cost only a few cents. Similar options include trigger.dev and many other platforms.
• Two kinds of triggers: on a schedule (a morning report, an end-of-month reconciliation: tell the agent "run at 5 p.m. every day" and it configures the schedule itself); and on a webhook signal: a link like a doorbell, and when another system (a web form, a CRM) calls it, the workflow runs within seconds. Work that fits neither type should stay in the workshop, where running under watch still catches problems.
• Real cost and responsiveness: platforms like this cold start in about 3 seconds and shut down on their own after the run; the curriculum spent only a few centsover several weeks of testing. The dashboard has a "run now" button to test between schedules, so you don't wait for the appointed time. One temptation to avoid: building a loop where "errors are sent to another AI to fix itself and rerun": it sounds cool, but the odds of it fixing cleanly without spawning new errors are fairly low, and your bottleneck is rarely the number of webhooks: just let errors report to a channel where a human reads them.
• The cloud must send logs back: by default, running in the cloud is running blind, with no thinking window to watch. When deploying, you must tell the agent: every run, success or failure, fires one line to a dedicated Slack (or Telegram, email) channel. No logs, no operation: we apply this rule to every client system, with no exceptions.

A number worth knowing when weighing investment in multi-agent architecture: an experiment published by Anthropic showed a strong model acting as lead, coordinating several sub-agents on research work, outperforming a solo run by up to 90%: but only for research work that gathers information, not for every kind of work. A big team does not automatically beat a lean one: every handoff and report back between parent and child is also a link that can fail: just remember the compounding math in part 4.

The final advanced part: sub-agent: a sub-agent is sent to do one job in its own clean-room memory, then returns just a summary, keeping the parent agent's head from filling with junk. The two sub-agents most worth keeping, per the curriculum: the reviewer (takes code with a stranger's eyes, without context, and grades purely on quality: improving accuracy by about 5-10%) and the librarian (dedicated to updating directives to match the scripts' real behavior, and allowed to write only to the directives folder: exactly the principle of least privilege). Don't overuse it: sending troops out has a cost and adds failure links; for most ordinary work, the main agent does it faster itself.

Part 10: Bringing it into the real workday, and the final boundary

Before looking at the operating picture, we lay out a menu of seven workflows worth building first for Vietnamese businesses, ordered by rising difficulty, each buildable with exactly the techniques you have learned:

1. Quotes from call transcripts (described in part 1): the appetizer that earns money fastest for a service company.
2. Scanning and enriching prospect lists: from industry and area criteria to a customer table with emails, running the full match-check loop.
3. Periodic reports from a template: sales data poured into the company's standard PDF template every Monday morning, with a chime to Slack or a Zalo group.
4. Reconciling data from two sources: invoices against statements, orders across two systems: the work people find most boring, and the one the DOE framework handles most durably because it is purely deterministic.
5. Tracking competitors and the market: each morning scan the prices, posts and job listings of a competitor list and boil them into a 10-line bulletin.
6. Screening job applications: score CVs against the company's own criteria, rank them with reasons, and interview only the top group: remember the two-axis rule: a human still signs off on the decision to reject anyone.
7. A complete new-client intake chain: an umbrella directive that ties the above into a single command: the destination of the whole course.

The real operating picture that the curriculum demos at the end, and the rhythm we see fits anyone who has finished the whole course series: three agent sessions running in parallel on three areas: one session runs the post-meeting workflow of a service company (from call transcript to quote, prospect scan, campaign launch, summary email); one does content research (finding topics that are performing in the niche for new posts); one handles community care (gathering questions, drafting replies, leaving a human to press send). The curriculum's estimate, which we find not at all exaggerated: a person who masters this skill set can automate around half of their daily workload, and the rest is also much more pleasant because the most boring work is carried by machines.

Your role in that picture comes down to two words: decider and fuel-giver. A truly stuck agent will come to you on its own, with full context: what it is doing, what it is stuck on, which paths it sees. Very often your answer only needs to be "go read that vendor's API docs first" or "take option two": one sentence, a few seconds, and the machine runs on for another hour. That is why someone who does not code can still run an entire workshop of machines: what the workshop needs from you is business judgment, which you have in abundance.

The final boundary, said plainly as in every course in this series: the framework you just learned is a personal and team workshop: extremely powerful for internal workflows, for service companies, and for the stage of figuring out what is worth automating. But when that workflow becomes the lifeblood of the business: a hundred transactions a day, many people with many permissions, real money flowing through every beat, one wrong step losing money and customers: then it needs to be rebuilt as production software: load-bearing, with permissions, full logging, and people on call and accountable. MONA has walked that road for over 10 years and 14,000+ projects, and the nice thing is that after this course you will talk to our team several times faster: you bring the directives and workflows you have already tested, and we tell you straight which parts stay as they are, which are worth industrializing, and how long until payback. Call 1900 636 648 or send it to info@themona.global: the first consultation is free, with transparent quotes and we build at the price you sign, as MONA has done since 2016.

Quick answers

What is an agentic workflow? It is a workflow in which the AI does not just answer but acts across many steps until the job is done: planning, calling tools, checking for errors, and fixing them itself. It differs from a chatbot in that it "really does" the work, and from drag-and-drop automation in that it is written in plain language and adapts while running.

Do I need to know programming? Not required. The AI writes the code; the learner handles the brief, reviews results, and keeps to the safety rules. Knowing the basics (such as the Claude Code courses in this series) makes it faster.

Is the DOE framework software I have to buy? No. It is a way of organizing folders plus one rules file: plain-language directives on one side, execution scripts on the other, and the AI in the middle orchestrating. You can build it with a free tool (Antigravity) or with Claude Code.

Why not just use n8n or Make? They are two different worlds: drag-and-drop tools need the path hard-drawn at build time and take quite a while to learn; agentic workflows are written as plain-language bullets and adapt while running. This series has a separate n8n course if you want to compare them hands-on, along with our straight opinion on where each one belongs.

Is it safe to let it run automatically? It is safe if you follow the rules: the part that goes to the cloud contains only deterministic scripts, with the AI staying where someone can watch; the four safety rules in the rules file (cost ceiling, no touching API keys, no carrying secrets out, logging); and anything high-stakes and error-sensitive always has a human approving.

How should a business without a tech team apply this? Start with the one workflow that eats the most hours, built following parts 5 and 6 using the SOP the company already has. Once it runs well in the workshop, then think about the cloud. If you want someone to build with you or to build the industrial version: MONA offers free consultation at 1900 636 648.

The next course in the series: n8n from A to Z: see the drag-and-drop automation world with your own eyes, to know where it is strong and weak compared with what you have just learned. See you there.

From lesson to practice: 14 ready-made AI Agent templates for Vietnamese businesses

Picture this: eleven at night, a customer messages asking for a shipping order code, the on-duty staff has gone to sleep, and by morning the customer is so annoyed they have canceled the order. That painful feeling of losing revenue is something we have met again and again across 14,000+ projects since 2016. To solve this once and for all, instead of fumbling from scratch, we just opened a library of fourteen free open-source virtual assistant templates on monagent.vn for you to download and try. This is the slimmed-down version of the AI Bear team running for real at the company, from Gấu Cười for customer care to Gấu Webmaster who watches the homepage. Just take a template, open it with Claude Code and have the machine read the AGENTS.md file, and the system analyzes it and builds a complete virtual employee on its own. Don't build the tools by hand. We once fell into that trap, letting the AI builder invent function names, and the whole system collapsed at the first step by calling functions that did not exist. Everything is already defined properly.

The workflow is very light. You can have the AI run on your own computer, or put it on a virtual server MONA Cloud located right in Vietnam. Our server rental starts at only 550 VND per hour, and when you shut it down, billing stops automatically. The key point we always tell customers: any system that runs automatically around the clock must have a clear budget ceiling. Our servers use a bank API service to top up a prepaid wallet via VietQR code, and when the money runs out the code returns a 402 error to stop the virtual employee immediately, never secretly charging beyond the business owner's control. Your business data stays safe on the server, you pay in Vietnamese dong with a monthly VAT invoice, and there are always MONA people on a Vietnamese-language hotline ready to help.

With that said, our advice is: don't install anything where you don't control the data. Download the template and test it, with the data staying on your own machine. The one-click deployment feature is still in beta, we state the status plainly on the page, and we never promise features that are not finished. The Zalo OA customer care version is waiting on a technical bridge, so don't rush to promise it to customers before you have it firmly in hand. If your business has a complex system and wants to bring an AI Agent course into real business operations, call 1900 636 648 and we will take care of it.