Loop Engineering Is Deciding Which Unknowns to Close, on Which Clock

One engineer ships a feature that “passes” the agent’s self-checks. Tests green. PR summary confident. Demo polished.

Then a teammate asks one boring question: “What if two people book the last table at the same time?”

That case was never written down. The model filled the gap with a fluent default — “first click wins,” no waitlist, no apology email, no refund path. The loop ran for an hour. The map said “done.” The territory said “angry customers on a Friday night.”

That failure is not mainly a model-quality problem. It is a loop design problem — and an unknowns problem.

“Loop engineering” became a buzzword after builders said the quiet part out loud: stop living inside one chat; design systems that re-prompt agents, measure progress, and decide what to do next. Andrew Ng framed the product view that matters for 0-to-1 work: you are not running one loop. You are running three, on three clocks.

Thariq (Claude Code at Anthropic) published the missing half in A Field Guide to Fable: Finding Your Unknowns: with long-horizon models, quality is often bottlenecked by your ability to clarify unknowns — the gap between the map you give the agent and the territory where work actually happens.

This is the bridge I want on my desk this week:

Loop engineering without unknown-finding is a factory that manufactures the wrong product faster.

Three loops, three clocks (brief)

Ng’s diagram, in one table:

Loop	Cadence	Who drives it	Job
Agentic coding	~minutes	Agent + spec/evals	Draft: write, test, iterate until a stop condition
Developer feedback	~hours	Human steers agent	Shape the product: taste, architecture, “I know it when I see it”
External feedback	~days	Users / market	Signal: update beliefs about what to build

Loop engineering is scheduling judgment, not merely scheduling tokens.

Minutes without a true stop condition → confident thrash.
Hours without human judgment → rubber-stamp demos.
Days without leaving the building → private gym, public irrelevance.

The novel move is not restating these clocks. It is asking, for each clock: which class of unknown is this loop allowed to close? And: how does that loop move across the map without pretending the map is the whole world?

The map is not the territory

What the map is

When people say “I prompted the agent,” they are drawing a map.

The map is everything you deliberately put in front of the model so it can move:

the goal (“build a simple expense splitter for three roommates”)
the constraints (“mobile-first,” “no login in v0,” “export CSV”)
the skills and checklists
the files you attached
the repo paths you named
the evals you defined as “done” (“user can add expense and see balances”)

Maps are useful. Maps are also lossy. They compress a messy world into language a session can hold — the same way a tourist map shows three metro lines and pretends the city is that simple.

What the territory is

The territory is what is true whether or not you wrote it down:

the codebase as it actually is (old auth, flaky tests, a payment library you forgot exists)
how people really behave (roommates forget receipts; diners cancel late; users paste screenshots instead of forms)
taste you only recognize when you see four layouts
constraints that appear only mid-implementation (the SMS provider blocks your country; the calendar API has no “hold seat for 5 minutes”)
trust: what people will actually use on a busy Tuesday, not in a demo

Territory does not care about your confidence. Territory only cares whether the artifact works when it hits reality.

What unknowns are

Thariq’s operating lesson: the gap between map and territory is a set of unknowns. When the agent hits an unknown, it does not pause like a careful junior engineer unless you designed for that. It guesses — often fluently.

Better long-horizon models do not create unknowns. They run further on a wrong map before a human notices. That raises the cost of an unexamined map.

Four kinds of gap (with everyday examples)

Use these as a working checklist, not a religion:

1) Known knowns — already on the map.

Example: “Users can add an expense with amount, payer, and who shared it.” You told the agent this. Good maps start here.

2) Known unknowns — you know you have not decided.

Example: “We have not chosen whether currency is always USD or multi-currency.” If you leave this off the map, the agent will invent a default (usually the simplest) and call it product.

3) Unknown knowns — you would recognize the right answer if you saw it, but you cannot specify it in advance.

Example: how dense the home screen should feel; whether “Settle up” should feel playful or serious; whether a red badge reduces stress or creates it. These need prototypes and reaction, not more adjectives like “clean and modern.”

4) Unknown unknowns — you did not know to ask.

Example: App Store rejects “split bill” apps that look like money transmission; users primarily split in WhatsApp and only open your app when someone is angry; daylight saving breaks recurring “every Friday dinner” reminders.

Three short scenes (map vs territory)

Scene A — Shared expense app.

Map: “Track who paid what and show who owes whom.”

