My week is built around those seams, not around the tools themselves. Here is how a normal one goes, in more detail than I usually share.

The setup is deliberately simple: one primary model for everything text-based, one notebook for context that carries between sessions, and a rule against adding new tools until an old one has failed me three times. That last rule has saved me from at least a dozen subscriptions I would have abandoned within a month.

Monday — research and orientation

I spend the first ninety minutes of Monday on what I call "state of the world." Every open thread from the previous week — questions I didn't finish answering, ideas I noted but didn't develop, decisions I deferred — goes into a single document. The model reads it and does three things: summarizes what's active, flags what's probably stale, and asks me to rank the rest by urgency.

This sounds administrative. It is the most important thing I do all week. It prevents the accumulation of invisible debt — the half-finished ideas and unanswered questions that compound quietly and eventually crowd out the actual work. By Monday afternoon I know exactly what the week needs to accomplish and roughly in what order.

The second part of Monday is research. Here I use the model as a map, not a source. I give it a question — something I genuinely don't know the answer to — and ask it to describe the shape of the answer: who disagrees, what's contested, what's actually settled, and what I should read to understand the contested parts. Then I go read.

I do not use the model's answer as the answer. I use it to tell me where to look.

Tuesday — writing and argument

Writing days start with walking. Twenty minutes outside, voice recorder running, saying out loud whatever I think about the thing I need to write. I am not performing. I am thinking. The recording catches the thinking.

I drop the transcript into the session and ask the model to extract the structure: what argument am I actually making, what's the strongest version of each point, where am I being vague because I haven't finished thinking yet. That last question is the most valuable one. The model is surprisingly good at identifying vagueness. It cannot fix it — vagueness is a knowledge problem, not an editing problem — but it can locate it.

The actual writing is mine. The model is a mirror at the drafting stage: it shows me what I said, not what I meant. The gap between those two things is where the real work happens.

Arguing with a bad outline is much faster than inventing a good one from scratch. The model is wrong in interesting ways. That's the point.

By afternoon I have a first draft. It is usually too long and unevenly weighted — the sections I understand well are dense, the sections I'm unsure about are wordy. The model helps me find the right length. I find the right weight myself.

Wednesday — inbox and correspondence

One sitting, one pass, thirty minutes. The model drafts everything I might want to send: replies, follow-ups, acknowledgments, declines. I read every draft in my own voice before deciding whether to send it.

Probably a third of the drafts get sent close to as-written. A third get substantially rewritten. A third don't get sent at all, because reading the draft helped me realize I didn't need to reply. That last group is the most valuable output of the session.

The rule is simple: the model can do anything, except the last step. The last step is always mine.

Sending is a decision. Publishing is a decision. Deciding is always mine. The model prepares; I choose. That division has not blurred in two years of daily use, and I think it's important that it hasn't.

Thursday — calls and judgment

Thursday is calls. I don't use AI in meetings. I've tried transcription, summary tools, action-item generators — I've tried most of them, and I've kept none. The cost of routing everything through another tool is attention, and attention is exactly what calls require.

What I do instead: spend five minutes before each call writing down what I want to know or decide, and five minutes after writing down what changed. Those two notes are the most useful record I have. They're written in my own words, based on my own judgment, and I can actually find them later.

Friday — shipping and review

Friday is for finishing things. Nothing new starts on Friday. Things that are close get pushed over the line. Things that aren't close get put on next Monday's list.

At the end of Friday I write the week's "delta note" — what actually happened versus what I planned on Monday, and what that tells me about how I should weight next week. The model helps me notice patterns I would otherwise miss. Three Fridays in a row where the same category of work didn't get done is a signal. Without the delta note, I would have missed it.

The lesson

The handoffs matter more than the tools. What you lose in translation between tools is usually the context that made the first tool useful. Keep the stack short. The fewer tools in the loop, the more fully you can use each one.