Answer Engines Are the Wrong Shape for News

Clients, thick and thin

AI answer engines are a poor paradigm for news.

This is not because AI has nothing useful to offer journalism, or because every generated answer is wrong, or because news organizations can only survive if the web continues to work exactly as it did in 2012. The problem is more specific than that: The answer box is an interface that collapses a complex, rich source environment into one fluent object. That can be fine for a casual question. It is much worse when the stuff of professional journalism—provenance, attribution, uncertainty, corrections, institutional trust, source diversity—comes into play.

From the reader’s side, fluency makes weak sourcing feel resolved. The product gives you a finished answer first, then makes the sources feel supplemental. No wonder, then, that people rarely click on links cited by AI.

From the publisher’s side, this creates grim economics. If a user does not click through, the publisher has supplied the raw material without receiving much, if any, reader relationship in return. Licensing deals may soften this for some large institutions, but they also risk concentrating the market around newsrooms big enough to bargain.

This dynamic would pose a challenge even if AI answers were perfect, but they’re not. In many cases, LLMs misrepresent news content. They concentrate citations to a small number of established newsrooms. They act as flawed gatekeepers, deciding which institutions get visibility and how their coverage gets framed.

So answer engines are imperfect, but they’re also just one instance of a broader product choice: the prompt text box as the default interface for serious work. The prompt box is a reasonable starting point. It is flexible, familiar, and good for low-stakes exploration. But in professional domains—law, research, journalism, medicine, or policy—the work is rarely just “ask a question, receive a paragraph.” It involves a richer workflow of managing context, tracking uncertainty, challenging claims, and keeping evidence close enough that it can be checked. We’re still figuring out how to build for those use cases, and the shape of those future products matters a lot.

One way to understand the stakes is through the distinction between thin and thick clients. Reductively, this is a debate about where capability lives. A thin client sends work somewhere else: The endpoint is mostly input, output, and connectivity. A thick client keeps more capability local to the user’s machine: compute, interface logic, files, state, customization, and sometimes the whole working environment.

Ben Thompson recently argued in Stratechery that AI is pushing computing back toward thin clients. The default AI interface is a text field that sends your request to a data center. Agents intensify the pattern by hiding the intermediate workflow between request and result. The strongest models, largest context windows, and fastest inference live in centralized infrastructure.

But we don’t have to bundle every part of the AI workflow into a server. A remote model can be a useful helper inside a thick client. A local model can still be part of a thin product if all the sources, annotations, rankings, prompts, outputs, and history are trapped in a provider-owned cloud. The important question is where the user’s relationship to information lives.

That question has a long history. In 1945, Vannevar Bush’s memex imagined a personal filesystem and library where a user could store materials, then build associative trails through them. Alan Kay and Adele Goldberg’s Dynabook vision sharpened this into a theory of a computer as a user-owned metamedium, responsive to their decisions about how information should be represented and manipulated. More recently, Ink & Switch’s work on malleable software offers a vision of how users can leverage shared data and software with adaptations to their desired workflows. For news, that suggests an interface where a reader, journalist, or researcher can reshape the view: a timeline here, a source comparison there, a saved reading trail, a custom filter that is inspectable rather than hidden in a ranking model.

This kind of approach does not apply to every news habit. If I want a box score or the weather, a thin answer may be enough. Every casual interaction doesn’t need to be an archival research project.

Thick clients also do not map cleanly onto the current platformized news system. Platformized news is transient; a thick client is durable. Platformized news is generic by default, then personalized through opaque inference. A thick client is personal because the user’s state accumulates over time. Platformized news is rigid; a thick client should be malleable.

The useful news precedent, then, is not the platform feed. It is an earlier vision of networked journalism. In 2001, Jo Bardoel and Mark Deuze described online journalism through interactivity, customization, hypertextuality, and multimediality, with the journalist becoming an orienting node in a networked information environment. Journalism would be connected and adaptive, making news more inspectable, participatory, and useful for orientation.

In the late 2000s, newsrooms built out infrastructure to support this vision. NPR, The New York Times, and The Guardian opened APIs with the hope that trusted news content and metadata would support a broader ecosystem of useful applications. The public developer renaissance mostly did not arrive, but the internal value was real: APIs let news organizations publish across new devices, experiment with formats, syndicate content, and separate reporting from any single output surface. A similar approach could help build the computable substrate that AI news tools need.

So, what would a thick news client look like?

At minimum, it would treat sources as durable objects rather than disposable context for an answer. Articles, documents, transcripts, datasets, press releases, social posts, podcasts, newsletters, and user annotations would live in a workspace the user controls. The model would operate over that workspace, but it would not be the workspace.

A user following a developing story could pull in raw material from several outlets, official documents, and primary-source artifacts. The client could maintain a timeline, extract claims, identify named entities, show which claims are supported or contradicted by which sources, and preserve the path from a generated synthesis back to the underlying text. If the model rewrites a dense policy story as a plain-language brief, the transformation would carry its source trail with it. If it generates a map, timeline, or argument table, those objects would remain editable and inspectable rather than disappearing into chat history.

AI is well suited to this kind of interface precisely because so much of the work is tedious. It can retrieve, cluster, summarize, translate, rewrite, compare, tag, and maintain derived artifacts. Open-weight models and local runtimes make some of that work plausible on user-controlled machines. Browser-managed AI suggests another version where local or hybrid inference becomes a platform capability. But the model is only one layer. The more important design commitment is that the source material, metadata, and surrounding notes remain portable and inspectable.

One concrete example of what this might look like is Andrej Karpathy’s “LLM Wiki” proposal. Karpathy describes a persistent Markdown wiki maintained by an LLM over time, wherein the model writes summaries and syntheses, then updates them as new sources arrive. That is not a news product, but it is very close to the shape of one. Imagine a local news workspace that treats a beat, location, or policy as a living wiki. New articles and documents update source summaries. Claims become linked to evidence. Reader notes become part of the working context. The LLM can still generate answers. But rather than temporary chat responses, they become views over a maintained source environment.

There are real constraints here. Most users will not maintain a personal archive for every story. Local models will not always be good enough. Publisher rights, paywalls, corrections, takedowns, and attribution remain thorny questions. And private personalization can become its own information-limiting environment if it simply lets people tune out everything uncomfortable.

But those are product and governance problems, and they’re more tractable if we refuse to accept answer engines as the final form. A prompt box is optimized around the appearance of completion; we can build richer, more expressive clients.

The broader point is that the way we build with AI is still open. Chatbots, answer engines, and agent harnesses are a first draft of a first draft. They reveal powerful capabilities, but they also inherit the incentives of the companies that host the models, own the interfaces, and aggregate demand. For news, that means more source material flowing into a centralized intermediary, more reader attention captured at the answer layer, and more pressure on publishers to accept visibility without a lasting audience relationship.

The alternative is not nostalgia for RSS or a blanket rejection of AI. It is a thicker client for public information: local-first where it matters, cloud-assisted where useful, source-grounded by default, malleable at the interface, and honest about provenance.