Territory: partial payments, “I’ll get the next one,” people who never settle, foreign currency on trips.

Wrong loop behavior: the agent ships perfect math for equal splits only. Tests pass. First real trip, the app becomes a fight generator.

Scene B — Restaurant booking.

Map: “Pick a time, party size, confirm reservation.”

Territory: double booking, no-shows, peak Friday rush, kitchen capacity that is not “tables × 2.”

Wrong loop behavior: the agent builds a beautiful calendar UI and never models the kitchen. Demo day looks fine. Friday night does not.

Scene C — Personal habit tracker.

Map: “Daily check-in, streak counter, simple charts.”

Territory: people lie to streak counters; motivation dies after travel weeks; “flexible goals” matter more than perfect red X’s.

Wrong loop behavior: the minutes-loop optimizes streak animation. Hours-loop later discovers the product is guilt software. Days-loop (if you ever ship) confirms churn.

Caveat: this is an operating model for agentic work, not a formal science of all learning. It is a way to talk about risk when agents act fast.

How a loop actually navigates the map

Think of the map as a route sketch and the loop as a vehicle that can only see through instruments you installed.

1) The loop only drives roads that exist on the map

An agentic coding loop does not explore “all of product space.” It explores the graph implied by your prompt, tools, and stop conditions.

If the map says:

Screens: Home, Add expense, Balances. Buttons: Add, Delete, Settle all.

…the minutes-loop will pave those roads — even if territory needed:

Partial settle, “mark as paid outside the app,” and a note field for “I already Venmo’d you.”

The loop is not stupid. It is obedient to the map. Obedience is a feature of agents and a hazard of incomplete maps.

A healthy minutes-loop roughly does:

Sense — read files, run tests, open pages, inspect errors.
Act — edit code, generate UI, call tools.
Check — evals, tests, linters, your “done when” criteria.
Update — either the implementation (still on the same map) or escalate to change the map itself.

Most broken loops only update implementation. They never escalate map errors. That is how you get an hour of polish on the wrong product shape — a shinier “Settle all” button when users needed “Settle $12 of $40.”

This is the part people skip when they say “just run a loop.”

Clock	What the loop is allowed to navigate	What it must not pretend to settle
Minutes	Code paths, tests, local consistency with the current map	Product meaning, user trust, market truth
Hours	Map revisions from human taste and architecture judgment	“Customers will love this” without signal
Days	Beliefs about users, workflow adoption, willingness to change behavior	Whether the last PR’s unit tests are green

Minutes-loop navigates the map.

Hours-loop redraws the map.

Days-loop tells you whether the map was about the right territory.

If you only run minutes, you get a more detailed wrong map.

If you run hours without days, you get a prettier internal consensus.

If you run days without minutes, you get strategy theater with no artifact.

4) Unknowns are fog on the map — loops need wipers

Unknowns are not “extra philosophy.” They are places where the vehicle will invent a road.

Known knowns → pave with skills and evals (minutes can cruise).
Known unknowns → put a stop sign: interview, decision log, “do not invent.”
Unknown knowns → force scenic overlooks: prototypes, variants, human reaction.
Unknown unknowns → blindspot pass, peer review, real users — or they become silent defaults.

A loop without unknown-handling is a car with no fog lights: it still moves; it just hits things faster.

5) A walkthrough anyone can picture: roommate expense app

Map (v0 prompt):

“Build a web app for three roommates. Add expenses, show who owes whom, settle all. Clean UI. No login for v0.”

Minutes navigation:

Agent builds forms, balance math, a green “Settle all” button. Stop condition: clickable demo with sample data.

→ Territory collision: real roommates settle partly, pay outside the app, and argue about “shared” vs “personal” groceries. The map never mentioned partial settle.

Hours navigation:

You react to the demo. The map is redrawn:

“Settle all” becomes “Record a payment” (amount + note + who paid whom)
“Shared by all” vs “custom split”
Soft language: “balances,” not “debt collection”

The agent is steered. The map changes. That is the hours-loop doing its job.

Days navigation (the real test):

Unknown still on the fog line:

Will the three roommates open this app every week — or keep using a group chat and a spreadsheet screenshot?

No amount of minutes-loop polish closes that. Only territory can: real use, real nagging, real abandonment.

That is loop engineering with map discipline: each clock has a navigation job, and map updates are first-class, not shameful interruptions.

Loops × unknowns (the useful table)

