Stable Direction, Evolving Path

I woke up late that morning.

My goal was clear: be at the entrance to Hall 8 of Tokyo Big Sight by 9

AM. Nothing else was ready. I hadn’t packed what I needed to bring, I hadn’t looked up the route ahead of time, and by the time I walked out the door, I was flustered.

At the door, I opened my transit app and typed in the destination. It gave me a route: which train to take, which station to transfer at, which platform to go to, and when I was expected to arrive. Then I made a decision I barely noticed at the time, though in hindsight it turned out to be crucial: for the entire trip, I never closed that route screen, and I never ran a new search.

The trip itself did not go smoothly. When I got to the station, the trains were delayed. I learned later that the driver on an earlier train had fallen suddenly ill, setting off a chain of delays down the line. The crowd on the platform kept growing, and the departure times on the digital board kept ticking further back.

Normally, I probably would have searched again at every transfer station to see what the fastest route was “right now.” That day, I didn’t. Whenever a train pulled in, I just glanced at its final destination, train type, and platform number, and checked them against the route from when I left home: Was this the train in my plan? If yes, I got on; if not, I waited.

I checked my way forward like that, one stop at a time. At 9

AM, I was standing at the entrance to Hall 8 right on time.

Generating a Plan and Verifying a Plan Are Two Different Things

When things change unexpectedly, it is easy to fall into one of two traps: either you scrap everything at the first sign of trouble and search for a new route at every transfer station, or you cling blindly to the original plan and keep waiting even when you know the route is blocked.

The first reason that morning went well is that I unintentionally separated two actions.

Tapping search as I walked out the door was generating a plan based on the state of things at that moment. Looking at the digital board on the platform and checking each arriving train was verifying the plan against the reality in front of me to make sure I was still on track.

I generated a plan only once, right as I left home. For the rest of the trip, I simply checked what I observed against that original plan, instead of feeding the delayed state back into the app to get a new route.

Why not search again once the delays started? Because the moment a delay happens is precisely when information is at its messiest. When trains have just been held up, the live data in a transit app may not have caught up yet, and the “faster route” it suggests may turn out to be just as backed up by the time you get there. Resampling at the noisiest moment does not necessarily produce a more accurate plan than the original one. By contrast, the route calculated before I left home came from a relatively clean state, which made it a better reference point.

More importantly, I was flustered that morning. When you are flustered, the last thing you are good at is gathering fresh information and weighing trade-offs on the spot. Keeping the route fixed took that load off my mind: it turned an open-ended question that required rethinking—“What should I do now?”—into a simple check: “Is the train in front of me the one in my plan?”

Check the Structure, Not the Details

That raises an obvious question: if the trains were delayed and every timestamp in the plan was wrong, why did the original plan still work?

Because delays like this on Japanese rail lines tend to move the whole line together. When a driver falls suddenly ill, it doesn’t affect just one train; it pushes back every train along the line in sequence. All the exact times were off, but the structure of the route itself had not changed: it was still the same lines, the same transfer stations, the same platforms, and the same direction of travel.

So what I checked that day was never the exact time on the clock, but which train it was—where it was bound, whether it was rapid or local, and which platform it stopped at. Timestamps are details that are easily thrown off; train services, platforms, and transfer connections are the stable structure.

If I had been checking by the clock and seen that the 9

train hadn’t arrived, I would have immediately concluded that the plan had failed, started searching for new routes, switched platforms, and scrambled back and forth. By checking only against the stable structure, the original plan stayed valid for as long as the transfers still connected.

When small local opportunities came up, I could still adjust on the fly within that structure. On a crowded platform, announcements, signs, and the flow of people in line all helped me find the right platform faster; or if an earlier train heading the same way pulled in first and made the same stops, I could get right on once I confirmed it reached the same transfer station. Which specific train I rode could change; the structure of the route and where I was headed stayed the same.

When It Is Actually Time to Replan

When, then, does an original plan actually stop working?

Looked at the other way around, the answer is straightforward: if only my first line had been delayed that day, and the transfer after it was a connection that could not be replaced once missed, the plan would have broken at the transfer station. Once the structure of the route is broken, sticking to it makes no sense, and that is the moment you have to run a new search.

That gave me a practical rule of thumb: when a disruption only shifts the details, keep following the original plan; generate a new plan only when the disruption breaks the plan’s structure.

Advice like “adjust when changes exceed your tolerance threshold” sounds reasonable, but it is hard to use in practice because nobody can define that threshold in the moment. Replacing it with “Do the key nodes in the plan still connect?” gives you a question you can answer on the spot.

The same principle applies to everyday work and to designing AI agents.

In a project, the user problem you are solving and the standard for delivery are the direction; the specific approach, schedule, and division of work are the route. If a team changes direction every day at the slightest shift in details, it just spins in place. It is the same when an agent executes a complex task: define the goal, constraints, and acceptance criteria clearly at the start; later, when a tool call fails or a small deviation comes up, retry or work around it within the current path first, and stop to replan only when the original approach turns out to be unworkable, a key assumption no longer holds, or the user changes the goal.

Of course, this approach rests on a premise: you need a clear destination to begin with, and it has to be possible to map out a route in advance.

If you haven’t even figured out where you are going yet—say you are just beginning to explore a new direction and still testing what you actually want to build—locking in a plan up front will work against you. Or if the environment is changing so fast that the route’s structure breaks every few minutes, you have no choice but to stop and check the map more often. And if you find out halfway there that the exhibition has been canceled, what needs to change is not the route, but the destination itself.

It is just that most of the time, what we are dealing with is neither “the exhibition was canceled” nor “the station collapsed,” but simply “the train is a few minutes late.”

At times like that, the best approach is to work out the route carefully once before you leave, and on the way, simply check whether the train in front of you is the right one. Wait when it is delayed; start over only when the structure breaks. Moving forward through change comes not from making a fresh optimal judgment at every step, but from knowing which judgments you don’t need to make again at all.