- Seven ways to use AI when you work remotely, all of them aimed at the written half of the job rather than the video call half.
- Remote teams don't lose information. They lose the ability to find it, which looks identical from the outside and costs a great deal more.
- Your team's calendar says when they work. Their message timestamps say when they really do, and the gap between those two is where your pings go to die.
- Threads stall because two people are answering different questions. There's a way to find out which two.
- The build item hands off your weekly update: describe the routine once and let a workflow assemble it from the work you already did.
Here's the thing about using AI when you work remotely: the useful applications have almost nothing to do with meetings. Remote work turns nearly every question into a written one, and written questions land in threads, docs, comment boxes, and DMs that nobody searches. The information exists. Finding it is the job.
That's the shift worth naming. Roughly a quarter of paid full days in the US are now worked from home, a rate that tripled after 2020 and has held flat since 2023 according to WFH Research. Remote stopped being an experiment years ago. But most advice about AI and remote work is still stuck on the video call, recommending transcripts and summaries, when the expensive part happens in the other seven and a half hours. Your colleague in Lisbon posted the answer in March. You asked the same question in August. Nobody did anything wrong, and two hours evaporated anyway.
Every idea below targets that gap. None of them require your team to adopt a new norm, buy a new tool, or agree with you about anything. Each one ends with something you can start today.
1. Dig Up the Decision Before You Ask About It
Renata joined a logistics startup in her third week of a pricing rebuild, remote, from Buenos Aires. The project had eleven months of history: a Slack channel, a folder of half-finished docs, a spreadsheet with four tabs named after people who'd left. She did what anyone does. She asked in the channel why the enterprise tier used a flat fee. Three people answered from memory, contradicting each other, and one of them was wrong.
The archive had the answer the entire time. It was in a thread from the previous November, buried under a discussion about something else, where the founder explained the reasoning in four sentences.
Nobody looked, because looking was harder than asking.
That calculation just flipped. Point an assistant at the exported channel history and the document folder, then ask a question about causes, not keywords: when did this get decided, who decided it, what was the argument against, and what changed afterward. Keyword search fails here because the November thread never used the phrase "enterprise tier." An assistant reading for meaning finds it. This is the same move as turning a pile of scattered sources into an answer you can cite, applied to your own team's past instead of the open web.
Start today: Pick one thing about your project you've never understood. Export the relevant channel (in Slack, a workspace owner can export public channel history; most tools have an equivalent) and drop it in with this ask: "Find every message where this decision was discussed. Give me the timeline, who argued which side, and quote the exact messages so I can go read them." Then read the originals. The quotes are the point.
2. Map the Hours Your Team Really Works, Not the Ones They Say They Do
Stated working hours are fiction on a distributed team. The calendar says 9 to 5 in their local zone. In practice one teammate answers everything before 7am and goes quiet after 2pm, another disappears for a three-hour block midday and works until 8, and a third does the deepest work on Sunday night. Everybody knows this vaguely. Nobody has it written down.
You can measure it instead of guessing. Take your own message history with a person, pull the timestamps, convert them to their local time, and look at the distribution. What comes out is the honest picture: their real first hour, their real last hour, the block where they never respond, and the overlap window you and they genuinely share.
The payoff isn't politeness. It's that you stop burning a full day per exchange. Send a question into someone's dead zone and you get an answer tomorrow. Send the same question ninety minutes earlier and you get it in twenty minutes, plus a follow-up. On a four-round conversation that's the difference between Tuesday and Friday. GitLab's handbook calls this the non-linear workday and treats it as the normal case rather than the exception, which is the right frame.
Start today: Copy the last two weeks of timestamps from a DM thread with one person you work with often. Ask: "Convert these to America/Chicago time, then tell me their earliest and latest active hour, their longest quiet gap, and the two-hour window where we're both most likely online." Write the answer on a sticky note. Do it for the three people you wait on most.
3. Write the Handoff So the Next Time Zone Can Move Without You
Handing work across time zones fails in a predictable way. You post "here's where I got to, let me know if you have questions," go to sleep, and wake up to a message asking a question you could have answered in one line.
Eight hours gone, on both ends, over a sentence.
The fix is to write the answers before the questions arrive. You already know what they'll ask. You just don't think to write it down, because in an office the question would have taken four seconds. So invert the process: describe the state of the work, then ask an assistant to read it as the person picking it up cold and list every question they'd hit in the first hour. Answer those in the handoff. It takes six minutes and buys back a day.
The questions that come back are consistently more basic than you'd expect. Which branch. Which file is current. Whether the client already saw the draft. What "almost done" means in hours. Boring, and every one of them costs a full cycle when it goes unanswered overnight.
Start today: Next time you hand something off, write your normal handoff note, then paste it in with: "You're picking this up in eight hours with no chance to ask me anything. List every question you'd need answered before you could start, ranked by how badly it blocks you." Answer the top five in the note before you post it.
4. Assemble Your Status Update From the Work You Already Did
The weekly update is the tax on being invisible. In an office people see you working. Remote, that visibility has to be manufactured, in writing, every week, and it lands on Friday afternoon when you're least able to reconstruct what happened on Monday. So it takes an hour, it's vague, and it undersells the work.
All of the raw material already exists in a form you can pull. Your calendar knows which meetings happened. Your task board knows what moved from in-progress to done. Your document tool knows which files you edited and when. Your repository knows what you shipped. The update isn't new information, it's a shaped view of records that are already sitting there, which makes it exactly the wrong thing to write by hand every week.
This is the one on the list you shouldn't keep doing yourself. Describe the shape once (which sources, which format, which day it goes out) and hand off the assembly, the way you'd turn any recurring write-up into something that builds itself from the sources. What arrives is a draft with the specifics already filled in. You spend five minutes adding the judgment a machine can't supply: what was hard, what you're worried about, what you need from someone.
Start today: Write down the four places your week leaves a trace and the exact headings your update uses. That list is the whole specification. Hand it off and stop rebuilding it every Friday.
5. Turn "Thoughts?" Into a Decision Request With a Default
Remote work is full of stalled asks, and most of them stalled because of how they were written. "Thoughts?" gives the reader no way to be finished. There's no question with an answer, no deadline, and no consequence to ignoring it, so it sits in a thread getting older while you wonder whether you're being blocked or forgotten.
A decision request is a different object. It states the choice, lists two or three options with the trade-off each one carries, names your recommendation, sets a date, and declares what happens if nobody replies by then. That last part does the heavy lifting. "If I don't hear back by Thursday I'll go with option B" converts silence from an obstacle into an answer, and it's the single most useful sentence in async work.
Where an assistant helps is the reshaping. You're too close to your own message to notice you wrote three paragraphs of context and never asked a question. Paste the draft, get the decision-request version back, then check the options are real. If one is obviously terrible, you've written a rubber stamp.
Start today: Find one message you sent more than three days ago that nobody has replied to. Rewrite it as: the decision, the options with trade-offs, your recommendation, the date, and the default if the thread stays quiet. Repost it as a new message rather than a reply, so it arrives at the top of someone's day instead of the bottom of yesterday's.
6. Find the Real Disagreement in a Thread That's Gone Four Rounds
Kwame manages a small remote design team and watched a thread run twenty-two messages over three days about whether to rebuild the onboarding flow. Two senior people, both reasonable, both getting shorter with each reply. On a whiteboard it would have taken eleven minutes.
He pasted the whole thread in and asked what the two of them were disagreeing about. The answer took one line: one was arguing about whether the rebuild was worth doing this quarter, the other about whether the current flow was broken at all. Neither had noticed. They'd been trading evidence past each other for three days because they were answering different questions, which is what asynchronous disagreement does when nobody can see a face.
Twenty-two messages. One question nobody had asked.
Ask for the structure, not a summary. Summaries flatten a thread into what was said. What you need is what's being contested: the claim each side is defending, the point where they stopped sharing an assumption, and the one piece of information that would settle it. Then post that, plainly, as its own message. Naming the disagreement out loud almost always ends it, and it's the kind of read that gets much easier when your team's message history is something a workflow can reach into.
Start today: Take the longest unresolved thread you're in. Ask: "What are these two people disagreeing about? Give me each person's actual claim, the assumption where they diverge, and what evidence would resolve it." Post the answer in the thread as a question, not a verdict.
7. Answer It Once Where People Will Find It
Remote work makes you a search engine for your own team. Same six questions, different people, spread across DMs where each answer disappears the moment it's read. Microsoft's Work Trend Index found workers being interrupted every two minutes during core hours, roughly 275 times a day across meetings, email, and chat. A meaningful slice of that traffic is questions with a known answer that lives in someone's head.
Mine the incoming, not the outgoing. Cluster the questions people asked you last month by what's being asked rather than how it's phrased. "How do I get access to the staging site," "who approves staging access," and "my staging login isn't working" are one question wearing three hats. Rank by frequency, take the top five, write each answer once somewhere linkable.
Then send the link instead of the answer. Not to be short with people, but because the fourth person who needs it will find it without asking, which is the entire point of writing things down where the team can search them. Two honest caveats: this only works if the page stays current, and some questions are really a request for a two-minute conversation. Answer those with the conversation.
Start today: Search your DMs for the last thirty days of messages containing a question mark. Paste them in with: "Group these into repeated questions, ignoring wording. Rank by frequency and show me the top five." Write those five answers into one document today. Send the link the next time one comes in.
Pick One
Seven is too many to start with, and the one that made you nod is the one to do. If you're new to a team, that's the decision archaeology in idea one, because it pays back in your first week. If you've been somewhere three years and Friday afternoons keep vanishing, it's the status update. If a thread is currently making you angry, go straight to idea six and find out what the argument is really about.
Something worth saying plainly: none of this replaces a colleague. It replaces the waiting, the retyping, and the third time you explain staging access. Sunday's roundup reports what changed in AI this week, Wednesday's Loop builds one workflow start to finish, and this column hands you the ideas in between. When one of them turns out to be a thing you'd rather never do again, the workflow directory is where you go to hand it off.
The recurring part of remote work should run without you
Tell BYOBot which weekly write-up eats your Friday and where the raw material lives. You get back an agent that assembles it while you're doing the work worth being paid for.
Frequently Asked Questions
- They work better, because a partly remote team is where written context breaks down fastest. When half the group shares a room, decisions get made in conversation and never get written anywhere. Everything here is about capturing and finding the written record, so the person who wasn't in the room can move without waiting. Hybrid teams get the most out of the decision history idea and the handoff note.
- That depends entirely on which tool and which account. Company-managed AI inside your existing suite generally keeps data under the same agreement your files already sit under. A personal free account usually doesn't, and may use your input to improve the model. Check your employer's policy first, use the company-provisioned tool when one exists, and strip names, salaries, and customer details when you're unsure. If you're building something that touches company data on a schedule, the same question applies to any workflow you set up, so answer it once and write down the answer.
- Every idea here works on your side of the wire without anyone else changing a habit. You can reconstruct a decision history, map real working hours, write a decision request, and publish a page of answers whether or not your team ever adopts async norms. Good async behavior spreads by being copied, not announced. Ship one decision request with a default and watch how fast it gets answered.
- The status update. It's the same job with the same inputs every week, which is exactly the shape of work that becomes an agent: pull from the calendar, the task board, and the documents you touched, then assemble the update in your format. Describe the routine once and it runs on schedule instead of costing you an hour every Friday. The same pattern covers any report you rebuild on a fixed cadence.
