I had a big build to ship and a Pro plan with a usage window that resets every 5 hours. A long job doesn't fit in one window. It doesn't fit in one context either. Two problems showed up fast: - Token limits. Hit the window and everything stops, mid-task, until the reset. - Continuity. A stopped session loses its thread. A session that runs too long gets heavy and forgets. Either way, I had to re-explain everything. So I stopped trying to keep one session alive. I designed the work so no single session mattered. The idea Put the memory in files, not in the conversation. Then any session, at any time, can die and be replaced without losing anything. The flow - A spec and a plan. The design is written and approved first. The plan cuts the work into small tasks, each self-contained enough for someone who has never seen the project. - A controller. One headless session that dispatches and decides. It doesn't write code, so its context stays small. - Disposable workers. Each task goes to a fresh, unattached session with one job: implement, review, re-check. They return a short summary and are gone. Nothing accumulates. - A ledger. A plain file that records what's done. This is the project's memory. Whoever starts next reads it and continues from the exact point where the last one stopped. - Standing instructions in files. Rules for implementers and reviewers live on disk, so dispatching a task is one short line, not a pasted prompt. - A supervisor. A small script, not an AI. It watches the controller, notices when the limit hits, waits for the reset, relaunches, and notifies me only when it needs a human. It costs zero tokens, because a model watching a model just burns the window you're trying to save. What it looks like in practice I start a stage in the evening. The window runs out at some point. The supervisor waits. After the reset, a new controller starts, reads the ledger, and carries on. In the morning it's merged and waiting for my verification. If one account is exhausted, I log into the second and it continues.

We've been putting a lot of work into Glaido. We want to make it undeniably better than Wispr Flow. Think of it as the voice layer that can actually take action and connect to all of your tools, rather than just transcribing text. Now we're stuck on the name. Four options on the table: And if you haven't checked out Glaido, get a FREE month HERE

Tying this back to my last post on progressive tool discovery, same idea but applied inside a single skill instead of across a bunch of tools. Say you've got one massive skill, like thousands of words of instructions covering a bunch of different scenarios. If you load the whole thing every time the skill gets touched, most of it is dead weight for whatever the actual task is. Instead you can structure it so only a short description is visible at first, and the full body only loads once the skill actually gets triggered. And even inside that, if it points to extra files or reference docs for specific sub cases, those stay unloaded until that exact case comes up. Practically, this just comes down to folder structure. Something like: document-skill/SKILL.md, which has a short front matter description like "handles Word, PDF, and Excel files" that's always visible, and then a body that says "if the task is a PDF, read pdf-instructions.md, if it's a spreadsheet, read xlsx-instructions.md" and so on, with those actual instruction files living next to it in the same folder. None of those extra files get touched unless that specific case comes up. So if the task is "make me a PDF," the model reads SKILL.md, sees it should go look at pdf-instructions.md, and only then pulls that one file in. The spreadsheet and docx instructions never get loaded at all. Is anyone building skills this way already, one big skill split into layers instead of a flat wall of instructions? Would like to know how you're structuring it. Or you are just creating separate skills for everything?

Been playing around with progressive tool discovery in MCP lately and it's kind of changed how I think about setting these things up. If your MCP server has like 30+ tools and you just load all their full schemas every single call, it's a mess. Tokens burned on stuff you're not even using, and honestly the model starts fumbling which tool to pick because there's just too much sitting in front of it. What's worked way better is only showing the model a name and a quick one liner for each tool up front. Then when it actually needs something, it does a search first and only pulls in the full schema for that one tool. Seen two flavors of this: Project based, where the tools are scoped to whatever repo or workspace you're currently in, so you're not even seeing tools that don't apply. Global based, where literally every tool from every connected server sits behind one search step, and you just query it like "send a slack message" and it hands back the right one. Here's roughly how I set the global version up. You build one lightweight "search_tools" function that just returns names and one liners for anything matching the query, nothing more: search_tools("create calendar event") returns something like [{ name: "calendar.create_event", desc: "Create a calendar event" }] Then a second call, get_tool_schema("calendar.create_event"), actually returns the full schema with all the params, and that's the only point it enters context. For the project based version, same idea but instead of searching across everything, you drop a small config file in the repo, something like .mcp-project.json, listing which servers or tools are actually relevant to that project, and the client only exposes those from the start. Anyone else doing this already? Curious if you're going project scoped, global, or mixing both.

Everyone is racing to build more AI agents. 10 agents. 50 agents. 100 agents. But here's the question I can't stop thinking about... Who manages Agent #73? Companies don't become successful because they hire hundreds of talented people. They succeed because they build management systems that keep those people aligned. Maybe AI is heading toward the same challenge. Imagine an AI organization. 🧠 Specialist agents complete tasks. 👥 Team leads coordinate related work. 🎯 Managers allocate priorities. 🏢 Chief of Staff agents resolve cross-team conflicts. 📈 Executive agents monitor organizational goals. Each layer exists for one reason: To reduce coordination complexity. One thought I've been exploring💡 Today's challenge is building smarter agents. Tomorrow's challenge may be building smarter management. As AI ecosystems grow, the biggest failures may no longer come from weak models BUT They may come from unclear ownership. Conflicting priorities, Poor escalation, Context getting trapped inside one team, Or nobody realizing the objective has changed. Those aren't intelligence failures BUT They're management failures. Perhaps the next generation of AI won't compete on how many agents it can run BUT It'll compete on how well those agents are organized. Because every successful company eventually discovers the same lesson: Growth creates management problems AND Not intelligence problems. Maybe the future isn't an AI workforce BUT It's an AI enterprise, complete with management layers, governance, accountability, and coordination. Because adding intelligence is easy AND Scaling alignment is hard. Curious how others think about this💡 If your AI ecosystem grew from 10 agents to 1,000, what would fail first: the models or the management structure coordinating them?