The Second Loop
A modern fighter jet is built so unstable it cannot fly itself. A computer flies it instead, correcting dozens of times a second. Your life is the unstable airframe — and right now, you are the computer.
The F-16 was one of the first aircraft designed to be aerodynamically unstable on purpose. Left to itself it doesn't settle into a glide; it diverges — the nose wanders, and the whole machine tends away from level flight rather than back toward it. That isn't a defect. The instability is what makes it agile: a stable airframe resists being turned, while an unstable one practically falls into the turn. The catch is that no human can fly it. The corrections come too fast and never stop. So a flight computer sits in the loop, reading the state and nudging the control surfaces many times a second, and the instability becomes a feature. Take the computer out and the jet tumbles in seconds.
Your life is that airframe.
It isn't naturally stable either. Commitments rot if they aren't tended. Plans rest on assumptions that quietly go stale. Attention scatters. And the world keeps applying disturbances — an email that reopens a settled question, a meeting that moves, a travel rule that changes, a half-promise made at dinner that never made it into any system. Left alone, the state drifts, and it rarely drifts somewhere good. The only thing holding it level is you, running the correction loop by hand, in working memory: the didn't I say I'd, the wait, did that ever get sorted, the I should check before. You are the flight computer. And you are saturated — because the loop never stops, and you are also trying to live the life you're busy stabilizing.
So here is the question this essay is about. We are about to point a great deal of AI at this problem. What, exactly, should it be?
The obvious answer is a better sensor. Connect everything, watch every surface, get smarter about what to surface, build a sharper inbox. But look at what that does to the picture above: it hands a saturated pilot a louder warning light. More to perceive is more load, not less, when the controller was the bottleneck in the first place. The airframe doesn't need to see more. It needs a second loop — something else in the loop that holds it level, so the pilot can fly.
That reframe inverts the objective. Most software competes for your attention; the thing that would actually help has to compete to need almost none of it. The goal is not to maximize how much it notices or how helpful it appears. The goal is to keep the system from drifting into a bad state while spending as little of your attention as possible. Nearly every "proactive assistant" that curdles into one more anxious feed got that backwards — it optimized coverage, and coverage is paid for in the one currency the user can't spare.
A control loop can hold something stable only if it can do two things: measure how far the system has drifted, and act to pull it back. Those two halves are the rest of this essay. One turns out to be an observability problem and the other a controls problem — and the interesting part is what happens when you wrap both around a single number.
The number you're trying to keep small
Start with the number. Call it drift: one quantity for how far your life has wandered from a state you'd call stable — promises kept, plans sound, nothing important silently rotting. Write it $V$. A good controller keeps $V$ small, or at least keeps it falling back down whenever the world knocks it up: $\Delta V < 0$ under the disturbances that actually arrive. (Control theory has a name for a quantity a system is built to keep descending. We'll get there.)
The first hard problem is that you cannot read drift off raw events. Events are a flood — messages, calendar pings, ticket updates, docs, news — and almost none of them move the number. Treating each event as a thing to evaluate is exactly how you get the anxious inbox: a system forever asking this happened, should I say something? The thing that actually moves drift isn't an event. It's a situation — a few correlated signals that together touch a promise. Five Slack messages, a moved meeting, and a stale doc might be one situation, not seven interruptions. The unit of the problem is the situation; almost all of the events are noise around it.
Your life already has SLOs
This is, very precisely, the problem observability was built to solve — so it's worth borrowing the architecture wholesale, not as a metaphor.
A production system emits a firehose of telemetry, and nobody watches it directly. Underneath sit logs (the raw lines), metrics (a few numbers that summarize health), and traces (the causal chain of how one request became a problem). On top sits the only thing that matters operationally: the SLOs — the explicit promises about what the service guarantees. And the rule mature teams converge on is that you do not page a human because a log line appeared. You page when an SLO is about to burn. Cause-level noise stays on the dashboard; only promise-level risk earns an interruption.
Map that onto a person and it lines up cleanly:
| Production system | Your life |
|---|---|
| Logs | Messages, mail, transcripts |
| Metrics | Age of an open loop, overdue replies, prep completeness |
| Traces | The thread — how a decision weeks ago became tomorrow's question |
| Service map | The people and projects you depend on |
| SLOs | Your promises |
| Page on SLO burn | Act on drift, not on noise |
Drift is just how close those promises are to breaking. And the payoff is that observability is the only mature answer we have to the exact thing a controller needs: turning a flood of signal into one trustworthy reading of how far from fine are we? You don't get that number by watching harder. You get it by correlating events into situations, mapping situations onto promises, and measuring the promises. Sense, in this system, is an observability pipeline — and its output is $V$.
Put the two halves together and the shape is just a loop:
The second loop
Given a live reading of drift, what kind of loop should act on it? Control theory offers a ladder, and each rung is a better answer to keep $V$ bounded for the least attention.
Feedback is the bottom rung: wait until the error is visible, then correct. This is essentially every assistant today — you notice the drift yourself, you ask, it helps. Genuinely useful, and also the pilot already fighting a nose that's dropped. It acts late, and it still spends your attention on the noticing.
Feedforward is the next rung: model the disturbance and correct before the error shows. Better in principle, brittle in practice. Pure feedforward acts on a prediction, and when the prediction is wrong it injects an error that was never going to happen. An assistant that front-runs your life on guesses doesn't save attention; it spends it on phantoms — and it burns trust faster than silence ever would.
Model-predictive control is the honest version, and it's the one this design wants. At each step it estimates the current state, rolls the model forward over a horizon — what could make tomorrow's meeting go badly, what plan is resting on something nobody checked, what's about to go stale — weighs the branches, then commits only the next safe step and recomputes when new information lands. It looks ahead like feedforward but acts like a careful person: one bounded move at a time, never betting the farm on a forecast. And it has an advantage here it never has on a jet — life is slow and compute is fast, so the loop can actually run the branches you never have time to. It can notice that the trip you're about to book routes through a permit-controlled border region, and that one traveler's citizenship might make it a problem — the kind of thing you'd otherwise hit at the worst possible moment, after the money's spent.
Lyapunov is the rung that names the objective the others were circling. A Lyapunov function is a quantity you can prove a system keeps driving downward; if you can always push it down, the system is stable no matter what the world throws at it. That's the real goal — not activity, not coverage, but a guarantee that drift trends back toward zero under real disturbances. With one amendment that changes everything downstream: the control effort is your attention, and it sits inside the cost. So the controller isn't solving "minimize drift." It's solving "keep drift bounded while spending the least attention" — every action weighed against the error it actually prevents.
You can feel the difference between the rungs better than you can read it. Here's the same unstable system under each controller — push disturbances at it and watch what each does to the drift line, and at what cost:
The reactive loop lets drift climb until it's bad, then scrambles. The eager one twitches at everything and burns attention on corrections that were never needed. The receding-horizon loop holds the line nearly flat with a handful of well-timed moves. Same disturbances; very different bills.
The rules were the cost function all along
Here's the part that surprised me. Once attention is in the cost, a stack of things that look like interface taste stop being taste at all. They fall out of the math — they're just what minimizing attention while keeping drift bounded forces you to do.
Anxious in analysis, calm in speech. Sensing and simulating are cheap and private; speaking is expensive and public. So the optimal controller worries constantly and interrupts almost never. It runs hot on the inside and quiet on the outside — not as a personality, but because that's where the cost lives.
Prepare before you interrupt. If an action has to spend an interruption, it had better land. "An email came in" wastes the cost. The same interruption arriving already triaged — what changed, why it matters, what's been checked, what you could do — pays for it. The expensive channel should only ever carry prepared judgment, never a raw fact.
Use the quietest channel that works. Among all the inputs that push drift down, prefer the cheapest one that holds: a calm queue you pull when you want, a card, a glance. Reserve the hard interruption for when nothing cheaper will keep the system stable.
Spend at the seams. The same nudge costs differently at different moments — intrusive at 10:05 inside the meeting, nearly free at 9:55 on the walk there. A cost-aware controller waits for the seam instead of firing the instant it knows.
And the asymmetry that orders the whole roadmap: a miss usually just lets drift float back to where you'd have been anyway — recoverable. A confident wrong action adds a disturbance that wasn't there — new harm. So the controller earns the right to act in proportion to how reversible the action is. Recall and reminders first, where being wrong costs a glance. Drafts and prepared options next. Anything autonomous and hard to undo last, and only once the loop has been right often enough to be trusted with it.
Which collapses to one line. A notification adds to your drift. A good escalation subtracts from it. Most of what ships does the first and calls it help.
Presence is the loop running without you
Run this loop well and the thing that changes isn't your output. It's that you come out of the correction loop. The capacity you were spending to hold it all in working memory comes back, and that recovered capacity has an ordinary name: presence. The point was never to make you do more, or to make you more interruptible. It was to keep the system stable while taking you out of the business of watching it.
There's a failure mode worse than doing nothing, and it's worth naming because it's the easy one to build. A miscalibrated second loop doesn't merely fail to help — it adds disturbance. More pings, more low-confidence guesses, one more surface that needs tending. In control terms, a controller that increases the very quantity it was meant to reduce is worse than no controller at all. Every honest version of this has to stay on the right side of that line — which is why the bar for shipping isn't "it did a lot." It's a feeling: I'm still in control, but I'm no longer the only thing keeping my life from slipping — and I'm more present because of it.
Step back and the strange thing is how alone the human is here. We've wrapped a control loop around nearly everything that has to stay stable while the world pushes on it — the thermostat on the wall, the autopilot in the air, the governors on the grid, the autoscalers and alerts around every service in production. The conspicuous holdout is the person stabilizing their own life by hand, in working memory, because until recently nothing else could even hold the picture. That's the gap worth building into. Not a smarter chatbot. A second loop.
We've been building Lya to find out whether the shape can be made real — drift watched quietly, situations instead of events, nothing leaving without your say-so, silence as the default rather than the exception. It's a scripted demo for now, not running on your data; the point is to make the laws above legible enough to argue with. If you want to see what the loop feels like from the inside, you can walk through it.
Thinking with
Lyapunov stability. The idea that a system is stable if you can find a quantity it always drives downward — the namesake, and the cleanest way to say "keep drift falling no matter the disturbance."
Model Predictive Control / receding-horizon control. Estimate the state, look ahead over a horizon, commit only the next safe step, recompute as new information arrives. The honest middle between reacting and over-committing.
Google's SRE practice and alerting on SLOs. Page on user-facing promises and error budgets, not on raw causes — the discipline that keeps an alerting channel worth listening to, and the direct ancestor of "act on drift, not on noise."
Observability — logs, metrics, traces. The machinery for turning a firehose of telemetry into one answer to "are we okay?" Borrowed here as the sense half of the loop.