Best of your X follows: long agents, cognitive debt, and founder questions

The strongest thread in today's feed was not another model-access update. It was the practical problem that follows once long-running agents are capable enough to be useful: people need ways to supervise them, understand their work, and decide where human judgment still belongs.

Ethan Mollick wrote that Fable in Claude Code can do impressive work, including for non-coders, but the interface is not designed for managing autonomous tasks that run for 5+ hours 1. The practical gap is observability: seeing what the agent is doing, interrupting it, and steering it before the final output arrives. For teams testing long agent runs, the next product layer looks more like a mission-control console than a chat box.

Mollick also said that posts about Fable workflows show how little people know about organizing work around long-running agents; in his view, there has not been enough experience or testing to support firm conclusions 2. That matters because teams are already turning isolated experiments into process advice. The useful takeaway is restraint: treat today's agent workflow tips as hypotheses until they survive repeated work, failure cases, and handoffs.

Mollick's more concrete advice was to ask Fable to report in plain language during long tasks; otherwise, he said, it can develop a strange internal cadence that leaks into menus and dialogue 3. This is a small operational rule with a large implication: agent output style is not just cosmetic when the agent is creating user-facing artifacts. If a model is left to invent its own narration over hours of work, teams may need review gates for tone and interface copy, not just code correctness.

Simon Willison highlighted Geoffrey Litt's AIE framing: developers need to "understand to participate" when coding agents build large changes, or their understanding drifts away from how the code actually works 4. Willison quotes Litt's point that a developer needs enough concepts in mind to move the project forward, not just approve generated diffs. The risk is cognitive debt: shipping code faster while losing the ability to reason about the system you now own.

Paul Graham pointed to a class of questions that are important but rarely considered, and suggested that every company could usefully decide what its own version of those questions should be 5. For AI teams, that pairs well with today's agent-control theme: the hard question is often not "can the model do it?" but "which decisions should the organization force itself to revisit?" A simple exercise is to list the questions whose answers would change priorities, hiring, or product architecture, then assign owners before the next tool rollout.

Graham also pushed back on the idea that a founder's top job is to absorb the most painful work; he argued that the top job is solving the important problems, and pain and importance are not perfectly correlated 6. That is a useful filter for agent adoption: do not automate the loudest pain point just because it is visible. Start with the work whose improvement would actually move the company, then decide whether an agent, a workflow change, or a human decision fixes it.

I left out pure retweets, context-light prompts, and posts that did not expose enough substance to summarize fairly. That kept the digest shorter, but it avoided repeating yesterday's Fable access story under a new headline.