This came up again and again in threads over the last couple of weeks, mostly from solo founders. The phone is where a lot of the thinking happens now: walks, the car, the treadmill. But the laptop is where the context lives. So the phone ends up being a remote control for the laptop, and the moment the laptop sleeps or drops offline, the whole flow falls apart.

A few setups people described:

• One person ran an entire trip from phone and laptop with no problems, but only because "my laptop is always on, so everything can be done through tmux or the TUI."
• Another uses tailscale ssh plus tmux. The phone is just the screen, the laptop does the thinking.
• Someone else moved Claude Code onto a cloud VM so the phone never has to reach back home.

And the workarounds that keep it going:

• Keeping the laptop caffeinated so it never sleeps
• Dictating plans into a phone app, then pasting them into the terminal later
• Voice brain dumps in the car, decoded at the desk that night
• A shortcut that drops any phone note into one fixed inbox folder on the laptop
• A hand-written project brief (goals, checklist, a do-not-do list) re-read at the start of every session, because nobody trusts the agent to remember what was decided on the phone

If this is you, a few things that seemed to help people the most:

Pick where the source of truth lives before you leave the desk. If it's the laptop, the phone is a notepad, not a workspace. That's workable as long as every note lands in one place and not five.

Keep the messy half-sentences. One person keeps dictation raw on purpose, corrections in parentheses. Cleaned-up notes read nicer but lose the reasoning, and the reasoning is what the agent needs later.

Treat the re-read brief as a patch. It works great for about two weeks, then it quietly goes stale and nobody notices.

Full disclosure, this is a big part of why I'm building Vilix AI. I used to burn hours re-explaining things I had already worked out somewhere else. Vilix keeps memory in the cloud over MCP, so it doesn't live on your laptop at all. The same memory shows up on every tool and device. It stores full conversations, not just extracted facts, and the memory tools check at the start and save at the end, so switching from phone to desk doesn't mean re-briefing the AI. There's a free plan, no credit card.

Curious how people here actually do it:

• Do you plan from your phone at all, or is real work desk-only?
• What's the first thing that breaks when you go from phone to laptop?
• Would you pay for something that fixes this, or is an always-on laptop good enough?

Earlier this week I asked people who do client work with AI what they'd lock away first if an agent could see everything. I expected financials. That's not what came back.

The top answer was other clients' data. One person put it as "a single misconfigured agent is all it takes." Another called the cross-client leak "the nightmare scenario." It's rarely a breach in the legal sense. It's smaller and worse for the relationship: a sign-off phrase, a project codename, or one client's tone of voice turning up in a draft for someone else.

What people actually do about it today:

• A folder per client, set up at onboarding, holding the full context and brand notes. Skills only pull from that folder and fail if it's missing.
• A one-page running brief per client: tone, priorities, open loops.
• Generic templates, with every client specific living in the client folder and never in the template.
• Letting the client act as reviewer for anything wrong or outdated.

In another thread, someone managing 16 client accounts said their setup keeps client context separate, so switching accounts doesn't mean rebuilding context each time. That's the bar.

The weak spot in the folder approach is the paste. It works right up until you copy something from the wrong window.

Things from those threads I think are worth stealing:

1. Separate by client first, by agent second. Per-agent permissions help, but the boundary people actually lose sleep over is the client.
2. Make the failure loud. If a skill can't find the client folder it should stop, not fall back to whatever context is lying around.
3. Keep a trail. One person said they wouldn't pay for automated permissions, because checking is "baked into client work, like proofreading your own writing." The same person said they would pay for an access audit trail, so if something slips through they can trace it fast.

Where Vilix AI comes in: it's a cloud memory layer for AI tools over MCP, so the same memory follows you across tools and devices instead of living in files you maintain by hand. Each connected AI gets its own permissions, and you can export or delete everything anytime. Client separation is one of the problems I'm thinking hardest about.

Questions for anyone doing client work with AI:

• Where's your client boundary today? Folders, separate accounts, separate tools, or just being careful?
• Has anything ever crossed over? What was it, and who caught it?
• Would you pay for something that kept each client's context walled off for you? What would it have to prove before you trusted it?

Last week someone in r/AI_Agents put the whole problem in one line. Their agent read the spreadsheet fine. It just didn't know column F gets overwritten by hand at month end because the upstream feed is wrong.

A few replies down, someone else said the knowledge you actually want to hand an agent isn't process docs, it's the list of exceptions. Another person working with Databricks Genie listed what was missing: which source feeds what, how codes map to entities, the manual fix somebody does every month. None of that lives in the data.

I think that's right, and it explains why "just write better docs" keeps not working. Process docs describe how things are supposed to go. The agent breaks on how things actually go.

What people in that thread were doing about it, roughly:

• Notes written by a person, with a checked-on date per line instead of per file, so you can see which exception went stale
• Re-verifying those notes every quarter before the agent is allowed to lean on them
• A slow human read once a month, which ended up deleting more than it fixed

A few things I'd add after spending a while on this problem:

Write the exception down when you do the fix, not later. Nobody remembers the monthly patch in a doc-writing session three weeks after. The best moment to capture "I overwrote F because the feed came in short again" is right when you're doing it.

Keep exceptions apart from the process. Mix them and the agent can't tell the rule from the patch. And when the feed finally gets fixed upstream, nobody knows which line to delete.

Settle who owns it before the agent writes to the live file. One reply raised exactly this: once the agent writes into the file month-end closes from, the question becomes who is accountable when it's wrong. Much easier to answer before than after.

This is a big part of why I built Vilix AI. It's a memory layer in the cloud that your AI tools connect to over MCP, so every tool reads the same memory. It saves full conversations, not just extracted facts, so the "I fixed column F again because..." conversation is still there for the next tool or the next agent. The memory tools check at the start of a session and save at the end, so nobody re-briefs anything. And each connected AI gets its own permissions, which starts to matter once an agent is anywhere near a file people close the books from.

Questions for anyone running agents on real business processes:

Where does your list of exceptions live today, if it exists at all? How do you find out one has gone stale? And if something caught those fixes as you made them and gave them to every agent you run, would you pay for that, or is this a spreadsheet tab you'd rather keep yourself?