In my last article, I wrote about coming back from my backpacking trip and realizing that work had kept moving while I was gone, but I still couldn’t easily get myself back into it.
I wanted to dig deeper into why this felt so difficult. I had finished a Substack article before I left and tucked it away in drafts so it could publish while I was gone. I didn’t want a full month with no posts, even though that’s sort of what happened. I also had agents continuing to read what was happening in the news and come up with new topic ideas, article angles, and bullet points.
So there was ongoing activity, and there were bread crumbs, but when I got back, I still had a bunch of work that had been left in flight from several weeks before, and most of it was no longer in my short-term memory. It was extremely frustrating to stare at a massive amount of work and feel like I had no momentum to get it moving.
I could see the tasks, Slack threads, local codebases, context files, notes, and agent summaries, but trying to get the context back in my head felt like an impossible task. Every time I tried to reinsert myself, I felt like there was too much to absorb. I tried to use AI to help me figure out which things I should focus on first, but that led me in circles.
So I did what I often do when a restart feels expensive: I kept kicking the can. I had physically returned from the trip, but it still took a couple of weeks to really get back into things again (this may or may not have also applied to my exercise regimen).
You’ve probably felt some version of this on a large project. You spend the whole morning trying to get the work started again, but the process of getting started eats up all your time and you make zero progress. Then the same thing happens the next morning, and eventually you change direction because restarting the project feels too confusing. It’s like streaming the newest season of a show you like, but the recap proves you only remember the highlights, not the plot details behind why anyone is mad at anyone else (hello, Silo Season 3).
That’s what I keep focusing my thoughts around now; AI can help work continue while you’re away from it, but that doesn’t mean the work is ready for you when you come back. A pile of output isn’t the same thing as a usable handoff.
Preserved Doesn’t Mean Ready
Some of the AI-generated work helped. I was able to read summaries and get a quick sense of what I had missed. Somewhat unsurprisingly, when you miss a few weeks of AI news and then read it all in one summary, it doesn’t feel like things have changed all that much. That’s its own weird part of following AI: the news makes us feel like things are changing so fast you can’t keep up, but the underlying problems haven’t changed much.
The harder part was figuring out which summaries still mattered. Why did this idea seem important to me when I saved it? Was this a real strategy direction or just a passing idea? Which summaries were worth trusting? Which ones connected to the larger arc I had been trying to build?
A backlog of unread AI documents doesn’t save me time if I’m not reading it. A list of possible post ideas doesn’t help much if I can’t remember which idea had real energy behind it. A draft is useful, but only if I can still tell what I meant when I started it.
That’s where the handoff starts to matter. The handoff isn’t always from one person to another. A lot of the time, it’s from the version of me who was deep in the work to the version of me who’s trying to restart it later with only partial memory... and I don’t always leave that future version of myself enough to work with.
AI Makes Parallel Work Easier Than Parallel Context
This is where I really struggle with using AI for difficult tasks.
If I’m working through a new product feature, I usually don’t know the shape of it at the beginning. I talk to people. I research. I look at my own tool usage. I start forming opinions. But building it sometimes shapes those opinions. I don’t always know what the shape of the tool should be until I start building it.
That makes the handoff to an agent weird. I’ve read plenty of advice that says you should give the agent a clear goal and let it go do the work. I understand the appeal. There are times when I wish I could type /goal build a successful unicorn, walk away, and come back to an IPO draft waiting for me.
That’s obviously not how it works, but don’t let me stop you from one-shotting your way to fame and fortune.
If I’m building a product feature, I don’t want AI to just generate the average version of that feature based on a statistical analysis of every product feature the model was trained on. I want the thing to be specific and dialed in. I want human input in the middle of the process, because the middle is where a lot of the judgment happens.
But that creates a coordination problem. Sometimes an agent works for fifteen minutes. Sometimes it works for an hour. I don’t always know how long it’s going to chug on a specific subtask. If I sit there staring at the screen, I’m not using my time well. If I go work on something else, I start a second thread of attention.
Then maybe I start a third. Then a fourth. Suddenly the problem isn’t whether AI can be helpful; the problem is that each workstream is now competing for the limited clock cycles in my brain.
That sounds productive until I have to come back to the first stream. By then, I don’t just need the output. I need to remember what I asked for, what I cared about, what I was willing to skip for now, and what I expected to review. If that stream stalls near the end of the day, I tell myself I’ll pick it up in the morning. By the next morning, the details, meaning, and purpose have already started to fade.
I can’t tell you how many times I typed “what should I be reviewing here?” in response to a long wall of text that an AI delivers back to me.
The Tools Don’t Share the Whole Story
The sheer number of tools makes this worse.
On my Mac, I tend to work in coding agents and local repos. When I’m on the go, I use chat tools and voice mode. I’ll talk through a product idea while driving, and that conversation can be useful because it helps me organize my thinking. AI is good at helping me amplify my ideas and get them focused, especially with my ADHD brain.
But the conversation I had in voice mode doesn’t automatically know what happened in a coding session. The coding session doesn’t automatically know what I talked through while driving. The planning notes don’t always know which decision got made in Slack.
So I end up building little handoff packages for myself. I pull together context files, reference files, notes, summaries, links, and whatever else I need so the next tool or the next session has a sliver of a chance of understanding what came before. It works, but it’s always been more friction than it should be.
The tools are getting better, and some of this may eventually become a moot point inside a single company’s products. But the problem gets harder when work crosses tools, people, teams, and companies. That’s where I still see the handoff break down.
Teams Hit the Same Problem
I’ve seen companies struggle with this too, especially when product or go-to-market people use AI to explore an idea, build a prototype, or sketch out a workflow, and then need to share it with engineering.
They come up with all sorts of manual ways to move the work. They generate markdown files, export mockups, save screenshots, zip up folders, paste transcripts, write setup notes, and hope the next person can recreate the state of the work.
Rarely does it transfer cleanly. Not because anyone did something wrong, but because so much of the work was built on local context instead of shared team context. The prototype may look impressive on one machine, but the useful context is scattered across chat history, local files, generated docs, assumptions, and decisions that never became part of the team’s understanding.
That’s when the handoff becomes its own project. Before anyone can continue the work, someone has to stop and reconstruct the state of it. This is already annoying when you’re handing work back to yourself. It gets much harder when the next person doesn’t have the half-remembered context in your head, doesn’t have access to every tool you used, and doesn’t know which artifact you considered final.
What Needs to Travel With the Work
I don’t think the answer is forcing all work into one giant tool. That makes sense in a software diagram and tends to be miserable in real life. People already work across too many places, and that isn’t going away just because AI is involved.
The better question is what needs to travel with the work.
A useful handoff doesn’t need to include every artifact. It needs enough current state that the next person can continue without rereading the whole history. What were we trying to do? What changed? Which decisions were made? What are we still unsure about? Which artifact is the one to trust? What should happen next?
Those questions aren’t exciting, but they’re the questions that make work resumable. They matter more as AI makes it easier to create parallel streams of work in parallel tools with parallel transcripts.
Without some efficient way to carry that state forward, the connective tissue is still mostly human memory. And speaking from my own experience, we have flaws in how we remember things.
That worked better when the amount of produced work was limited by how fast people could make it. It strains when one person can create a week’s worth of new material before lunch.
The Part I Keep Coming Back To
Focus Over Features started with the idea that when you can build anything, the hard part is knowing what should exist. I still believe that. Lately, I’m feeling the companion problem more painfully: when tools can help us produce more work than we can comfortably hold in our heads, the work has to leave behind enough shape that we can understand it when we return.
This matters for engineering, sure, but it really impacts all the teams within a company. It matters for product, sales, operations, client work, and any team where people are using AI to think, generate, summarize, prototype, or plan. No one is really questioning whether these tools are powerful. They obviously are. The question is how we use them together without feeling like we work for the AI, shuffling data back and forth between tools all day.
I’m still working through that. Some of this friction will disappear inside individual products. But the harder problem is cross-tool, cross-person, cross-team, and cross-time. That’s where the handoff breaks down and that’s the tool that’s missing.
Ryan, the distinction between preserved work and work that is ready to resume seems especially useful. I would put the next decision beside the trusted artifact: what needs reviewing, what was already accepted, and which uncertainty could change the answer. A directory of complete files can still leave that decision invisible. The handoff is easier to use when the returning person can make one concrete decision before reading the whole history.
Recoverable progress requires more than saving the latest draft. In proposal tests, I keep the first output, its source basis and unresolved decisions so the next reviewer knows what remains open.