Don't Automate What Shouldn't Exist: Build Better AI Loops

Most AI automation scales existing confusion. Learn when to delete a process, when to use a loop, and how to build one without creating more noise.

2026-07-21 · By Guilherme Salgueiro

The most trustworthy automation may be the one that does nothing.

It found the signal, checked the available evidence, concluded that it could not prove an intervention was necessary, recorded the result, and stopped.

Most automation dashboards would call that an empty run. I think it is the beginning of a more useful way to build with AI.

But there is a question even a careful loop cannot answer once it starts running: **should this routine exist at all?**

We are in a race toward AI. Companies are adding copilots, agents, daily briefs, autonomous workflows, and now loops—not always because they remove a real constraint, but because AI adoption itself has become the objective. The technology is powerful. The problem definition is optional.

That is how a company ends up applying a powerful weapon to a bug. Or producing a morning brief nobody needed. Or building an agent that faithfully executes a process everyone already knows is broken.

Automation does not repair weak thinking. It scales it. It makes the process faster, cheaper, more frequent, and harder to question because activity now wears the label of innovation.

The answer is not less AI. Used well, automation and loops create extraordinary leverage. The answer is to make every automation earn its place—first by proving that the underlying process deserves to exist, then by proving that the system saves time, improves the output, or makes better decisions than the alternative.

Before we build more loops, we need to get better at deleting them.

• Do not automate a process until you have questioned its purpose, deleted what should not exist, and simplified what remains.
• An automation maps a trigger to an action. An agent run pursues one bounded goal. A loop uses feedback to move changing reality toward a desired state.
• A reliable loop needs trusted evidence, bounded authority, independent verification, minimal state, and explicit reasons to stop, repeat, or escalate.
• Measure whether the system returns time, attention, or better decisions—not whether it produces more activity.

Question the Process Before You Automate It

