Single learning path · 8 lessons
Leave with a real company process redesigned for humans to direct and AI agents to execute, with the agent specification, quality criteria, and permission rules documented.
Lessons
Leave knowing the difference, in one of your own processes, between “AI on top of the old process” and a true redesign.
Leave with a real process mapped across input, decision, action, verification, exception, and outcome, with its delegable links marked.
Leave with a long-horizon request written and tested in an AI chat, with an approval checkpoint before anything is sent.
Leave with your process roles assigned across the human, coordinator agent, specialist agents, and verification.
Leave with your agent’s context inventory: what information it needs, where it is, and whether it’s accessible today.
Leave with your agent’s quality checklist: what counts as a correct answer, what errors are acceptable, when to stop, and when to call you.
Leave with your agent’s permissions matrix decided: read, write, send, buy, delete, approve, sensitive data.
Leave with the complete agent specification on one page and a simulated run completed in an AI chat.
Sources
Microsoft, Work Trend Index 2026 · Deloitte, State of AI in the Enterprise 2026, Agentic AI strategy, Agentic AI is scaling faster than guardrails e AI readiness research · OpenAI, How agents are transforming work · World Economic Forum, Future of Jobs Report 2025 · McKinsey, Rewiring talent strategy in the age of AI.
Single learning path · Lesson 1
By the end of this lesson, you’ll be able to look at a process in your company and point out, step by step, what is “AI layered on top of the old way of doing things” and what would count as a true redesign.
Your team already uses AI: someone asks it to write an email, someone else summarizes a contract, and another person generates an image. Yet the process still requires the same five people and the same forty steps. The latest research from Microsoft and Deloitte converges on an uncomfortable point: real gains don’t come from using AI better; they come from redesigning who does what. This lesson gives you a way to see the difference in your own work.
↓ scroll to study
Almost every company today “uses AI.” Someone opens a chat, asks for text, then copies and pastes it. The work gets a little faster, but the sequence of steps stays the same, with the same people handing work off in the same ways. Deloitte called this putting AI on top of the old process. It’s like replacing a typewriter with a computer and still printing everything to carry from room to room.
Redesigning is something else. It means asking: if an agent can carry out entire parts of the workflow, who still needs to do what? An agent here isn’t a chat that answers a question. It’s a program that receives an objective, accesses the company’s systems, performs several steps in sequence, and stops at the points you set to ask for your approval.
Accountant Roberto, from a firm with 40 clients, uses AI to write emails asking for missing documents. He saves ten minutes per client. But he still opens each folder, still checks what’s missing, still decides whom to contact. A redesign would ask: what if an agent checked all 40 folders on Monday morning, listed what was missing from each, and drafted the emails for Roberto to approve?
The sentence that organizes this entire course is simple: humans direct, and agents carry out increasingly large parts of the process. Directing means defining the objective, providing context, choosing limits, and deciding on exceptions. Carrying out means performing repeatable steps, consulting systems, preparing materials, and recording what was done.
Microsoft calls it Frontier Professionals people who already work this way: they use agents in multi-step workflows, redesign processes, and create usage standards for the team. The detail that matters most to you: in this group, the skills that increased most in value weren’t technical. They were AI quality control and critical thinking.
On the sales team at a distribution company, manager Cláudia directs the work: she sets the goal of reactivating customers who have been inactive for 90 days and requires that she review every proposal before it goes out. The agent does the work: it sorts the customers, pulls their purchase history, prepares an approach for each one, and queues everything for approval. Cláudia has gone from writing emails to directing a workstream.
Before
Cláudia opens the spreadsheet, filters for inactive customers, picks ten, asks the chat "write an email to reactivate a customer" ten times, edits each one, sends them, and records it in the CRM. A whole morning.
After
At 8 a.m., the agent delivers a list of the 30 inactive customers with the highest potential, each with a purchase history and a prepared approach. Cláudia reads it, revises three, approves them, and the agent sends and logs them. Forty minutes.
When a company decides to “bring in agents,” the impulse is to take the process as it exists today and replace people with AI at every step. The result is usually an equally slow process, except now no one can explain why step 14 exists. The more mature companies in Deloitte’s research do the opposite: they redesign roles and processes so AI can run the workflow from end to end, while people handle judgment, exceptions, supervision, and strategy.
So the right question to ask before any agent is not “how does AI do this step?” It’s “does this step need to exist if one agent does the previous three all at once?” Many process steps exist only because one person needed to hand work off to another. When the same agent does all three, the handoff disappears.
In the finance department of a retail chain, analyst Fernanda receives invoices, enters them in a spreadsheet, and sends the spreadsheet to a colleague to review. The colleague sends it back with comments, which she addresses before sending it to the manager. That’s four steps. If an agent classifies the invoices, matches them against the purchase orders, and flags discrepancies, only two steps remain: Fernanda reviews the discrepancies, and the manager approves. The other two steps existed only because the work was being handed from person to person.
Redesigning doesn’t remove people from the process. It changes the kind of work they do. McKinsey describes this as a hybrid workforce: people and agents working side by side, with humans focused on decisions, exceptions, and outcomes. Throughout this learning path, when you’re unsure whether something belongs to a human or an agent, test it against these four names.
Judgment it’s deciding when the rule doesn’t resolve the issue on its own. Exception it’s the case that fell outside the norm and needs someone who knows its history. Supervision it’s checking whether the agent got it right before the consequence occurs. Strategy it’s deciding which process is worth redesigning, and why. None of this is a small task. It’s the work that has always been most valuable and was buried under everything else.
Lawyer Marcos, at a labor law firm, spends hours preparing a summary of the case file for each new case. An agent can read the file, extract dates, parties, and claims, and prepare the summary. Marcos still handles deciding the legal strategy, assessing the case’s risk, and talking with the client. He doesn’t work less. He works on what only he knows how to do.
An agent doesn’t replace the decision-maker. It gives the decision-maker back the time that was tied up in the steps.
This isn’t a long-term bet. In Deloitte’s readiness survey, 74% of leaders expect that, in four years, almost half of business processes will have been redesigned or rebuilt around agents. And only 5% consider their own processes highly prepared today. The opportunity for people who learn to redesign processes lies between those two numbers.
The professional this course prepares you to be has a working title: AI work architect, or agent architect. It’s someone who can enter a company, look at a process that currently takes five people and forty steps, and explain methodically how it would work with humans and agents while maintaining control, quality, and accountability. Over the next seven lessons, you’ll build this method one piece at a time, always using one of your own processes.
For accountant Roberto, this means the firm that redesigns the monthly close first can serve 80 clients with the team that serves 40 today. For manager Cláudia, it means a competitor that redesigns customer reactivation can reach every inactive customer each week, while her team reaches ten. The opportunity belongs to whoever gets there first.
Test yourself
A company started using an AI chat to draft all its sales proposals. The process steps stay the same; each one just gets faster. According to this lesson’s criterion, this is:
Practice now 0/4 done
In about 10 minutes, choose a real process from your work and classify each step as “AI on top” or “candidate for redesign,” on paper or in a simple spreadsheet.
You’ll only write on your own sheet or spreadsheet. Nothing changes in the real process, no one needs to know yet, and if the process seems like the wrong choice in the next lesson, you can switch without any downside.
You’ve just done what most companies still haven’t: examined a real process using the right criteria. This worksheet is the raw material for the next seven lessons.
Summary
Single learning path · Lesson 2
By the end of this lesson, you’ll be able to map the process you chose into six steps (input, decision, action, verification, exception, result) and mark whether each step can be delegated to an agent.
The list of steps you made in the previous lesson shows what happens. It doesn’t show where the agent can step in safely or where it needs to stop. That’s where the skill the course’s source text calls the most important one for the coming years comes in: AI process engineering. It’s not about writing polished prompts. It’s about seeing the process through its structure, and the structure is always the same.
↓ scroll to study
AI process engineering means taking a real process from any area and asking methodically: which parts of this can be delegated to agents? The important word is methodically. Without a method, the answer becomes an opinion: one person says “everything,” another says “nothing,” and the process stays as it is.
The method is to rewrite the process in a fixed form with six links: input, decision, action, verification, exception, and result. Every business process, from sales to legal, fits this form. And each link has a different answer to the delegation question. That’s what makes the analysis repeatable from one process to another.
In the previous lesson, financial analyst Fernanda listed eleven steps for checking invoices. Eleven steps sound like eleven decisions. Rewritten as six links, they become: input (invoices arrive), decision (does this invoice match a purchase order?), action (record or set aside), verification (do the totals add up?), exception (invoice without a purchase order), outcome (report for the manager). Structurally, eleven steps were six links.
Input it’s what comes in and triggers the process: a request, a document, a message, a calendar date. Action it’s the step that changes something in the world: entering, classifying, sending, recording, calculating. Both have something in common: they can be described. You can explain to someone in five minutes what comes in and what to do with it.
Anything you can describe in five minutes tends to be delegable to an agent, with one condition: the action must be reversible or approved in advance. Adding something to a draft is different from sending it to a client. In this lesson, you only mark what’s delegable. How to control delegated actions is covered in lessons 6 and 7.
For accountant Roberto, the monthly close starts with bank statements and invoices that clients send by email or app by the 5th. The task is to classify each transaction under the right account. One morning, he explains the two to a new intern. That’s the signal: if it fits into a morning of training, it can fit into an agent.
The link decision it’s where most analyses go wrong, because they treat every decision as the same. They aren’t. There’s the decision that follows a rule: “if the amount is over 5,000, send it for approval.” An agent makes that decision better than a tired person at 6 p.m. And there’s the decision that requires judgment: “is this customer worth making an exception to the deadline?” That stays with someone who knows the history.
The way to separate them is the training question: would two well-trained people with the same information always reach the same answer? If so, it’s a rule, and it can be delegated. If two competent people could disagree, it’s judgment, and at most the agent can prepare the information for the person who will decide.
Lawyer Marcos gets a new case. “Is this case about labor law or civil law?” is a rule: the filing says. “Is it worth taking the case?” is a judgment: it depends on the risk, the client, and the law firm’s schedule. The agent classifies the practice area, prepares the summary, and presents the risks. Marcos decides whether to take the case.
Before
Marcos reads the entire case file for each new case, which takes about two hours, then decides in ten minutes whether to take it. Eight cases come in each week.
After
The agent reads the case files, classifies the area, extracts parties, dates, and claims, and puts together a one-page summary of the risk points. Marcos reads it in fifteen minutes and decides.
Verification it’s the step that checks whether the action was done correctly before the consequence occurs: the total matches, the name is correct, the amount is within the expected range. Exception it’s what happens when verification fails or something outside the norm comes in. Processes designed by people often have these two implicit links: someone “takes a look.” With agents, they need to be explicit.
Here’s a rule you’ll use through the end of the course: an agent can perform the verification, but exceptions always go to a human. The agent checks; if something doesn’t match, it stops and calls someone. This isn’t about distrusting the technology. It’s the same logic any team follows: the person doing the work checks it, and unusual cases go to the person who makes the decisions.
On manager Cláudia’s team, verification for customer reactivation means checking that each prepared proposal uses the current price list and doesn’t promise a delivery time of less than seven days. The agent checks both things in every proposal. The exception is a customer with an outstanding balance: the agent doesn’t contact them, but puts them on a list for Cláudia to decide what to do.
Test yourself
A proposals agent finds a customer whose purchase amount is three times the historical average. According to this lesson’s method, what should it do?
The sixth link, result, is what exists at the end that didn’t exist at the beginning: a report delivered, a customer answered, a reconciliation completed. It seems obvious, but most of the processes you’ll map have never had their result written in one sentence. Everyone in the chain knows their part, and no one has written down what the whole process delivers.
That’s why you map the six links from the end to the beginning. First, the result, in a sentence someone outside the process can understand. Then the input that triggers it. Only then do you map the links in between. Once the result is clear, many steps on your list from lesson 1 turn out not to contribute to it, and that’s where the redesign begins.
Fernanda, the financial analyst, wrote the outcome of the invoice review as “spreadsheet sent to the manager.” After rewriting it, it became: “the manager knows, by the 3rd, which invoices don’t match the order and why.” With that statement, two of the eleven steps—formatting the spreadsheet and sending a copy to the archive—no longer made sense. Nobody used them to achieve the outcome.
Write the outcome first. The steps that don’t lead to it were already unnecessary before any agent came along.
Practice now 0/5 done
In about 12 minutes, turn the list of steps from lesson 1 into a six-link map, written from end to beginning, with each link marked as delegable or human.
It’s still just your own paper or spreadsheet. No company system is affected. If a link doesn’t fit into any of the six boxes, note it in the margin and move on: in lesson 4, this usually resolves itself.
You’ve just done AI process engineering on your real process. This map will become an agent specification in the next lessons.
Summary
Single learning path · Lesson 3
By the end of this lesson, you’ll be able to write a long-horizon request for an AI, with an objective, context, constraints, success criteria, and an approval checkpoint, and test it in a chat you already use.
Today, you ask “write this email” and get an email: you keep thinking, choosing, and checking, while AI just types. The valuable professional of the coming years asks, “analyze, identify, prepare, record, and ask me to approve before sending.” OpenAI calls this a shift from isolated interactions to long-horizon delegated tasks. This lesson teaches you to write that request, and you’ll try it today.
↓ scroll to study
“Write this email” is a small task. The AI does one thing, returns it, and the next decision is yours again. “Analyze customers who haven’t bought in 90 days, identify those with the most potential, research their history, prepare an approach for each one, record it in the system, and ask me to approve it before sending” is a long-horizon goal. The AI performs a sequence of steps, uses tools, checks what it found, and iterates until it reaches a result, stopping where you told it to.
The difference isn’t the length of the text. It’s who carries the sequence: for a small task, you; for a delegated objective, the agent, while you step in at decision points. It’s the division from lesson 1, written into a prompt.
Lawyer Marcos used to ask AI “summarize this section” several times a day. Twelve requests per case. Now he asks once: “Read this case file, identify the parties, dates, and claims, point out the three biggest risks with the page where each appears, and prepare a one-page summary so I can decide whether to take the case.” One request, and he steps in only at the end.
Knowing how to direct AI, the second of this course’s six competencies, comes down to five elements that every long-horizon request needs. Goal: the result, in the sentence you wrote in lesson 2. Context: what the agent needs to know about your company to avoid being generic. Constraints: what it cannot do. Success criteria: how you’ll know it’s good. Approval point: where it stops and waits for you.
The five elements come directly from the six-step map: the objective is the result, context and constraints come from rule-based decisions, the success criteria are verification, and the approval checkpoint is where exceptions and judgment come in. You’re translating the map you already made.
For accountant Roberto, for the monthly close: objective, “all of Padaria Trigal’s March transactions classified under the accounts in the chart of accounts”; context, “the attached chart of accounts and our classification history from February”; constraint, “don’t create a new account; flag anything uncertain”; criterion, “the balance matches the bank statement”; approval point, “show me the questions before generating the report.”
You don’t need a new program. The most widely used chats in September 2026—ChatGPT, Claude, and the Copilot included with Microsoft’s package—accept attachments and run a sequence of steps from a single request. The button names differ; the logic doesn’t.
A reminder that applies to everyone: ask the AI to show the plan before executing it. This makes the chat work like an agent with an approval point, even without a connection to the company’s systems, which only comes in lesson 5.
Financial analyst Fernanda opens the chat her company already pays for, attaches the March invoice spreadsheet (she uses a copy with supplier names replaced by codes) and the purchase order list, and pastes in the prompt. The AI first responds with a five-line plan. Fernanda adjusts one line and says, “go ahead.”
How to run a long-horizon request in chat
When you delegate an objective to a capable person, they usually come back with two or three questions before starting. Agents are the same, and that’s a sign of quality, not weakness. A well-written request says explicitly: “if you’re missing information you need to decide, ask before assuming.” Without that line, AI fills in the gaps with what seems reasonable, and what seems “reasonable” to it may be wrong for your company.
The second thing a good agent does is show what it did. Always ask for a record: who was considered and excluded, which rule it applied, and what was uncertain. That’s what will let you supervise it, the topic of lesson 6. Without it, you have the result and faith.
Manager Cláudia included this in the prompt: “if a customer has an outstanding balance or an order in progress, don’t prepare outreach; put them on a separate list with the reason.” On the first run, the AI returned 27 outreach drafts and a list of 3 customers set aside, each with a reason. Cláudia didn’t need to ask anything. It was all in the record.
The first mistake is delegating without an approval checkpoint: “do everything and let me know.” If something goes wrong in step two, it has already affected steps three through ten. The approval checkpoint is where a cheap mistake stops before it becomes an expensive one.
The second is the opposite: a small task dressed up as a goal. “Analyze the clients and tell me what you think” has no criteria or constraints, so it returns an opinion that could apply to any company in the country. If you can’t say how you’ll know it’s good, the request isn’t ready.
Accountant Roberto asked, on his first try, “classify the entries and generate the report.” The AI made up an account called “general expenses” for 40 entries it couldn’t classify, and the report looked polished but was wrong. On his second try, he added the restriction “don’t create a new account; flag it as a question” and the approval checkpoint “show me the questions before the report.” It returned 40 questions, which he resolved in twenty minutes.
Common mistake
Pasting real customer data into the chat to "test quickly". This happens because chat feels like a private conversation, but it isn’t: it’s a service outside your company. To test, use a copy with names, documents, and amounts changed. You can test the request logic the same way, and no one at the company will have to explain later why the customer list left the building.
Practice now 0/4 done
In about 15 minutes, adapt the request below to the process you mapped, paste it into an AI chat, and get a plan of up to six lines to approve.
Use only fictional data or a copy with names, documents, and amounts changed: the chat is a service outside your company. Nothing is sent to any customer because the request ends before anything is sent. If the response seems odd, delete the conversation and paste it again with the missing piece.
Você vai atuar como meu assistente de processo. Antes de executar, me mostre o plano em até 6 linhas e espere minha aprovação. OBJETIVO: <o resultado do seu processo, na frase da aula 2. Ex.: preparar uma abordagem de reativação para cada cliente sem compra há mais de 90 dias> CONTEXTO: <o que a IA precisa saber da sua empresa. Ex.: vendemos material de construção para lojistas; a tabela de preços e a lista de clientes fictícia estão em anexo; prazo padrão de entrega é 7 dias> RESTRIÇÕES: <o que não pode. Ex.: não prometa prazo menor que 7 dias; não use preço fora da tabela; não aborde cliente com cobrança em aberto, coloque numa lista separada com o motivo> CRITÉRIO DE SUCESSO: <como vou saber que ficou bom. Ex.: cada abordagem cita o último produto comprado pelo cliente e tem no máximo 6 linhas> PONTO DE APROVAÇÃO: não envie nem registre nada. Ao terminar, me apresente as abordagens em lista, com um registro do que você considerou e descartou, e espere meu ok. Se faltar informação para decidir algo, pergunte antes de supor.
You’ve just delegated an objective, not a task, and kept the decision point with you. That request is the first version of your agent’s specification.
Summary
Single learning path · Lesson 4
By the end of this lesson, you’ll be able to distribute the steps in your process among a human, a coordinator agent, specialist agents, tools, and verification, and draw that chain on a sheet of paper.
The request you ran in the last lesson worked because it was a medium-sized process in a chat, with you watching. As the process grows, a single agent starts to lose track: it confuses research with writing, forgets the rule from the beginning by the time it reaches the end, and no one checks its work. Companies getting results from agents don’t use just one agent. They use a chain, with separate roles. Building that chain is worth far more than knowing how to use a chat.
↓ scroll to study
When a process has five different types of work—research, classification, writing, calculation, and checking—a single agent with one giant request tends to do all of them moderately well. The reason is the same as with any team: someone who does everything excels at nothing, and by the time they reach the end, the instruction at the start of the request is too far behind them.
That’s why companies getting results don’t design “one agent for the process.” They design “one agent for each type of work, and one to coordinate them.” Each specialist gets a short instruction, a small context, and a clear task. That’s easier to manage because each piece is small enough for you to understand what it does and check whether it did it right.
Lawyer Marcos tried a single request: “Read the case file, summarize it, point out risks, suggest a legal strategy, and write the client letter.” The summary was good, the risks were superficial, and the letter had the wrong tone. He split it into three: one specialist that only extracts facts from case files, one that only assesses risks based on those facts, and one that only writes for clients without legal training. Each did better than the giant request, and he could tell where to make changes when something came out poorly.
The chain you’ll learn to build is always the same, in any field: human defines the objective; one coordinator agent receives the objective and breaks it down; specialist agents execute each part; they use tools (read a document, calculate, search); the tools reach the company systems (spreadsheets, customer records, email); a verification checks the set; and the human receives the result and decides on exceptions.
Notice what this does to your worksheet from lesson 2. The six links don’t disappear; they get assigned owners. Input and action go to specialists. Rule-based decisions go to the coordinator. Verification becomes a role of its own. Exceptions and judgment return to the human at the end. The map and the chain are the same process, seen from two angles: what happens and who does it.
For sales manager Cláudia, the customer reactivation chain works like this: she defines “reactivate customers who haven’t bought in 90 days, without promising a turnaround shorter than 7 days”; the coordinator divides the work into three areas; one specialist pulls the list and history from the customer database, another writes the outreach messages, and another checks prices against the price list; the verification checks everything against the constraints; Cláudia approves, and the messages go out.
The most misunderstood role in the chain is the coordinator. It doesn’t research, write, or calculate. It receives the human’s goal, decides how many parts to split it into, gives each part to the right specialist with the right context, waits for the results, combines them, and sends them for verification. If a specialist comes back with a question, the coordinator decides whether to answer using a rule it already has or escalate the question to the human.
Think of a restaurant maître d’. They don’t cook or serve, but without them each table gets its food at the wrong time. The coordinator makes the chain feel like a single job to you, even though there are five jobs underneath. They’re also where you write the rules for “when to stop and call a human,” because they’re the only one who sees the whole process.
For financial analyst Fernanda’s invoice review, the coordinator receives the task: “check the 200 March invoices against the purchase orders.” It divides the work: one specialist reads and classifies the invoices, another looks up each matching purchase order, and another compares the amounts. When the comparison specialist finds 14 discrepancies, the coordinator doesn’t try to resolve them. It makes a list with the reason for each one and sends it to verification and Fernanda.
Before
One 40-line request for a single agent. When the result was wrong, Fernanda didn’t know whether the mistake was in reading the invoice, finding the order, or comparing them, so she redid everything.
After
One coordinator and three specialists, each with an 8-line request. When a discrepancy is wrong, the record shows which specialist introduced it, and you adjust only that one.
An agent that only chats doesn’t execute anything. To take action, it needs tools: read an attached document, do a calculation, search a database, write to a spreadsheet, prepare an email. And the tools need to reach the systems of the company. Here’s a word you’ll hear a lot and don’t need to fear: API. An API is a system’s service port, the door another program uses to request or leave information without anyone clicking on a screen. Almost every modern business system has one.
You’ll also hear MCP, which works like a standardized outlet: instead of each agent needing a custom adapter for each system, everyone uses the same connection. For you, the architect, that means one practical question per system: does it have a service port, and who at the company knows how to open it? Building it is the job of the technology team. Deciding what the agent can access is yours.
Accountant Roberto listed the closing systems: the accounting software, the app clients use to send receipts, and the bank, via statements. The accounting software has an API, the provider confirmed. The app exports a spreadsheet each day. The statement comes as a file from the bank. Three systems, three ways to access them, and none require Roberto to program anything.
Test yourself
A specialist in the chain sent the coordinator a question: “Customer X has two records in the system. Which one should I use?” Who should resolve it?
The last step before a human is verification, and it deserves a separate agent with separate instructions. The reason is the same one companies use to separate the person who pays from the person who approves the payment: people tend to think they did things correctly. A verifier that receives only the result and success criteria, without taking part in the work, finds errors the person who did the work can’t see.
The verifier doesn’t judge whether something is good. It checks against written criteria: prices match the list, no deadlines are under seven days, and every client on the separate list has a reason. What passes goes to the human for approval. What doesn’t pass goes back to the coordinator with the reason. And anything unusual that isn’t covered by a criterion is flagged and escalated. It’s the first line of quality control, covered in lesson 6.
At Marcos’s law office, the verifier receives the one-page summary and the case file, then checks three things: every date cited appears in the case file on the page indicated; the parties’ names are exact; and no claim from the filing was left out of the summary. Last week, the verifier caught a summary that changed the amount in dispute. The specialist who wrote it wouldn’t have noticed. Marcos might have missed it too if he’d been reading quickly.
A chain of agents isn’t more complex than a single agent. It’s easier to direct because each piece is small enough for you to check.
Practice now 0/4 done
In about 12 minutes, distribute the links from your lesson 2 map across the seven positions in the chain, on a sheet with seven columns.
It’s a drawing on paper or a spreadsheet. No agent is created, and no system is connected. If a link doesn’t fit anywhere, leave it in the margin: that’s normal, and lesson 5 usually shows why (usually there’s missing context, not a missing position).
You’ve just designed an orchestration chain for a real process. This design gives a technology team what it needs to know what to build, and you did it without writing a line of code.
Summary
Single learning path · Lesson 5
By the end of this lesson, you’ll be able to build your agent’s context inventory: every piece of information it needs, where it is now, its format, and whether it’s accessible or stuck in someone’s head.
Two companies run the same chain with the same request. At one, the result is generic and useless. At the other, it seems like it was produced by someone on the inside. The difference isn’t the AI model. It’s what the model had at hand: documents, procedures, customer records, rules, history. Deloitte points out that data that is hard to search and reuse is one of the biggest obstacles to agent automation. And most of that context probably already exists at your company. It’s just not somewhere an agent can access.
↓ scroll to study
An AI model without context knows a lot about the world and nothing about your company. It’s a recent graduate on their first day: writes well, reasons well, and doesn’t know who the most important customer is, which discount rule applies, or that the “general expenses” account was prohibited in 2024. Asking it to “prepare the proposal” produces a proposal that would work for any company in the country.
The same intern, after a month with the procedures folder, proposal history, and price list, becomes useful. With agents, that month doesn’t exist: the context has to be provided all at once, in writing, where the agent can access it. The fourth competency in this course, integrating systems, starts here, and the part that’s up to you isn’t technical. It’s knowing what the agent needs and where it is.
Lawyer Marcos asked the agent for a summary “in the firm’s standard format.” It returned a generic summary because the firm’s standard existed in three places: an old template in a text file, the secretary’s head, and a 2023 email. When he brought all three together in a two-page document and attached it, the summary followed the standard. The agent didn’t get better. It got the context it needed.
When the source text talks about connecting the agent to the company, it lists what turns an agent into a digital worker: documents (contracts, proposals, reports), procedures (how we do things here), the CRM (customer records and history), the ERP (orders, inventory, invoices, accounts), email, o database (the tables underneath the systems), metrics (the numbers leadership tracks), rules (limits, approval authority, deadlines) and internal knowledge (what only someone who’s been there for years knows).
No agent needs all nine at once. But every process you map uses at least four, and most people remember only two. This list is here to help you remember the others.
For customer reactivation, sales manager Cláudia marked customer records (purchase history), rules (minimum time and price list), email (recent conversations with each customer), and internal knowledge (the salesperson who covered the area knows who had a dispute with the company in 2022). Four sources. Only the first was in a system.
Test yourself
A reconciliation agent received the statements and invoices, and still classified 40 transactions under a prohibited account. Which source of context was most likely missing?
Deloitte used two words for the obstacle: data that is hard to search and hard to reuse. Searchable means an agent can find the information when needed, without someone pointing it out. A procedure in a shared folder with a clear name is searchable. The same procedure in a photo of a whiteboard on someone's phone isn't. Reusable means the information is useful for the next case without rework. A price table in a spreadsheet is reusable. The same table in a scanned image file isn't.
The good news is that making context searchable and reusable almost never requires technology. It requires someone to write down what was in their head, save it with a clear name, and replace images with text. It takes an afternoon per process, and it’s the work most companies skip as they go straight to “let’s put the agent in place.”
Accountant Roberto discovered that each client’s chart of accounts was in the accounting software and searchable. But the classification rule (“machine rental is a cost, not an expense, for Padaria Trigal”) was only in his and his assistant’s heads. He spent an afternoon writing a document for each client, half a page each. It was the best-spent afternoon of the year: now both the agent and the new assistant classify things the same way.
Common mistake
Assuming “it’s all in the system,” then discovering in the first run that the deciding information is in someone’s head. This happens because the system stores what happened (entries, orders, emails), not the criteria behind the decisions. Before connecting any agent, spend an afternoon interviewing the people who do the process today and writing down the criteria. If that person went on vacation tomorrow, what would no one know? That’s the missing context.
In September 2026, context reaches an agent through three paths, from the simplest to the most permanent. The first is the attachment: you provide the document in the conversation, as you did in lesson 3. It works for testing and small processes. The second is the project folder that ChatGPT, Claude, and Copilot offer: you store the documents and instructions there once, and every new conversation for that project starts with them. It works for a process that runs every week.
The third is the direct connection to the systems, through the service interface in lesson 4, where the agent retrieves up-to-date information on its own, without anyone attaching anything. This is the path to turning the process into a real digital worker, and it’s the only one of the three that requires someone in technology to set up. It may seem complicated, but it works like an authorization form: you decide which systems the agent can access and sign off; the person who manages the system builds the connection.
Financial analyst Fernanda started with path one: she attached the invoice spreadsheet and the purchase order spreadsheet every week. After a month, she moved to path two: she created a project folder with the checking procedure, supplier list, and tolerance rules. Today, she only attaches that week’s invoices. Path three, connecting directly to the purchasing system, is with the technology team, with her design in hand.
The context inventory is a simple table and the artifact for this lesson. For each piece of information the agent needs, use five columns: what it is, where it is now, its format, whether it’s accessible (searchable and reusable), and who owns it. The owner column is the most important and the most often forgotten: without someone responsible, the context gets outdated, and the agent starts making decisions based on last year’s price list.
Once the inventory is complete, the problems reveal themselves. Rows with “in so-and-so’s head” in the where-it-is column mean an afternoon of writing things down. Rows with “scanned image” in the format column mean an hour of data entry. Rows without an owner mean a conversation with the manager. None of this is technology. All of it is what separates a generic agent from one that feels like part of the company.
Lawyer Marcos’s inventory for the case-file summary has six rows: the case files (court system, PDF, accessible, owner: him); the summary template (new document, text, accessible, owner: him); the firm’s list of legal arguments (in his head, to be written down, owner: him); the fee schedule (spreadsheet, accessible, owner: partner); the history of similar cases (firm system, accessible, owner: secretary); and the risk criteria (in his head, to be written down). Two afternoons of writing, and the inventory is complete.
The five columns of the context inventory
Practice now 0/4 done
In about 12 minutes, list all the information your process uses in a five-column spreadsheet, including where it is, its format, whether it’s accessible, and who owns it.
It’s your spreadsheet, with no customer data in it: you note where the information is, not the information itself. If you don’t know who owns a row, write “?” and move on. The question mark is already a finding.
You’ve just discovered where the knowledge of your process really lives, and how much of it an agent could reach today. Few companies have this map for any process.
Summary
Single learning path · Lesson 6
By the end of this lesson, you’ll be able to write your agent’s quality worksheet: what counts as a correct answer, which errors are tolerable, when it should stop, when it should call you, and how to test it before running it for real.
When AI only answered, a mistake cost you another read-through. When it takes action, it can mean a proposal sent with the wrong price or a transaction entered under a prohibited account. Microsoft found that the most advanced professionals put much more weight on quality standards, documentation, and outcome evaluation than beginners do. That’s what separates people who keep agents running from those who shut them down after the first scare. Evaluation and supervision are the course’s fifth competency, and the one that will grow the most.
↓ scroll to study
When the first round of results looks good, the natural reaction is “it worked.” But that doesn’t tell you in how many cases, what error slipped through, or whether it will work next week. We accept this imprecision from a person because they learn and correct themselves. An agent follows its instructions forever, including the mistake.
The right question has five parts, answered in writing before the agent touches anything real: what counts as the right answer; which errors are tolerable; when to stop; when to call a human; and how to test beforehand. Together, they make up the quality checklist, the deliverable for this lesson.
Sales manager Cláudia ran the customer reactivation and thought it worked: the 27 outreach drafts were well written. Two weeks later, she found that three mentioned a product the company had stopped selling in 2025. Well written, but wrong. “It worked” wouldn’t have caught that. “Every outreach message only mentions products in the current catalog” would have.
Defining the correct response is where most people get stuck, because they try using adjectives: “well-written,” “complete,” “professional.” You can’t verify adjectives; you can verify observable conditions. A correct approach “mentions the most recently purchased product, is no more than six lines long, doesn’t promise a turnaround of less than seven days, and ends with a question.” Any reviewer, human or agent, can check that.
The fastest path: five real outcomes produced by people, three good and two bad, and the question “what do the good ones have that the bad ones don’t?” The answers become conditions. Save the five: they’re the first test set, covered in step 05.
Lawyer Marcos picked five case summaries he had written over the year. The good ones had these things in common: every date had the corresponding case-file page beside it; the claims from the filing were listed in the same order as in the filing; and the amount in dispute was on the first line. The bad ones mixed facts and opinions. Those became four conditions. The fifth, “no opinions before the risk section,” came from the bad ones.
Tolerable errors may sound like heresy to people who work in accounting or law. But every team tolerates errors; they just don’t write down which ones: a misplaced comma, yes; the wrong price, no. Writing this down keeps the agent from stopping over trivial things and ensures it never lets important issues slip through.
The scale has three bands. Tolerable: the error is cosmetic or reversible in seconds, so the agent proceeds and records it. Blocking: the error changes the outcome for the customer or the company, so the agent stops and calls for help. Prohibited: the error has irreversible consequences, and the agent isn’t even allowed to go near it, which is the subject of lesson 7. Each condition on the checklist gets a threshold.
For accountant Roberto, during the close: a transaction description abbreviated differently from the standard is tolerable. A transaction classified under an existing but incorrect account is blocking: stop and show it. Creating a new account in the client’s chart of accounts is prohibited: the agent doesn’t have permission, even if it’s certain.
Before
Roberto reviewed all 600 closing entries one by one because he didn’t trust any of them. Three hours per client, and errors still slipped through in hour 3.
After
The agent records what’s tolerable, stops at what’s blocking, and never reaches what’s prohibited. Roberto reviews only the list of blocking items: 14 entries, each with its reason. Twenty minutes.
The third and fourth parts of the checklist are often confused. When to stop it’s the condition that makes the agent stop its own execution: it found a blocking error, lacks information to make a decision, or hit a limit (more than 50 customers, more than an hour, or an amount above a cap). When to call it’s the condition that wakes someone up, and it doesn’t always mean stopping. Many stops only need to be logged for the next day’s review.
Separating the two avoids the extremes that kill agents: one that interrupts you twenty times a day and gets turned off within a week, and one that never calls and is found to be wrong too late. Good design means making few calls, each for a reason worth interrupting you.
Financial analyst Fernanda defined the rules: the agent stops and records every invoice without a matching purchase order and every discrepancy above 2%. It calls Fernanda right away in only two cases: a discrepancy above 5 thousand reais, or more than 20 invoices stopped on the same day, which points to a problem with the file, not the invoices. For everything else, she checks the list in the morning. Interruptions dropped from 30 a day to one or two a week.
Test yourself
A proposals agent found 3 customers with incomplete records out of 30. Based on this lesson, what should it do?
Testing before a real run doesn’t require technology. It requires a test set: 10 to 20 real situations from the past, with the answer a competent person gave at the time. Run the agent on them with anonymized data and compare: in how many cases did it meet every condition? What ranges did the errors fall into?
Deliberately include difficult cases: last year’s exception, the customer with two records, the invoice without an order. Getting 15 easy cases right proves nothing; getting 12 out of 15 right with the difficult ones included, and stopping correctly on the other three, means you’re ready to run it with supervision. And you don’t throw the test set away: run it again whenever the instructions change.
Manager Cláudia put together 15 cases: 10 common ones, 2 with an outstanding balance, 1 with duplicate records, 1 with an order in progress, and 1 involving a customer who had a dispute with the company in 2022. The agent got the 10 right, set aside the 3 it should, stopped on the duplicate record, and contacted the customer who had the dispute because that information wasn’t recorded anywhere. She wrote the rule, flagged the customer in the records, and ran all 15 again.
An agent isn’t approved because it looks good. It’s approved because it passed the same cases a competent person would, including the difficult ones.
Practice now 0/5 done
In about 15 minutes, write the five parts of the worksheet on one page (correct response, tolerance, stop, call, test) for the process you’ve been working on, and list the first 10 test cases.
It’s your document. No agent runs in this exercise. For the test set, you only note the case name and where it is (“March note 4412”), without copying sensitive data. If a tolerance range seems wrong, leave a note and change it later: the record is a living document.
You’ve just written what most companies discover they were missing only after their first costly mistake. With this scorecard, anyone on your team can evaluate your agent, not just you.
Summary
Single learning path · Lesson 7
By the end of this lesson, you’ll be able to fill in your agent’s permissions matrix, deciding for each action (read, write, send, buy, delete, change, approve) whether it can do it, can do it with approval, or cannot do it, and which sensitive data must stay out of its reach.
When AI only answered, permissions weren’t an issue: the worst that could happen was a bad response. When it takes action, the worst is an email to the wrong customer, a duplicate payment, a deleted record. Deloitte measured this: only about 21% of companies say they have mature governance for agents. The others are giving agents permissions they wouldn’t give an intern on their first day. This lesson sets you apart from that group.
↓ scroll to study
Agent governance is the set of decisions about what the agent can do, what it can use, and who is accountable for it. The source text sums up the shift in one sentence: the more AI moves from answering to acting, the more important it becomes to control permissions. You can read and discard a wrong answer. A wrong action happens in the world, and you find out afterward.
Your company already has governance for people, even if you don’t call it that: who approves purchases, who has the bank password, who signs contracts, who can see payroll. Agent governance follows the same logic, applied to a worker without the common sense to fill in what wasn’t written down. What’s implicit for a person goes in the matrix for an agent.
Accountant Roberto has a new assistant and, without thinking about it, applies governance: she enters transactions, but doesn’t close the month without his review; she can see the statement, but doesn’t have the bank password; she can send document follow-up emails, but not fee collection emails. He never wrote this down. For the agent, he’ll have to, and he’ll discover he already knew the answer.
The source text lists the questions the company needs to answer: who can read, write, send, buy, delete, change, approve, and access sensitive data. The first seven are actions, and each carries increasing risk. Read doesn't change anything. Write creates something new, in a draft or record. Change changes something that already existed. Send takes something from inside the company and moves it outside. Buy costs money. Delete destroys what can’t be brought back. Approve it’s the decision itself.
For each action, answer three questions: can (does the work and records it), can with approval (prepares, shows, a person releases), not allowed (the tool doesn’t even exist for it). The rule that resolves 80% of the matrix: reading and writing a draft are usually “allowed”; changing and sending, “with approval”; buying, deleting, and approving, “not allowed” in the first version. After months of passing test runs, you loosen one level at a time.
Sales manager Cláudia filled it in: read customer records, allowed; write outreach as a draft, allowed; change the record (mark “contacted on”), requires approval; send the email, requires approval; apply a discount (spend margin, in other words), not allowed; delete a contact, not allowed; approve its own outreach, not allowed. Seven rows, ten minutes.
Before
“The agent has access to the sales system.” One sentence, with no distinction between reading, changing, and sending. In the second week, it updated a customer’s list price because it interpreted “adjust the proposal” as “adjust the customer record.”
After
Seven rows in the matrix. Changing a record requires approval, and the list price field is out of reach. The same ambiguous instruction now generates a question, not a change.
The eighth question is different from the previous seven. It’s not about what the agent does, but what it can see. Sensitive data is anything that, if exposed, harms a person or the company in a way that can’t be undone: identity documents, health data, salaries, bank details, trade secrets, information about minors. The rule here isn’t “with approval.” It’s this: if the agent doesn’t need the data to do its job, the data stays out of reach, period.
The agent almost never needs it. To reactivate a customer, it needs their purchase history, not their CPF. To check an invoice, it needs the amount and supplier, not bank details. For each piece of data, ask: would the work come out the same without it? If so, leave it out. And know how each piece of data gets in: an agent connected to an external chat, like the one you used in lesson 3, is a path out of the company, and anything that passes through it goes outside.
Lawyer Marcos stopped when it was time to connect the agent to case files: cases contain names, documents, and sometimes health reports. He decided on two layers. For the risk summary, the agent sees the case file, but runs in an environment contracted by the law office, with a confidentiality agreement, rather than in a free chat. For the client letter, the agent gets only the summary, with documents and health data already removed. The same process, two levels of access.
A matrix without a “who’s responsible” column is a wish list. For every row where the agent can act, one person owns the permission: they grant it, review the record, and answer if something goes wrong. This isn’t about finding someone to blame; it’s about making sure someone is keeping an eye on things. No one reviews permissions without an owner, and they expand on their own.
Along with the owner comes the record: every agent action is recorded along with what it did, when, and based on what. It’s the same record lesson 3 asked you to require at the end of the prompt, now mandatory and saved. If a client asks “why did I receive this email?”, the person who owns the permission opens the record and answers in a minute. Without a record, the answer is “it was the AI,” and that answer doesn’t help anyone.
Financial analyst Fernanda owns three permissions for the invoice-checking agent: read invoices and purchase orders, write the discrepancy list, and change an invoice’s status to “checked.” Her manager owns one: approve payment for checked invoices, which the agent cannot do; it can only prepare them. When the audit asked why invoice 4412 was paid, Fernanda opened the record: checked by the agent at 8:12 a.m., amount matched purchase order 887, approved by the manager at 10:30 a.m.
Test yourself
A customer service agent has permission to “change the delivery address, with approval.” A customer requests the change at 10 p.m. What happens?
After an agent has been running well for a month, the temptation is to give it everything at once: “it’s proven itself, it can send directly.” The rule from people who’ve been running agents for years is the opposite: start with the tightest matrix that still lets the work happen, and loosen one permission at a time, always after the lesson 6 case set passes again with the new permission. One step, one case set, one month of clean records. Then the next step.
It's slow on purpose. Deloitte called this moment "agents scaling faster than safeguards," and the 21% measure that. Those who loosen things gradually reach the same place as the impatient, without the incident that makes leadership shut everything down and lose a year. The agent architect maintains that pace.
Accountant Roberto started the closing agent with “read” access to everything and “write” access only to drafts. Month 2: write directly to the accounting software, while closing was still blocked. Month 4: change the classification of tolerable entries without approval. Month 6: send the report to the client after their approval. Close the month on its own? Roberto says maybe never. And that’s fine.
Give the agent the permissions you’d give someone on their first day. It will have many first days, one step at a time.
Practice now 0/4 done
In about 12 minutes, read the case, decide on its agent’s permissions matrix, compare it with the answer key, and then fill in the matrix for your own agent.
This exercise is on paper by design: granting an agent real permission is the only action in this course that could have irreversible consequences, so you practice the decision with a sample case before making your own. Nothing is configured in any system, and you keep the matrix to take to the person responsible for technology.
The case. Norte Distributors sells building materials to 900 retailers. Sales manager Helena designed a customer reactivation agent: it reads customer records, identifies those who haven’t bought in 90 days, and prepares outreach. The team also wants it to update records with “contacted on,” send emails directly, and apply discounts of up to 5% to speed things up. Each customer record contains the company’s legal name, CNPJ, purchase history, credit limit, bank details for payment slips, and the store owner’s name and mobile number. The agent will run on an AI service contracted by the company, under a confidentiality agreement.
You’ve just decided, in writing, what your agent can and can’t do, with one person responsible for each row. That puts your process among the few Deloitte would call mature in governance.
Summary
Single learning path · Lesson 8
By the end of this lesson, you’ll be able to bring together everything you wrote in the seven lessons into a one-page specification and run a simulated rehearsal of the agent in an AI chat before building anything.
You have a process, a map, a request, a chain, an inventory, a quality scorecard, and a permissions matrix on separate sheets. Separately, they’re exercises. Together, on one page, they’re what a company can build—and what almost no company has today. Here, you stop “using AI” and start redesigning work. The source text gives this a name: AI work architect.
↓ scroll to study
If you think “programmers are the ones who win in the end,” this section disagrees. The source text is clear: the advantage goes to accountant + AI, lawyer + AI, salesperson + AI, manager + AI. Deloitte says the same thing: AI skills need to come with domain expertise. AI multiplies the impact of people who understand the problem, and you can’t multiply zero.
Notice what you did: you chose the process because you know the company, separated rules from judgment because you know where competent people disagree, wrote the quality criteria because you’ve seen good and bad results, and decided on permissions because you know what you wouldn’t give a new employee access to. A programmer wouldn’t do any of that better. Building the connection is the cheapest part to hire for.
Financial analyst Fernanda started lesson 1 with eleven steps for checking invoices. Today she has an agent specification that her company’s technology team estimated would take three weeks to connect to the purchasing system. She didn’t write code. She wrote what no one on the technology team would know: a 2% discrepancy is tolerable, an invoice without a purchase order means stop, the manager approves payment, and the agent never.
The course promised six competencies, and it’s worth naming where each one happened. Thinking through processes: lessons 1 and 2. Knowing how to direct AI: lesson 3, the request with five parts. Build agents: lesson 4, the chain. Integrate systems: lesson 5, the context inventory. Evaluate and supervise: lessons 6 and 7, the checklist and matrix. Deep knowledge of a business: you brought it from home, and it’s what made everything else work.
The World Economic Forum identifies AI and data as the fastest-growing skills through 2030, and keeps analytical thinking, creativity, leadership, and continuous learning among the core skills. These six skills bridge the two lists.
Lawyer Marcos and sales manager Cláudia took the same course and came away with completely different specifications: his was full of restrictions on sensitive data, while hers was full of rules about when to reach out. Neither could have written the other’s. That’s what “business expert + AI” means.
In your profession, the process that takes ten usually looks like this:
The source text proposes the most important strategic shift: instead of dozens of chatbots, choose ten critical processes and turn them into agent-powered work systems. You’ve built one. Ten is a one-to-two-year program for a midsize company, and each one follows the seven steps you’ve completed. The method doesn’t change; the content does.
How do you choose? Three questions: Does it repeat at least every week? Does it involve more than two people or more than ten steps? When it’s late or goes wrong, does it cost money or a customer? Three yeses, and it goes on the list. Start with the process that has the most green lines in the context inventory: it delivers results faster and builds trust for the other nine.
Accountant Roberto listed seven office processes, all with three yeses: closing, client payroll, monthly filings, business formation, document follow-up, fee collection, and questions. He started with closing because the chart of accounts was already in a system. Document follow-up comes next: it feeds into closing, and one agent feeds the other.
The specification is the document you give to whoever builds the agent and use to direct it. Seven blocks, each one of your worksheets summarized in three to eight lines. Nothing is new: the work here is compression, and the whole thing fits on one page, two sides at most.
One page is a constraint by design. The person building it reads the whole thing; the approver does too; and six months from now, you can reread it in five minutes and remember why you made each decision. No one reads a 20-page specification, and the agent ends up built from what someone remembered from a conversation.
Manager Cláudia’s specification fits on one page. The sales director read it in eight minutes and asked one question: “why can’t the agent give a 5% discount?” She pointed to the row in the matrix and the reason. Approved.
The seven blocks of a page specification
Before building, you can rehearse the entire agent in an AI chat today. Paste in the specification and ask the chat to play the coordinator, follow the chain, apply the worksheet, and respect the matrix, running one case from the test set with fictional data; at the end, ask it to point out what it still needs to make a decision. This may seem like a trick, but it works like a dress rehearsal: the set doesn’t exist yet, but you can already test the script and stage directions.
The rehearsal shows where the coordinator didn’t know whether to stop, where a rule was missing, and where the matrix was too loose—all before spending an hour on technology. Try three cases: a common one, a difficult one, and an exception. Fix them and run them again. When all three pass, the page goes to the person who builds it.
Lawyer Marcos pasted in the specification and asked for a simulated review of a fictional case. In the middle of it, the chat, acting as coordinator, asked: “The client is a company, but the fee schedule only lists individuals. What should I do?” The specification didn’t cover that. He added one line to the checklist and another to the inventory. Ten minutes, two gaps filled.
Practice now 0/4 done
In about 15 minutes, condense the seven sheets into one page, paste it into an AI chat with the request below, run a fictional case from the test suite, and get a list of gaps in your specification.
The specification contains no customer data: it has rules, system names, and criteria. The case uses fictional names, documents, and amounts. No agent is built, and no system is touched: the chat is only role-playing. If the simulation invents a permission you didn’t grant, that’s a finding, not your mistake: make a note and tighten the matrix.
Vou colar a especificação de um agente para um processo da minha empresa. Faça o papel do AGENTE COORDENADOR num ensaio simulado. Regras: 1. Siga a cadeia (coordenador, especialistas, verificação) e narre cada passo em uma linha: quem fez, o que fez, com base em qual regra da especificação. 2. Respeite a matriz de permissões à letra. Ação "com aprovação": pare e me peça aprovação. Ação "não pode": diga que não pode e siga. 3. Aplique a ficha de qualidade: para cada condição, diga se o caso atendeu e em que faixa caiu qualquer erro. 4. Se faltar informação, NÃO suponha. Pare e pergunte, dizendo qual bloco da especificação deveria ter a resposta. 5. Ao final, liste em até 8 itens o que FALTOU na especificação para você decidir sozinho, por ordem de importância. Os dados do caso são fictícios. Não envie nem registre nada de verdade. === ESPECIFICAÇÃO === <cole aqui a sua página: processo e resultado, mapa, pedido, cadeia, inventário, ficha de qualidade, matriz de permissões> === CASO DA BATERIA (fictício) === <a entrada que chegou, com nomes e valores inventados. Ex.: "cliente Ferragens Sol, sem compra há 120 dias, último produto: 40 sacos de cimento em maio, cobrança em aberto de 1.200 reais"> Comece narrando o passo 1 do coordenador.
You’ve just rehearsed a process redesigned for humans and agents, with controls, quality, and accountability spelled out before spending an hour building. This page is the work of an agent architect.
Summary