The AI That Can't Work Because Someone's Laptop Went to Sleep
We've reached an interesting moment in computing history where your carefully orchestrated AI workflow can be derailed not by algorithmic failure or computational limits, but because Dave's laptop lid closed during his commute home. The grand promise of connected AI systems—where multiple models collaborate, share context, and build on each other's work—runs headlong into a mundane reality: these systems still need to run somewhere, and that somewhere is often a device with strong opinions about power management.
The past few years have brought us from isolated AI tools to increasingly sophisticated orchestration frameworks. You can now chain together language models, image generators, data processors and specialised agents into workflows that genuinely feel like having a small team working on your behalf. Except your team keeps disappearing mid-sentence because the device hosting them decided it was time for a nap.
When Always-On Meets Actually-Off
The technical capabilities have genuinely improved. Modern AI orchestration platforms can manage complex sequences: a model reads your email, another extracts action items, a third schedules follow-ups, and a fourth drafts responses. In theory, this happens seamlessly in the background whilst you get on with your day. In practice, it happens until your laptop's battery saver mode kicks in, or your home broadband hiccups, or Windows decides that right now—during a multi-hour processing task—is the perfect moment to install updates.
This isn't a failure of the AI systems themselves. The models work exactly as advertised when they're actually running. The problem is architectural: we've built increasingly sophisticated software on top of infrastructure that was never designed for this kind of persistent, long-running operation. Your laptop is optimised for being a laptop—portable, power-conscious, occasionally offline. That's exactly what you want most of the time. It's exactly what you don't want when you're trying to run an automated system that needs to stay operational for hours or days.
The Cloud Isn't Always the Answer
The obvious solution is to move everything to the cloud, where servers run continuously and don't have inconvenient ideas about conserving battery. And for many workflows, that's exactly the right approach. But cloud hosting introduces its own complications: costs that scale with usage, data privacy considerations, latency for tasks that need quick local access, and the small matter of needing a constant internet connection.
For personal AI workflows, the economics often don't add up. Running a few API calls is one thing; maintaining a persistent cloud instance that orchestrates your daily tasks is another. You can easily spend more on hosting than the time savings are worth, particularly for tasks that don't justify the expense of always-on infrastructure.
There's also the question of what happens when your orchestrated workflow needs access to local files, browser sessions, or applications running on your machine. Suddenly you're back to needing a local component anyway, which brings you full circle to the original problem: that component is running on a device with its own ideas about uptime.
The Reliability Paradox
We've created AI systems that are remarkably capable but fundamentally unreliable through no fault of their own. A language model can produce brilliant analysis, but that's cold comfort when the workflow that called it crashed halfway through because someone closed their laptop. The more sophisticated these orchestrated systems become, the more painfully obvious the infrastructure mismatch becomes.
This matters more than it might initially seem. When you're using a simple AI tool—send a prompt, get a response—the reliability requirements are minimal. The interaction is synchronous and short-lived. But modern AI workflows are increasingly asynchronous and long-running. They need to monitor for triggers, maintain context across multiple steps, retry failed operations, and coordinate between different services. These are patterns that assume reliable infrastructure, not a laptop that might go to sleep at any moment.
The developer experience tells the story clearly. Build a multi-step AI workflow, test it whilst you're actively using your computer, and everything works beautifully. Close the lid and go for lunch, and you return to find it stopped thirty seconds after you left. Not because the AI failed, but because your operating system did exactly what it was supposed to do: conserve power when the device appeared idle.
Workarounds and Their Limitations
People have developed various strategies to keep systems running. Disable sleep mode entirely, which works until you forget your laptop is on and drain the battery completely. Use keep-alive utilities that simulate activity, which feels like a workaround to trick your own computer. Set up a dedicated machine that never sleeps, which solves the problem but requires spare hardware and isn't exactly portable.
Some platforms have built in persistence mechanisms—saving state, resuming workflows, retrying failed steps. These help, but they're essentially band-aids over the fundamental issue. When a workflow breaks mid-process, you lose context, waste compute time on duplicate work, and introduce complexity trying to figure out where to resume.
Mobile devices present the problem in even sharper relief. Your phone is the device most likely to be with you constantly, making it appealing for persistent workflows. It's also the device most aggressively managed for battery life, with operating systems that will happily terminate background processes without consultation. Building reliable AI orchestration on mobile requires fighting the OS at every step.
What Actually Works
The solutions that work tend to acknowledge the infrastructure reality rather than fighting it. Short-running workflows that complete in minutes rather than hours. Cloud services for tasks that genuinely need persistence. Local processing for quick, interactive work. Hybrid approaches that use cloud orchestration but local execution where needed.
Edge computing—running persistent services on local network devices like a Raspberry Pi or home server—occupies an interesting middle ground. You get the benefits of always-on infrastructure without cloud costs or data leaving your network. It's not quite as simple as running everything on your laptop, but it's considerably simpler than managing cloud infrastructure.
The emerging pattern seems to be treating AI orchestration as infrastructure rather than application code. Not something that runs opportunistically on whatever device happens to be handy, but something with dedicated resources that match its operational requirements. That might be cloud, edge, or a dedicated local machine, but it's rarely your primary laptop.
The Wider Picture
This infrastructure mismatch highlights a broader transition in how we think about AI systems. The first wave of AI tools were essentially fancy calculators: give them input, get output, done. The current wave increasingly resembles services: persistent, context-aware, operating over time. But we're often still trying to run them with the first-wave mindset, treating them as applications rather than infrastructure.
As these systems become more capable and more integrated into daily workflows, the question of where they run and how they maintain reliability becomes less of a technical detail and more of a fundamental design consideration. The AI that can produce brilliant results is genuinely impressive. The infrastructure that keeps it running long enough to finish the job might be the more important piece.
More From the World of Technology
If you found this exploration of AI infrastructure challenges interesting, we've written extensively about technology trends and where they actually lead rather than where the marketing suggests. There's plenty more to read through if you're inclined.
What Cursor is actually doing when it rewrites your code (and why it feels uncomfortably accurate)
Upgrading the Engine: The Fast New Language Speeding Up Web Development
We don't write about these topics purely for entertainment value—keeping current with how technology actually works in practice is rather central to what we do. We build things: websites, software, systems that need to function reliably in the real world rather than just in demonstrations. Understanding where the gaps are between promise and practice tends to produce better results.
If you're considering having something built—whether that's a website that needs to handle modern demands, software that solves a specific problem, or systems that integrate new capabilities without falling over—we'd be happy to discuss it. The conversation is free, the advice is honest, and we're generally quite good at turning ideas into things that actually work. You can find out about prices (and all about us) below.
Why does my AI workflow stop working when I close my laptop?
Your laptop is designed to conserve power when idle, so it goes to sleep when you close the lid—which stops any running processes, including AI workflows. The AI isn't failing; your operating system is just doing what it's supposed to do to save battery.
Should I just run my AI workflows in the cloud instead of on my laptop?
It depends on your specific needs and budget. Cloud hosting solves the reliability problem but introduces ongoing costs, data privacy concerns, and can be problematic if your workflow needs access to local files or applications on your machine.
How can I keep my AI tasks running when my computer goes to sleep?
The most reliable solutions involve dedicated infrastructure rather than fighting your laptop's power settings. This could mean cloud services for tasks needing persistence, edge computing on a device like a Raspberry Pi, or keeping workflows short enough to complete in minutes rather than hours.