Industrial engineering was my path into AI.
For most people, that brings to mind factories, lines, queues, bottlenecks, handoffs, throughput, variation, and flow. The discipline was always broader than the factory frame.
At its best, industrial and systems engineering teaches you to see work as a system: people, machines, information, incentives, and constraints interacting over time.
The setting changes, but the same questions persist.
Where does work wait? When does quality break down? Which local optimizations make the whole system worse? Which feedback arrives too late to matter?
The Toyota Production System became an important reference point for that reason. TPS treated flow, quality, waste reduction, and learning as design problems inside the work itself, even outside the factory frame. Quality belonged inside the work, before the final inspection. Learning happened inside the system, close to where problems surfaced and could be corrected.
The Goal became a seminal book for operators for the same reason.
Eliyahu Goldratt made the logic of constraints legible through a factory story: a plant can be full of efficient local activity and still fail when the whole system ignores the constraint.
The lesson was to understand the system well enough to improve flow where it actually mattered.
Then The Phoenix Project carried that inheritance into software.
Software looked different from a factory floor. The work was less visible. The inventory was work in progress. The bottlenecks lived in handoffs, tickets, deployments, incidents, queues, unclear ownership, and feedback loops that were too slow to correct the system.
The operating problem was familiar.
The promise of The Phoenix Project was that IT work could be managed like a production system once you made invisible work visible, oriented teams around flow, amplified feedback, and built continual learning into daily work.
That lineage runs through Agile, DevOps, CI/CD, incident response, platform engineering, and product operations. The agentic AI era carries those principles into a new work system.
Agents change where reasoning can live
Agents matter because they change where reasoning can live.
Historically, if you wanted software to handle a workflow, you had to make the workflow legible to software first. You had to derive the rules, define the fields, map the decision tree, specify the edge cases, and decide in advance where the system should stop.
That works well for stable processes.
Much of real work resists clean rules.
The inputs are messy. The relevant context lives across tools. The judgment changes by case. The edge cases matter. The work is too repetitive to deserve constant human attention, but too ambiguous to encode into traditional software.
So we accepted three bad options: static rules that broke at the edges, heavy process that forced humans to compensate for the software, or no system at all.
Agents change that tradeoff.
You can now place human-like reasoning in parts of a workflow where you previously had to rely on static rules, rigid process, or manual handoffs. An agent can read messy context, inspect logs, run queries, classify an issue, draft a recommendation, modify a codebase, call tools, and escalate uncertainty back to a human.
The human moves to a better part of the loop.
The operator reviews exceptions instead of manually inspecting every case. The analyst guides an agent through root-cause analysis instead of gathering every signal from scratch. The builder creates generalized tools an agent can compose across problems instead of building a brittle workflow for every edge case.
The shift matters because a single operator can now do work that once required a team, a roadmap, and custom software.
The gain has a cost. Add agents to old workflows without changing the operating model, and you get faster motion, hidden decisions, inconsistent artifacts, context rot, and cleanup work disguised as progress.
Leverage Loops names the operating problem.
A leverage loop is a designed feedback system for agentic work. It turns human intent into agent work, agent work into an artifact, the artifact into feedback, and feedback into a better system for the next pass.
Prompts, models, and tools all matter. The loop around the work matters more.
The agentic operator
The most interesting person in the agent era is the agentic operator.
By agentic operator, I mean someone who understands a domain well enough to know what good looks like, and is technical enough to use agents to build systems around that judgment.
Picture a PM using coding agents to prototype workflows, analyze customer behavior, and turn rough product hypotheses into working software. Or a data analyst using an agent across Slack, BigQuery, Jira, and Confluence to run root-cause analysis that used to take days of manual digging. Or a support, finance, operations, or growth person who knows exactly where the work gets stuck, but historically needed an engineering team to build anything useful around that knowledge.
Operators can gain technical agency without becoming software engineers.
The operator’s advantage is that agents make it possible to install reasoning and feedback loops closer to the work.
The operator can take a messy problem, aim an agent at it, give the agent tools, inspect what comes back, and improve the system after each run.
A root-cause loop across tools
Take a product manager investigating a sudden drop in conversion.
Historically, they might need to pull data from the data warehouse, search Slack for incident chatter, inspect Jira tickets, read Confluence docs for launch context, ask engineers for deploy history, and manually stitch together a story.
With agents, they can start to turn that investigation into a loop.
The PM gives the agent a loose aim: the metric that moved, the hypothesis to test, and the part of the system that seems suspicious. Then the agent explores. It inspects BigQuery and finds the relevant tables or fixtures. It runs small test queries before attempting the full analysis. It checks whether the hypothesis is pointed in the right direction. It searches Slack for related discussion, checks Jira for recent changes, and reads Confluence for product scope, launch notes, and experiment context.
The output is a first-pass analysis with evidence, assumptions, open questions, and recommended next checks.
The PM still owns the judgment, but they move out of the low-level handwork.
The job shifts. The analyst aims the investigation, decides what evidence matters, inspects the artifact, corrects the agent when it chases the wrong thread, and improves the loop so the next investigation starts from a better place.
At first, the operator may validate every step. Then the agent starts proposing a crisp plan and the operator validates the plan. Later, the operator gives the agent a hypothesis, the agent explores, comes back with a better approach, and asks for approval before executing.
For low-risk workflows, users can eventually self-serve through the agent without the original operator sitting in the loop at all.
This is how a single operator starts to make judgment travel farther: by teaching the loop where judgment matters, then moving to the smallest useful validation point.
From flow to loops
The Goal asked where the constraint was. The Phoenix Project asked where flow was breaking down. Leverage Loops asks where the loop is failing.
I keep coming back to that question when agentic work goes wrong. The obvious failure is usually a symptom: bad code, weak analysis, inconsistent output, or a demo that falls apart in real usage.
The first instinct is to blame the model. Sometimes the model is the constraint. More often, the deeper issue is the loop around the model.
The aim was fuzzy. The context was scattered. The tool access was wrong. The agent had too much scope. The artifact was hard to inspect. The feedback never made it back into the system. The next run inherited nothing from the last one.
When that happens, better models help less than people expect. A stronger agent inside a weak loop can move faster in the wrong direction, make more hidden decisions, and produce more convincing artifacts that still miss the aim.
More agent capacity makes the operating model more important.The Leverage Loops model
The framework has three parts:
AIM.
CONTROL.
LOOP.
Lets dive into each.
AIM: the initial bearing
AIM is the direction you are trying to point the system.
For small tasks, the aim may be obvious. Fix the bug. Summarize the document. Add the feature. Draft the email.
Meaningful work rarely starts that clean. You often begin with a hypothesis.
You think the customer problem is one thing, then the workflow reveals another. You think the product needs a feature, then usage shows the real constraint is trust. You think the agent should automate a process, then the failures reveal that the real opportunity is routing, escalation, or better human review.
Good operators can begin with imperfect aim. They need enough aim to begin, and a loop that helps them converge.
The distinction matters because agents can create the illusion of progress.
An agent can build the feature and weaken the architecture. It can answer the question and miss the decision. It can summarize the document and lose the insight. It can automate the workflow and create more cleanup work than it saves. It can satisfy the prompt while missing the aim.
AIM is the discipline of asking what you are actually trying to get the agentic system to do: what kind of progress should the system create?
CONTROL: keeping the system aimed
If AIM gives the system an initial bearing, CONTROL keeps it from drifting while the agent acts.
A large part of losing aim comes from weak control mechanisms. The agent gets too much scope, too little context, no stable source of truth, no way to check itself, and no clear boundary for what should remain unchanged.
So the work drifts.
The prototype works, but the abstractions are wrong. The analysis is detailed, but it answers the wrong question. The workflow runs, but nobody knows when to trust it. The agent makes local progress while the broader system loses coherence.
CONTROL is the set of mechanisms that keeps the system pointed in the right direction long enough to learn from the work.
In practice, control includes context, constraints, tools, permissions, tests, evals, review points, logs, artifacts, and source-of-truth documents.
For the analyst using agents across Slack, BigQuery, Jira, and Confluence, control might mean read-only access to production data, cited queries, and a clear separation between evidence and hypothesis. Control might also mean an incident-style artifact, explicit unknowns, and permission before changing dashboards, writing back to systems, or notifying the team.
Those controls make leverage usable.
They let the agent operate with enough autonomy to create value without letting it quietly drift away from the aim.
LOOP: the unit of agentic work
LOOP is how the system makes progress.
LOOP includes feedback after the work. It also describes the shape of the work itself.
At the smallest level, an agent is constantly moving through a loop: observe the environment, interpret the context, choose a step, use a tool, inspect the result, and decide what to do next.
The adaptive cycle makes agents different from static automation.
A script executes a predetermined path. An agent can react to what it finds.
The same loop creates both the upside and the risk.
An agent can explore a codebase, inspect logs, query data, read tickets, compare docs, test a hypothesis, and update its plan as new information comes in. A good operator takes advantage of that loop. The agent can adapt inside the work, so the operator can define the aim and review the evidence instead of predefining every step.
The loop works only when the conditions are right.
Missing context turns into guesses. Missing tools create dead ends. Weak data access forces the agent to reason from shadows. A messy environment sends the agent chasing the wrong thread. An unclear artifact makes progress hard to judge. No stopping condition lets the loop spiral.
Agents often fail in ambiguous environments because ambiguity requires a stronger loop. The agent needs enough context to orient, enough tools to act, enough structure to evaluate progress, and enough control mechanisms to keep from drifting.
For the analyst investigating a conversion drop, the loop is larger than “ask an agent for analysis.”
The loop is exploration, hypothesis, tool use, evidence, artifact, review, and improvement.
Inside that loop are smaller loops: query, inspect, revise; search, compare, narrow; hypothesize, test, update.
Outside it are larger loops: incident review, dashboard improvement, source-of-truth cleanup, better instructions, better tools, better future investigations.
The plural matters because the loops are nested.
The agent has loops. The task has a loop. The workflow has a loop. The operator has a loop. The system gets better when those loops reinforce each other.
A weak loop creates motion without convergence. The agent keeps acting while the work drifts from the aim. It reads more files without understanding the system. It runs more queries without finding the causal story. It writes more code without improving the product. It generates more analysis without clarifying the decision.
A strong loop creates convergence. Each step produces evidence. The artifact improves judgment. Failure sharpens context. Review improves the next run.
AIM gives the system an initial bearing.
CONTROL creates the conditions for the loop to operate safely.
LOOP is the cycle of work and feedback that moves the system closer to the right aim.
The loop executes the work and reveals what the work should become. That discovery is part of the work.
Shrinking the validation loop
A good leverage loop often keeps human judgment in the system, then gradually shrinks the validation loop.
At first, the human reviews every step because the agent still lacks enough context, tools, or trust. Then the human reviews plans. Later, the human reviews outputs. Eventually, the human reviews only exceptions.
For low-risk, well-understood workflows, the human can leave the loop almost entirely. Other workflows should keep human judgment close to the work.
Autonomy is one of the easiest traps in agentic work. People see the possibility of removing the human and assume removal is the objective.
Useful leverage depends on the right level of control.
Deterministic work should use deterministic software. Stable decisions should become rules. When the same path should run the same way every time, a traditional workflow may beat an agent.
Agents are most valuable where the work requires interpretation: exploring ambiguous context, synthesizing across tools, testing hypotheses, handling messy inputs, and escalating uncertainty.
That kind of work still needs validation. The useful question is where the validation should live, how expensive it needs to be, and how the loop can make it smaller over time.
Why this is different now
Feedback loops were always important. The lineage from The Goal to The Phoenix Project already says as much.
What changes with agents is the cost of installing them.
Previously, much of loop-building required humans to do the glue work: collect the evidence, inspect the logs, update the rules, rewrite the process, and carry context from one run to the next.
Now agents can help build and maintain parts of the loop themselves. A coding agent can create the data pipeline. An analysis agent can inspect the logs. A documentation agent can update the runbook. A review agent can compare outputs against prior failures. A workflow agent can try again with better context.
The operator becomes more important, and the role becomes more load-bearing.
The operator decides what matters. The operator decides where reasoning should live. The operator decides what controls are needed. The operator decides what evidence changes the aim. The operator decides when the system is ready for more autonomy.
The agentic era rewards the person who uses AI to make judgment travel farther.
The enemy is leverage without an operating model
AI creates leverage. The mistake is believing that leverage manages itself.
Drop agents into old workflows without changing the operating model and the pattern is predictable. Output increases while coherence drops. Automation expands while accountability weakens. Speed rises while context debt piles up. Autonomy grows while feedback gets thinner.
The pattern appears when a workflow gains leverage without loops. The agent can act while the system fails to learn. The agent can produce while the operator loses the ability to steer. The agent can move quickly while nobody knows whether the work is converging.
Leverage Loops is meant to diagnose that failure mode.
Move past the question of whether the agent was good enough. Ask where the loop failed: was the AIM clear enough to begin, did CONTROL keep the work pointed in the right direction, and did the LOOP capture feedback and improve the next run?
Those questions work at several levels.
For a coding-agent task, the model becomes the project brief, test plan, and pull request artifact. For a data investigation, it defines the agent’s tools, source access, analysis template, and review process. For an applied AI workflow, it sets routing, escalation, evals, logs, and human validation. For a personal operating system, it governs how context, memory, and project rules improve over time.
The model is simple: AIM, CONTROL, LOOP.
Direction, boundary conditions, converging work.
The operating model I keep coming back to
I expect Leverage Loops to keep changing as I use it.
I am building it in public through coding agents, applied AI workflows, personal operating systems, product work, data investigations, and the messy places where human judgment meets agentic execution.
The more I work, the more I keep seeing the same pattern.
Agents work well when an operator builds a better loop. The operator gives the system an aim, creates enough control for the agent to act without drifting, shapes the work into inspectable artifacts, and uses feedback to tighten the next run.
Over time, the loop gets smaller, faster, and more trustworthy.
I want to keep testing that operating model here.
The factory needed a way to see constraints. Software needed a way to see flow. Agentic work needs a way to see loops.
Leverage Loops gives that work a name.
A prompt can produce output. A workflow can produce repeatable output. A leverage loop improves the system that produces the output.
A leverage loop gives you a way to direct agentic leverage without drowning in side effects: hidden decisions, context rot, brittle automation, and impressive artifacts that miss the point.
The deeper work is installing loops that let agents reason inside the workflow while humans stay responsible for aim, control, and judgment.
The Goal taught us to manage constraints. The Phoenix Project taught us to manage flow. I want Leverage Loops to teach how to manage feedback systems around intelligent agents.
Aim the system. Control the work. Close the loop. Then use what you learn to build the next one.