Clock	Typical unknowns	How the loop navigates	Cheap detectors	Bad outcome if skipped
Minutes	Bugs, edge cases in code, missing tests	Move inside current map; log deviations	Blindspot pass, evals as stop conditions, implementation-notes	Green tests on the wrong product rule
Hours	UX taste, feature shape, architecture bets	Redraw map after human reaction	Multi-variant mocks, interviews, references, quiz-before-merge	Beautiful code for the wrong shape
Days	Will people change habit? Will they pay/trust/return?	Confirm or kill the territory hypothesis	Real users, support load, retention	Internal consensus mistaken for fit

Spend tokens only after you know which unknown the loop is supposed to close.

Practices that move the needle

Minutes (navigate the map you have)

Blindspot pass — ask for unknown unknowns with who you are and what you already know.

Example: “I’ve never built payments. Do a blindspot pass on what I’m not seeing before we implement Settle.”

Implementation notes — when territory forces a detour, pick a conservative option, log it under Deviations, keep going. That log is a ticket for the hours-loop.
Evals as done — “balances update after add expense” beats “looks good in the transcript.”
Harness — tools, sandbox, permissions, trajectory: keep high-frequency loops from becoming high-frequency incidents.

Hours (redraw the map)

Prototype before wiring — fake data, multi-direction mocks; react, then implement.

Example: four home-screen variants before any database.

Interview mode — one question at a time; prioritize answers that would change architecture.

Example: “Is v0 multi-currency, yes or no? Your answer changes the data model.”

References over adjectives — “Make it like Splitwise’s settle flow” beats “make it premium.”
Quiz before merge — if you cannot explain the change, you do not own it.

Days (test the territory hypothesis)

Multi-agent agreement is hours-loop feedback, not market signal, unless a real user is in the loop.
Last mile is the job: deploy, integrate, account for outcomes.
External signal that never rewrites skills, evals, or product bets is tourism — the map never updates.

Worked example: one weekend product (bounded)

Imagine you and an agent build a roommate expense splitter over a weekend.

Minutes: agent navigates your first map into a working demo — add expense, see balances, settle all.
Hours: you use it for ten minutes and feel the friction — redraw the map toward partial payments and notes.
Days: you ask two real roommates to use it for a month. The open unknown becomes concrete: Do they open the app, or still settle in chat?

Bounded claim only: the weekend validates that you can ship a workflow prototype.

It does not validate that the product becomes a habit, that people will pay for it, or that it replaces WhatsApp.

If you only optimize the minutes loop, you get a prettier way to enforce the wrong rule (“always settle 100%”) with more confidence — a better vehicle on a worse map.

What loop engineering is not

Not “I never talk to the model.” You still design goals, evals, and unknown-finding rituals.
Not maximum autonomy as a moral good. Autonomy without stop conditions is unattended risk.
Not token-maxing without artifacts. Spend is fine when it buys clarity and fewer unknown unknowns next week.
Not replacing product management. The days loop is product work. Agentic coding made deciding what to build more valuable, not less.
Not “the map is useless.” Maps are required. Maps that never get redrawn are the problem.

Operating checklist

Before a heavy agent session:

Write four ugly lists: known knowns, known unknowns, unknown knowns, unknown unknowns.
Assign each a clock: minutes / hours / days.
For minutes items, define a stop condition (eval/test).
For hours items, schedule a map checkpoint (prototype, interview, review).
For days items, name the territory question in one sentence (who must change behavior, and how would you know?).

If everything is assigned to minutes, you are not doing loop engineering. You are doing optimistic autocomplete.

While the agent runs, watch for this smell: lots of navigation, no map updates, rising confidence. That is fog with the headlights off.

Closing

Design the loop.

Design the map.

Design how unknowns force a redraw.

Then spend the tokens.

The builders who win will not be the ones with the longest agent transcripts. They will be the ones who know which feedback is allowed to change the map — and how often.

Minutes navigate.

Hours redraw.

Days decide whether the map was about the right world.

References

Andrew Ng — three product development loops (agentic coding / developer feedback / external feedback); The Batch / related posts on loop engineering for 0-to-1 products (Jun–Jul 2026).
Thariq (@trq212) — A Field Guide to Fable: Finding Your Unknowns (X Article, Jul 2026).
Related here: Agentic Engineering, The Last Mile Is the Job in the AI Era, Token-Maxing Is Not Waste, Not Every AI Agent Should Be a Coding Agent.