Elon Musk uses a five-step engineering process he calls [The Algorithm](https://www.elonmuskbook.org/the-book-of-elon-musk-free-online-version/the-algorithm). The order matters:

1. Question the requirements. 2. Delete the part or process. 3. Simplify or optimize. 4. Accelerate. 5. Automate.

Most AI projects begin at step five.

The most useful story behind the sequence comes from Tesla's battery-pack production line. Fiberglass mats were being fitted on top of battery packs. The line was struggling, so the team improved the robot's movement, accelerated it, and optimized the glue and drying process.

Then Musk asked what the mats were for.

The battery team said noise and vibration. The noise-and-vibration team said fire safety. A simple comparison test found no meaningful difference between cars with and without the mats. Tesla removed the part—and with it, an entire production step and roughly two million dollars of robotics.

The engineers had successfully improved the wrong system. The automation was working. The process was nonsense.

> “The most common mistake of smart engineers is to optimize a thing that should not exist.” — [Elon Musk](https://www.elonmuskbook.org/the-book-of-elon-musk-free-online-version/the-algorithm)

AI has made this mistake easier to hide.

Every technology wave produces the same executive sentence: **we need one.** A website. An app. A blockchain project. A metaverse presence. Now an AI support chatbot. The object changes. The absence of a reason does not. The race to [stay current with AI](/writing/you-already-failed-at-ai) has simply made the cycle faster.

Customer support makes the absurdity easy to see. Before asking which chatbot to buy, can the company answer a few less fashionable questions?

• What are the ten most common reasons customers contact us?
• Are tickets categorized consistently enough to know?
• Can a customer find a current, useful answer without opening a ticket?
• Do the FAQ, the support team, and the product give the same answer?

If the answer is no, the chatbot is not automating customer service. It is placing a confident conversational layer over organizational confusion.

A [Gartner survey](https://www.gartner.com/en/newsroom/press-releases/2024-12-09-gartner-survey-reveals-85-percent-of-customer-service-leaders-will-explore-or-pilot-customer-facing-conversational-genai-in-2025) found that 85% of customer-service leaders expected to explore or pilot customer-facing conversational generative AI in 2025. The same research warned that they needed an AI-ready knowledge base to make it work.

The first sentence gets the budget. The second gets postponed.

Air Canada learned what happens next. Its chatbot told a grieving customer that he could buy a regular ticket and request a bereavement discount afterward. Another page on Air Canada's website said the opposite. The customer followed the chatbot's instructions; the airline denied the discount. The British Columbia Civil Resolution Tribunal later [held Air Canada liable for negligent misrepresentation](https://www.canlii.org/en/bc/bccrt/doc/2024/2024bccrt149/2024bccrt149.html).

Air Canada did not have a chatbot problem. It had a truth problem. The chatbot simply delivered the contradiction with a friendly interface.

AI cannot decide which of two contradictory policies the company believes. It merely gives the contradiction a better interface.

First-principles thinking runs in the opposite direction. It asks what outcome matters, where the real constraint sits, who owns the answer, and what would happen if the process disappeared tomorrow. It requires what Musk calls [deep understanding](https://www.elonmuskbook.org/the-book-of-elon-musk-free-online-version/earn-deep-understanding): enough command of the details to distinguish a real requirement from organizational folklore.

If you cannot explain the process clearly without AI, you are not ready to automate it. You are asking software to hide the fact that the company does not understand its own work.

Only then does automation become useful. Once we have questioned the objective, removed what should not exist, and simplified what remains, AI can compress cycle times, monitor more evidence than a person can hold, and execute repeatable work with enormous consistency.

The point is not that automation comes last because it is dangerous. It comes last because it is powerful.

Deletion before optimization is what ensures that power moves the system in the right direction. Otherwise, we are not creating leverage. We are going nowhere faster.

Everyone Is Talking About Loops. Most People Mean Repetition.

“Loops” are becoming the next compulsory word in AI. Boris Cherny, the creator of Claude Code, recently said that the thing he finds himself using more and more is [the loop](https://www.youtube.com/watch?v=SlGRN8jh2RI). His examples include babysitting pull requests, keeping continuous-integration tests healthy, and regularly clustering product feedback.

The idea is powerful. The vocabulary is getting ahead of the understanding.

A scheduled prompt is now called a loop. A collection of agents is called a loop. A long prompt that tells an agent to keep trying is called a loop. Sometimes the word means nothing more than “the AI does it again.”

Repetition is not the useful part of a loop. **Feedback is.**

The easiest way to understand the difference is to reduce each system to its job.

An automation does a known thing when a known thing happens

**In theory:** a fixed rule connects a trigger to an action.

**In practice:** when a payment clears, send the receipt. When a form arrives, create the record. When a meeting is cancelled, release the room.


An automation does not need to understand the goal, compare alternatives, or learn from the result. That is not a weakness. If the rule is stable and the correct action is known, its simplicity is an advantage. Adding an AI agent would make the system less predictable without making it more useful.

An agent run solves one bounded problem

**In theory:** give the system a goal; it plans and takes actions until it produces a result or hands the problem back.

**In practice:** research five competitors and prepare a brief. Inspect this codebase, implement a feature, run the tests, and report what changed.


The route can change while the agent works. It can search, use tools, encounter an error, revise its plan, and check its answer. But the assignment is still finite. It begins with one goal and ends with one result.

An agent may loop internally while solving that task. That does not automatically turn the surrounding business process into a loop. A person can walk in circles while looking for their keys; that does not make the household a control system.

A loop keeps moving reality toward a desired state

**In theory:** a loop repeatedly compares what is true with what should be true, acts on the gap, and uses the result to decide what happens next.

**In practice:** a pull-request loop observes the current checks, compares them with “ready to merge,” fixes a safe failure, reruns the checks, and updates the pull request's state. It stops when the checks are green, repeats if a fix revealed another failure, and escalates if the remaining decision requires product, security, or architectural judgment.


This is why Cherny's examples are more instructive than the slogan. Pull-request checks have a visible state. A failing test can be rerun. New customer feedback can be compared with what has already been seen. These are not glamorous acts of artificial general intelligence. They are bounded problems with observable evidence.

A thermostat is the same idea without the AI vocabulary. It observes the temperature, compares it with the setting, turns the heating on or off, and checks again. The action changes the environment; the changed environment changes the next action. When the room is warm enough, doing nothing is correct.

Now reconsider the daily AI brief. A schedule that produces a summary at 7 a.m. every day is an automation, even if it invokes a sophisticated model. It runs whether you have six important meetings or none. It may create output without improving a decision.

A useful briefing loop first observes the day. Are there meetings that require preparation? Has relevant information changed? Are the sources current? Is there enough material to justify interrupting you? It creates a brief only when the evidence crosses that threshold. Otherwise it records “no brief needed” and stops.

The schedule is merely the alarm clock. The loop is the judgment that follows.

Does AI improve itself in a loop?

Not in the way the phrase usually implies. A deployed model does not rewrite its own weights and become a better model after each conversation. A provider may later use permitted conversation data to [help train future models](https://privacy.claude.com/en/articles/10023580-is-my-data-used-for-model-training), but that is a separate development process. That process can be a loop: observe failures, turn them into evaluations, change the training or system, test the new version, and decide whether it improved. The loop is built around the model. It is not magic happening inside every chat.

The same is true of “self-improving” skills. A skill improves only if the system can detect a failure, propose a specific change, have that change reviewed or independently tested, use it in a later run, and measure whether the failure recurs. If an agent simply writes every experience into memory, it is not learning. It is accumulating clutter with confidence.

Cherny's own team uses a more grounded version of self-improvement: when Claude repeatedly does something incorrectly, they [add the lesson to the project's shared instructions](https://x.com/bcherny/status/2007179832300581177) so future runs receive better context. The model has not modified itself. The operating system around it has improved—and the humans remain responsible for deciding which lessons deserve to persist.

Anthropic's own guidance describes skills and deterministic hooks as [building blocks for agent loops](https://claude.com/blog/steering-claude-code-skills-hooks-rules-subagents-and-more): the skill provides the procedure; the hook ensures that a required check actually runs. The model is only one component. [The surrounding system](/writing/100x-your-ai-same-model) supplies memory, verification, permissions, and stopping conditions.

Three questions are enough to classify most systems:

1. **Is the correct action already known?** Use an automation. 2. **Is there one bounded goal that requires judgment?** Use an agent run. 3. **Will reality keep changing, and must each result shape the next decision?** Build a loop.

If the result of the previous action cannot change the next decision, you have repetition. If the system cannot verify progress, you have motion. If it cannot conclude that no action is needed, you have an activity machine.

A functional loop needs more than a circular arrow on a slide. It needs a target state, a trustworthy observation, a decision rule, bounded authority, an independent check, memory that prevents pointless repetition, and a way out.

That is what we need to build next.

How to Build a Loop That Does Not Create More Chaos

Do not start with the prompt.

Start with the contract.

Before choosing a model, an agent framework, or a schedule, write down how the loop will know what matters, what it is allowed to change, how it will prove that the change worked, and when it must get out of the way.

If those questions are unclear, a better prompt will only help the system misunderstand you more efficiently.

A functional loop has seven parts.

1. Define the desired state

The loop needs a condition it is trying to make or keep true.

“Manage my pull requests” is not a desired state. It is a vague delegation of responsibility. “Keep this pull request rebased, passing its required checks, and ready for my review” is observable. The loop can compare reality with it.

The narrower the desired state, the easier the loop is to govern. If the sentence contains several unrelated outcomes joined by “and,” you may already be designing multiple loops.

2. Observe reality through a trusted source

The loop needs evidence of the current state: the actual pull-request checks, the actual inbox, the current calendar, the live account balance—not a summary left behind by yesterday's run.

Define where the evidence comes from, how fresh it must be, and what makes it complete enough to act on. If the source is unavailable or stale, the correct result is usually to stop and report that uncertainty. Guessing is not resilience.

3. Compare the current state with the desired state

The comparison turns data into a decision.

Are all required checks green? Is the branch behind? Is there new review feedback? Has anything changed since the last observation? The rule may be deterministic, or a model may need to interpret ambiguous evidence, but the question should remain explicit.

This is also where the loop must be allowed to conclude that no action is necessary. If “nothing to do” is not a valid decision, the system is designed to manufacture activity.

4. Act inside a defined authority boundary

Do not give a loop “permission to handle the pull request.” Divide its actions into three groups:

• **Allowed:** rerun a failed check, rebase a clean branch, or apply a narrow formatting fix.
• **Approval required:** change application logic, update a dependency, or respond to substantive review feedback.
• **Forbidden:** remove a failing test, dismiss a review, force-push, or merge.

This boundary matters more as the model becomes more capable. Capability expands what the system *can* do. Authority defines what it *may* do.

5. Verify the effect independently

An action is not proof of an outcome.

If the loop changed the code, rerun the checks. If it updated a record, read the record back from the source of truth. If it sent data somewhere, verify that the destination received the correct object exactly once.

Whenever possible, the verifier should be different from the mechanism that produced the work. Asking the same model “did you do a good job?” is reflection, not verification. Depending on the failure mode, a test result, database read, external status, second model with a separate rubric, or human approval can provide a stronger check.

The verifier does not need to be sophisticated. It needs to be difficult for the action to accidentally fool.

6. Update only the state the next run needs

Useful memory is selective.

The next run may need to know what was last observed, what decision was made, which action was attempted, whether it worked, and when it should check again. It probably does not need the agent's complete internal monologue or every intermediate tool result.

Store decisions and evidence, not cognitive exhaust. Otherwise each run inherits more context, more contradictions, and more opportunities to mistake an old fact for a current one.

7. Stop, repeat, or escalate

Every iteration must end in one of three explicit states:

• **Stop:** the desired state is true, no material change occurred, or no action is needed.
• **Repeat:** the action changed the state, but another bounded iteration is justified.
• **Escalate:** the evidence is insufficient, the allowed action failed, the risk is too high, or human judgment is required.

Add hard limits as well: maximum attempts, maximum cost, maximum elapsed time, and a rule for detecting no progress. A loop without an exit condition is not autonomous. It is stuck.

Write a loop card before you build the loop

You should be able to describe the entire operating contract on one screen. For example:

Notice what is not on the card: the model name and the prompt.

Those matter during implementation, but they are replaceable. The desired state, evidence, authority, proof, and owner are the durable system.

Earn autonomy in stages

You do not need to jump from a manual process to an unattended agent. A safer path has five stages:

1. **Run it manually.** Prove that the desired state and decision rules make sense. 2. **Observe in shadow mode.** Let the loop inspect reality and record what it would do, without changing anything. 3. **Recommend actions.** Compare its proposals with the decisions a capable human makes. 4. **Allow narrow actions.** Automate only the changes that are reversible, cheap to verify, and consistently correct. 5. **Expand or stop.** Grant more authority only when repeated evidence justifies it. Delete the loop if its value never exceeds its cost and noise.

This is not bureaucracy. It is how a loop earns trust without borrowing it from a successful demo.

Build a library of small loops, not one enormous agent

As loops multiply, the temptation is to combine them into one executive agent that watches everything and can act everywhere. That architecture looks elegant on a slide. In practice, it concentrates permissions, mixes evidence from unrelated domains, and makes failure difficult to isolate.

A loop library takes the opposite approach. Each loop has one desired state, one owner, a narrow scope, and explicit authority. A meeting-preparation loop does not also triage the inbox. A pull-request loop does not rewrite the roadmap. A customer-feedback loop identifies patterns; it does not silently change the product.

In my personal system, I treat the library as a registry of operating contracts rather than a folder of clever prompts. Each entry answers:

• What recurring signal wakes this loop?
• Which exact system, project, or account may it inspect?
• Is it proposed, being tested, enabled, paused, or retired?
• What may it change without approval?
• What evidence proves a successful run?
• Who owns the consequences?
• When does its permission expire or need review?

The status matters. A loop idea is not a live loop. A successful test is not permanent authority. A working loop in one project is not permission to run it across every project.

This turns reuse into something safer than copy and paste. You can reuse the structure of a PR loop while giving each deployment its own repository, owner, permissions, and stop conditions. The capability is reusable. The authority is local.

The result is less like one artificial employee and more like a collection of small, inspectable control systems. Each does one job, produces evidence, and knows when to stop.

That is how loops create leverage without increasing chaos.

The Best Loop Gives You Something Back

The automation at the beginning of this essay did nothing.

It did not produce a brief, open a task, rewrite a document, or send another notification. It observed the available evidence, found no reason to intervene, recorded that decision, and stopped.

That was not an empty result. It protected something more valuable than output: attention.

We tend to [measure automation by what it produces](/writing/stop-worshipping-effort) because production is visible. More summaries. More tickets processed. More messages classified. More dashboards refreshed. The activity proves that the system is running.

But output is not the scarce resource anymore. AI can produce more words, analysis, recommendations, and alerts than any person could consume.

The scarce resource is [the mind receiving them](/writing/strategic-ignorance).

Every unnecessary brief asks someone to read it. Every low-confidence alert creates a decision. Every autonomous action that cannot prove its result creates an investigation. A loop can remove ten minutes of work and quietly add twenty minutes of supervision, interruption, and doubt.

That is not leverage. It is attention debt.

The purpose of automation should be to return cognitive bandwidth: fewer things to monitor, fewer repetitive decisions, fewer open loops occupying the back of the mind. A well-designed system should make the day feel quieter, not merely more productive on paper.

This also means resisting the temptation to outsource every form of thinking.

Some thoughts need time before they become useful. A strategy needs to be argued with. An idea needs to survive a walk, a blank page, or a night without another prompt. A difficult decision may need a conversation rather than a confidence score. Writing is sometimes how we discover what we think, not an inconvenience to eliminate before the thinking begins.

AI can research, challenge, organize, simulate, and expose what we have missed. It can remove enormous amounts of mechanical work. But it should create room for judgment, not replace the experience through which judgment develops.

This is not an argument for less ambitious use of AI. It is an argument for more ambitious outcomes.

Do not settle for a system that produces something every morning. Build one that understands when your morning should remain undisturbed. Do not celebrate an agent because it completed a hundred actions. Ask whether those actions moved anything that mattered. Do not count how many loops are running. Count how many concerns you no longer need to carry.

Every automation must earn its place. It should save more time than it consumes, improve the work beyond what the review burden costs, or make a decision meaningfully better. It should keep earning that place across repeated runs—not receive permanent authority because of one impressive result.

And when it no longer does, delete it.

The real promise of AI is not a life filled with autonomous activity. It is the possibility of recovering time for the things that should never become background processes: original thought, careful judgment, honest conversation, and the slow work of deciding what is worth doing.

The best AI system may be the one you notice least. It handles what deserves to become mechanical, surfaces what genuinely needs you, and remains silent when silence is the correct result.

The future will not belong to the companies running the most loops.

It will belong to the people who know what deserves to keep running—and what deserves to stop.