LOOP-R · Track 05 · Application
Follow two loops from start to finish—one sales loop with four real cycles and one support loop—and leave with your own loop assembled: a complete worksheet, its first cycle designed, and a filled-out decision card.
Lessons
Read the clinic loop’s four real cycles—a veto, a discard, a new test, and a promotion—and predict what the fifth should test.
Sketch a support loop on paper—what it optimizes and monitors—and run the Observer on 20 tickets in your AI chat.
Complete the loop worksheet with five answers and your first decision card, and take the 13-question canvas with you.
Track 05 · Lesson 1 · tool
By the end of this lesson, you can read the clinic loop’s four cycles, explain why each idea was vetoed, discarded, or promoted, and identify what the fifth cycle should test.
You have already seen each part of the loop separately: worksheet, spreadsheet, guardrail, card. Now you’ll see them working together with real numbers—including a ten-point gain that was discarded. This is how the loop will behave in your business.
↓ scroll to study
This lesson’s case is LOOP-R’s reference example: a beauty clinic that sends proposals over WhatsApp. First, a note about the numbers. The nine assistants ran for real: every veto, verdict, and report is their unedited output. The proposals and client responses, however, are simulated to reflect a real effect. This case shows how the loop responds to a genuine improvement—it did not discover the improvement by itself.
The clinic owner—let’s call her Renata—answered the five questions on the loop worksheet. Measurable goal: convert proposals into paid packages, from 3% to 5%. Source of evidence: the tracking spreadsheet, one row per proposal, about 50 per week. What never changes on its own: discounts above 10%, promises about results or timing, contacting anyone who asked to opt out, or naming a competitor. Limit: R$ 50 per cycle, weekly cycles, up to three ideas at a time, one test at a time. Approver: Renata herself, with seven days to respond.
The system returned a proposal she only had to confirm: first test the signal metric —response rate, from 20% to 30%—and monitor conversion from a distance. Reason: proving 3% versus 5% takes about 1,500 proposals per version; at 50 per week, that would take 60 weeks. Response, 20% versus 30%, takes about 300. It also came with three guardrails: average margin, complaints, and opt-out requests.
How to read a cycle in four lines
The Observer reviewed 200 proposals. The Critic spotted the pain point: 166 of them, 83%, received no response within 48 hours. It also found a discrepancy: the worksheet said conversion was 3%, while the spreadsheet showed 2.5%. It flagged this as it should—the worksheet records what the person believes; the spreadsheet records what happened.
The Optimizer wrote down three ideas. First: close the proposal with a forced-choice question such as “would you rather start this week or next?” Second: cap the message at 80 words. Third: open by mentioning something specific from that client’s review instead of using the same greeting for everyone. The Guardian vetoed the first idea before any test: a forced choice assumes the purchase and sets a deadline, creating predictable pressure that can lead to complaints and opt-outs. A veto is final; the Guardian does not suggest an alternative.
Then came the calculation. The Optimizer expected response to rise from 17% to 22%. The Experimenter calculated that proving this difference would take 40 weeks. Renata resized the test around the worksheet target of 30%; the test then required 166 proposals per version—seven weeks. One test at a time: the 80-word idea went in, while the opening idea stayed in the queue. If you’re a real estate agent, the same logic applies: “would you like to visit Saturday or Sunday?” would get the same veto, and “reply within 24 hours” is your signal metric, not the sale.
Twelve weeks later: 300 proposals on each side. Version A, the usual script: a 19.3% response rate. Version B, with up to 80 words: 29.7%. The odds of this being due to chance are 3 in 1,000. Anyone looking at these two numbers would promote B immediately.
The Evaluator did not promote it. Complaints: 6 for version B versus 1 for A, while the worksheet’s tolerance was zero. Verdict: A STAYS. The rule was applied as written—and the rule was wrong. Six versus one out of 300 is noise from a rare event, not a real difference. Renata accepted the verdict, adjusted the complaint tolerance to 0.01 for future tests, and logged the 80-word idea as tested and discarded, with the numbers, so no one would accidentally test it again.
Notice what the loop ensured here: a version was not adopted just because it looked better, everything was recorded, and the error was in the worksheet, not the system. A support manager who sets “reopened within 7 days” to zero tolerance will discard a good response because of two tickets. Tolerance is a calculation, not a wish.
Common mistake
Zero tolerance for a rare event. Complaints and opt-out requests occur in 1% or fewer cases. With 300 on each side, 6 versus 1 is noise—and zero tolerance discards good ideas by chance. Use the product calculation: tolerance is about two standard errors of the baseline rate, which at 1% and 300 per side is 0.01.
In cycle 3, the idea waiting in the queue was brought back: open the message by mentioning a specific point from that client’s review. The Experimenter recalculated using the actual response rate, from 18.4% to 30%: 212 proposals per version, about nine weeks. A new idea—to mention the price right after the greeting—was vetoed because it could predictably increase opt-outs, a risk admitted by the hypothesis itself.
Twelve weeks later, cycle 4: 300 on each side. Response was 19.3% for A and 29.3% for B; odds of chance, 4 in 1,000. Guardrails: margin rose 0.7 points; complaints were 4 versus 2, within the new 0.01 tolerance; opt-outs were 1 versus 3, an improvement. Verdict: B WON. Renata received a five-line card costing about R$ 45, within the R$ 50 limit. She approved it. The script with the specific opening became the official version, v2. Version 1 remained in the history with a rollback button. If, in the first cycle after promotion, response or any monitored metric falls beyond tolerance, the system alerts her and asks to roll back.
One line in the verdict deserves attention: conversion, the number Renata actually cared about, rose from 3.0% to 3.7%—and with this sample size, that proves nothing. Remember this detail. At the beauty clinic or real estate agency, what the loop has proved so far is that more people reply, not that more people buy.
The meta-agent doesn’t look at the proposal or the client. It looks at the loop. After cycle 4, its report had four findings. Cost: the four cycles used about 1.6 million tokens for a single promotion. Cycle 4 used 90% of the R$ 50 limit—an alert. Vetoes: of four distinct ideas, two were vetoed, a rate of 0.5—an alert because the Optimizer is proposing things that conflict with the guardrails. Cadence: the worksheet promised weekly cycles; the actual intervals were 12, 1, and 12 weeks. The Critic flagged this three times in a row. Promotions: one in four cycles.
It also repeated one observation with numbers: two different ideas each raised the response rate by ten points—and neither moved conversion. Two observations against, none in favor. Today’s official version was approved based only on the signal. What it suggested from this will come in the practice—you get to figure it out.
A support manager reading their own loop’s report would draw the same conclusions: a high veto rate means invariants are poorly explained to whoever proposes ideas; costs near the limit mean too much memory is being loaded each cycle; broken cadence means no one is updating the spreadsheet every week. The meta-agent fixes none of this. It shows you, and you decide.
Before · v1
Same greeting for every client, a thank-you for the visit, five blocks of text. Response rate: 19.3%.
After · v2
The first sentence mentions that client’s concern or the area assessed. Response rate: 29.3%.
Result: +10 response points, with 300 proposals on each side and no guardrail outside tolerance. Conversion: 3.0% → 3.7%, still unproven.
Practice now 0/3 done
Read the case, answer three questions in writing, and compare with the answer key—about 10 min.
Nothing changes in your business until you approve it: here, you only read and make decisions about the clinic’s loop. If your answer differs from the key, read why—that difference is exactly what this lesson aims to teach.
Renata opens the cycle 4 report on a Monday. Script v2 has been official for one week. She has R$ 50 for the next cycle and three ideas in the Optimizer’s queue: a new greeting, sending the proposal as audio, and a meta-agent suggestion she has not yet read carefully. The spreadsheet continues to receive 50 proposals a week.
1. It was discarded because it worsened a guardrail beyond tolerance: 6 complaints versus 1, with zero tolerance. The Evaluator does not choose “what looks better”—if a monitored metric falls outside tolerance, A stays, even when the test metric rises. The worksheet changed: complaint tolerance went from zero to 0.01, because zero tolerance for a rare event discards good ideas due to noise. The idea remained in memory as tested and discarded, with the numbers.
2. Three conditions, all required: the difference was significant (19.3% versus 29.3%, odds of chance 4 in 1,000); the required sample size was reached (300 on each side, minimum 212); and no guardrail went outside tolerance (margin, complaints, and opt-outs all stayed within limits). After that came human approval on the card, within seven days.
3. Neither the new greeting nor audio. The fifth cycle should replace or supplement the signal metric with something closer to closing—for example, “replied and asked about booking or price.” The meta-agent report supports this: two different ideas raised response by ten points, and neither moved conversion (3.0% versus 3.7%, unproven). Continuing to optimize replies means continuing to optimize a signal that has twice failed to move the goal. If you answered “test the greeting,” notice the pattern: it’s the third copy idea, while the evidence points to the metric.
You just read an entire loop and predicted its next cycle from evidence, not taste—the same reading you’ll do for your own.
Summary
Track 05 · Lesson 2 · foundation
By the end of this lesson, you can say what a support loop optimizes and monitors, and run the Observer on 20 tickets in your AI chat—to see, with numbers, which issue deserves a hypothesis.
Support is where a company hears the most from customers and learns the least from them. Every ticket is closed and forgotten. Whether there are 200 or 10,000 a month, the evidence is already there—it just isn’t being read.
↓ scroll to study
Marcos manages support for software used by small shops. Eight people handle about 800 tickets a month. Each closed ticket leaves a trace: issue, time to resolution, whether it was solved at first contact, whether it returned within seven days, and the customer’s rating. That is a ready-made tracking spreadsheet—the loop’s evidence exists without anyone having to enter it.
What no one does is read it. That is all the Observer does: count and group, without interpreting. When Marcos first ran it on a month of tickets, the result was a number he “knew” but had never seen written down: 37% of tickets were about the same issue—exporting a report. Three hundred tickets, each answered from scratch by different people with different responses.
The beauty clinic owner has the same pile, only smaller: forty messages a month asking “how much does it cost?” before any proposal. Same phenomenon. She has never counted them either.
Ten thousand closed tickets are not ten thousand interruptions. They are ten thousand unread rows.
A support loop has the same shape as a sales loop—maximize one thing without worsening others—but different components. Optimize: first-contact resolution, for example from 55% to 65%. Without worsening: customer satisfaction, seven-day reopen rate, and time spent by the customer. Marcos needed two minutes to write this down and longer to understand why his previous objective was dangerous.
The previous version was “reduce average support time from 12 to 8 minutes.” A loop optimizing that learns to close tickets quickly, not resolve them. The customer comes back and opens another ticket, while the average time still looks good. It is the same trap as “maximize clicks,” which turns into clickbait: any metric on its own becomes a target and stops measuring what mattered. That is why the objective’s structure is mandatory, not optional—“without worsening” is what keeps the loop from gaming the metric.
There is good news in support: rates range from 50% to 70%, so the sample needed for proof is small. Proving 50% versus 65% takes about 170 tickets per version; at 200 a week, that is two weeks. Compare this with the clinic’s conversion rate, around 3%: 1,500 per version. Real estate is in between: “lead replied within 24 hours,” around 25%, takes about 300 per side. Support is where the loop turns fastest.
Test yourself
Marcos defines the goal as “average support time from 12 to 8 minutes,” with no “without worsening” conditions. What is the loop likely to learn?
With 37% in hand, the Critic writes a strong critique—300 cases is far above the minimum of 30. The Optimizer proposes a new standard answer for this issue, with steps and an image. The Guardian checks that it promises no timeline and touches no invariants. The Experimenter splits these tickets evenly between old and new answers for two weeks. The Evaluator compares first-contact resolution and monitors satisfaction and reopen rate. If B wins, the new answer becomes the support assistant’s official version. So far, it is the sales loop with a different subject.
The next step changes the company. Memory records: “37% of tickets concern report export; 214 point to the button hidden in the menu as the cause.” This is not a support hypothesis—it is a product hypothesis. It leaves the support loop as a card for the product decision-maker, with supporting counts attached. Documentation changes that same week. If the button changes, it eliminates those 37% at the source. Support has moved beyond answering customers to improving the product and process.
At the clinic, the step is smaller but similar: if “is there parking?” appears in 60 messages a month, the answer goes in the first line of the WhatsApp profile and disappears from the queue. At the real estate agency, “does it qualify for financing?” repeated 80 times becomes a line in the portal listing.
Before
800 tickets a month, 37% for the same issue, each answered from scratch by eight people using eight different texts. No quantified product change request.
After
An official answer tested A versus B for the most common issue, updated documentation, and a product card with 296 tickets attached as evidence.
Result: 296 individual tickets become 1 hypothesis with a supporting sample. The improvement in resolution exists only after the test—the loop does not promise the number, but it ensures it will not fall because of a system decision.
Marcos’s company also has a sales loop. Both write to the same memory. When support records that 37% of new customers get stuck exporting reports, the sales loop gains a guardrail: never promise “one-click reports” in a proposal. When sales learns that brick-and-mortar customers respond better to a certain kind of message, support gets a segment to monitor. Neither loop discovered this alone—the shared memory connected them.
This is the beginning of the meta-loop: someone looks at the loops together. The honesty standard from Track 4 applies. In today’s product, the meta-agent only reports—cost, vetoes, cadence, and agreement. Proposing structural changes is for a future version and requires human approval; self-redesigning loops are neither in the product nor promised. What exists today is already useful: two loops that do not repeat each other’s mistakes.
A real estate agent with two loops—one for portal leads, another for post-visit follow-up—has the same bridge: if follow-up records a complaint that photos do not match the property, the lead loop gains an invariant about photos. The clinic owner starts with one loop; the second comes after the first has run five cycles.
Practice now 0/3 done
Paste the prompt into your AI chat, read the count, and compare it with the expected result—about 12 min.
Nothing changes in your business until you approve it: the 20 tickets are fictional, and the prompt only counts and groups them. If the answer differs from what you expect, paste it again—the Observer must follow the prompt, not you.
The block below is a ready-to-use prompt: the first part tells the assistant its role, and the second contains the 20 tickets. You only replace what is between < >—and there is nothing to replace here.
You are the Observer in a customer support loop. Your only job is to count and group. Rules: do not interpret causes, suggest solutions, or give opinions. If a ticket could fit two issues, choose the main one and say how many were uncertain. Output: a table with the columns ISSUE | COUNT | % OF TOTAL, sorted largest to smallest, and a final row with the total. Nothing besides the table and total. Tickets (one per line, number and text): 1. I can’t export the sales report as a PDF; the button doesn’t appear. 2. I forgot my password and the recovery email never arrives. 3. The invoice won’t issue; it shows an unexplained error. 4. I accidentally entered the same product twice. How do I delete it? 5. Where is the report export option? I’ve looked everywhere. 6. The system is slow to open the register today. 7. I was charged twice this month. 8. I want to export the monthly report but can’t find the button. 9. My employee can’t log in; it says the user is locked. 10. Inventory report: I need a PDF for the accountant but can’t generate it. 11. Can the system send a low-stock alert? That would be great. 12. The invoice has been “processing” for two hours. 13. Report export doesn’t work on mobile; I only see a blank screen. 14. I can’t remember the password and the registered phone number is old. 15. The product appears twice in the list, with different prices. 16. It’s slow to save a sale; it freezes for about 20 seconds. 17. I need the sales report by period as a PDF. Where do I generate it? 18. The invoice was rejected; the error mentions code 999. 19. How do I export today’s report? I can’t find it. 20. I created a new user, but they don’t receive the password.
You just ran the first assistant in a support loop, saw which issue deserves a hypothesis in numbers, and saw the assistant stay in its role.
Summary
Track 05 · Lesson 3 · tool · final deliverable
By the end of this lesson, you will hand in your loop worksheet with all five answers filled in and a decision card ready for week one—and someone on your team will be able to read them without your explanation.
Four tracks produced five answers scattered across different notes. Today they become one worksheet, and the worksheet becomes the first cycle. Without it, the course ends the way AI does: one good answer, and that is all.
↓ scroll to study
The loop worksheet asks for nothing new. Each of its five questions was answered in an earlier lesson; today’s task is to bring them together. A numbered goal: Track 2, Lesson 1. Where evidence comes from: Track 2, Lesson 3. What never changes on its own: Track 3, Lesson 3. Cost and time ceilings, and who approves: Track 4, Lesson 4. If any answer is blank, go back—the worksheet with four answers is not “almost ready”; it is unsafe because the system will infer the missing one.
Paulo, a real estate agent, arrived with these notes: portal leads who reply within 24 hours, from 25% to 35%; the portal spreadsheet, one row per lead, about 80 a week; never promise an appraised value, contact anyone after 9 p.m., or promise exclusivity; up to R$ 30 per week, weekly cycle; he approves, with five days to respond. Five statements. That is the whole worksheet.
Why only five? Because they are the five things no system can safely infer: what you want, where the record is, what is forbidden, how much you can spend, and who signs off.
The three worksheets, side by side
After the five answers, the worksheet gets a second half that you do not write—you read and confirm it. The signal metric: if your target is a rate near 3%, the system suggests testing something faster and monitoring the target from a distance, as it did for the clinic. The sample size needed for proof, calculated for your metric and pace: “this test needs about 300 per version; at your pace, six weeks.” Guardrails with tolerances, suggested for your type of business. Sales: margin, complaints, and opt-outs. Support: satisfaction and reopenings. And the rollback trigger: in the first cycle after a promotion, if the number or any guardrail falls beyond tolerance, the card alerts you.
For Paulo, the system proposed a signal metric: the reply rate within 24 hours itself (already fast); a sample size of about 300 leads per version, four weeks at his pace; guardrails of booked visits with a 0.02 tolerance and portal complaints with 0.01. He checked the tolerances against the clinic lesson and confirmed them. Five minutes.
A note for anyone confirming: read the metric definition word for word. “Replied” must exclude “replied asking us to stop,” or the loop learns to provoke people. And if the clinic owner later wants to tighten a tolerance, she does it through the card, with a record—never midway through a test.
The first cycle runs on the spreadsheet you already have. The Observer counts. If there are fewer than 30 rows for a pattern the Critic wants to claim, it does not claim it—it records “observed, not tested” and waits for the spreadsheet to grow. The Optimizer proposes up to three ideas in IF… THEN… BECAUSE format, marked with evidence strength. The Guardian vetoes anything that touches what “never changes.” The Experimenter shows the calculation and timeline. And the Evaluator, in the first cycle, almost always says: INSUFFICIENT SAMPLE—continue.
That is not a failure. It was the answer in the clinic’s cycle 1 and cycle 3. The first cycle delivers something else: the first history entry, the first idea vetoed with a reason, the first timeline calculation. The support manager with 200 tickets a week sees a verdict in two weeks; the clinic with 50 proposals, in two or three months. The pace comes from your records, not from AI.
For the agent, the first card will say: “test in progress, 80 of 300 per version, three weeks left; no guardrail out of bounds.” The temptation is to open the spreadsheet in week two, see B ahead, and decide. Do not decide.
Common mistake
Twelve proposals became the rule. With few rows, any pattern looks true—“Tuesday converts better” with 12 proposals is not a real finding. The Critic only claims a pattern at 30 or more; below that it goes into “observed, not tested.” If you spot a pattern in a small spreadsheet yourself, note it and wait for the sample size needed for proof—do not change the playbook because of it.
Everything the loop asks of you after the worksheet fits on a decision card. Line 1: the cycle and the idea being tested. Line 2: the result, with the sample size on each side. Line 3: each guardrail, within or outside its limit. Line 4: cycle cost versus the ceiling. Line 5: the decision—approve, reject, or wait for more data. If you do not respond by the worksheet deadline, the default is not to promote, and the history records “pending.” Safe by design.
The clinic’s real card from cycle 4 said: hypothesis “open with something specific from the review”; replies 19.3% → 29.3%, 300 versus 300; margin OK, complaints 4 versus 2 within bounds, opt-outs 1 versus 3; cost about R$ 45 out of R$ 50; decision: approved. Marcos’s support card will have the same shape with different names: resolution 55% → 61%, 180 versus 180; satisfaction unchanged, reopenings 9 versus 8; cost R$ 62 out of R$ 80. Stopping before the sample size needed for proof because B is ahead is not one of the three answers—it is the most common way to promote noise.
After five approved cards with no rollbacks, the worksheet allows more autonomy: the system promotes automatically and notifies you. You do not have to get there. Approving one card a week for months is the loop working as promised—that is the level the clinic is at.
EXECUTION × EVIDENCE × EXPERIMENTATION × MEMORY = EVOLUTION
It is multiplication, not addition: if any factor is zero, the result is zero. No execution means no data—the first track showed AI that executes and stops there. No evidence means no real learning—Track 2 gave you the log spreadsheet. No experimentation means you do not know whether an idea works—Tracks 2 and 4 gave you the test, sample size, and card. Without memory, the system forgets—Track 3 gave you the history. What the loop guarantees when all four exist is not that the number rises: it will not fall by system decision, everything is recorded and reversible, and cost stays under the ceiling.
Paulo has plenty of execution—80 leads a week for years—and zero memory: every agent at the real estate office replies differently, and no one knows what has already been tried. The support manager has plenty of evidence and zero experimentation: they have never compared two replies. The beauty clinic had all four after four cycles. Each starts with the factor that is at zero.
The canvas below is the same worksheet, extended to any company process—purchasing, finance, marketing. The five answers cover questions 1, 3, 9, 4, and 11; the system proposes the rest.
LOOP-R Canvas—13 questions for any process
Practice now 0/4 complete
Copy the five answers from your notes, prepare the first week’s card, and test whether a teammate can read it—about 12 minutes.
Nothing changes in your business until you approve it: the worksheet is a document, and this practice card stays undecided. If an answer seems wrong later, correct the worksheet and record the change—the clinic’s worksheet also changed in cycle 2.
The block below is a plain-text form you fill in once: five questions and one card. Replace only what is inside < > and leave the rest as is. You can fill it in your phone’s notes, an email to yourself, or on paper.
LOOP WORKSHEET — <process name> 1. NUMBERED GOAL <metric>: from <current value> to <target value> without worsening: <guardrail 1>, <guardrail 2> 2. WHERE EVIDENCE COMES FROM <spreadsheet or system>, one row per <unit: proposal / lead / ticket> volume: about <N> per week 3. WHAT NEVER CHANGES ON ITS OWN - never <invariant 1> - never <invariant 2> - never <invariant 3> 4. CEILING up to R$ <amount> per cycle · cycle <weekly / every two weeks> up to 3 ideas per cycle · 1 test at a time 5. WHO APPROVES <name>, with <N> days to answer the card ---------------------------------------------------------- DECISION CARD — week 1 (fill in what you expect) CYCLE 0001 — hypothesis: “IF <change X>, THEN the metric will go from A to B, BECAUSE <evidence>” Result: <metric> <current> → <expected> (N = <per version>, <weeks> left) Guardrails: <guardrail 1> · <guardrail 2> · <guardrail 3> Cost: R$ <estimated> this cycle (ceiling R$ <limit>) Decision: [approve] [reject] [wait for more data] ← leave blank until the verdict
You have just delivered an assembled loop: a complete worksheet, the first card drafted, and a reader who understands what would discard the idea and what AI must never touch.
Summary