Personal Agents Make Experience More Important Than Content Acquisition

Content Has to Come From Somewhere

Content apps need content. Traditionally, they get it in one of two ways: attract creators to produce it inside the app, or build integrations to bring it in from somewhere else.

Both are hard, in different ways. Building a creator ecosystem means convincing people to make content before there's an audience to consume it. Building integrations means authentication, APIs, rate limits, normalisation, and ongoing maintenance as the systems you're integrating with change.

Either way, a lot has to happen before you get to the part most users actually care about: content curation and the product experience around it.

Personal agents create another possibility. If an agent can gather and structure existing content on the user's behalf, an app doesn't necessarily need to attract its own creators or own the integrations used to reach it. That's the pattern I've been exploring with ScrolLess: the agent gathers the content, while the app focuses on what to do with it.

The Problem Apps Carry

Look at the codebase of a news reader, social aggregator, or personal dashboard and you'll find a substantial amount that has little to do with the experience the app is trying to deliver. OAuth flows, API rate limits, token refresh logic, schema mappings that need updating when platforms change their response formats. The plumbing required to reach the data becomes a substantial part of building the product.

This wasn't always the shape of things. In the early web, apps often owned their data because they were the source of it — you were putting information into them, not pulling it out of somewhere else. As more of our data moved behind platforms and their APIs, applications increasingly became integration layers too: authenticating, synchronising, and translating between external systems before they could do anything useful with the result.

There's a less-visible cost for users. When an app owns your integrations, it will often hold the resulting data too. Your history, preferences, saved items, and other state become tied to that application. Switching to another app can mean starting again. That arrangement is normal enough that it barely registers as an architectural choice. But it is one. Research into data sovereignty in the age of big tech has been examining the consequences of this kind of platform control for years.

The Inversion I'm Exploring

What happens if a personal agent takes over the integration work? The agent authenticates with platforms, gathers content, and structures it into a format the application understands. The application receives the result and focuses on what to do with it.

In the model I'm exploring, the resulting data also lives on the user's device rather than in the application's backend. That separates three responsibilities which are usually bundled together: the agent gathers, the device owns, and the app presents.

For developers, integration complexity moves out of the application. Adding another source doesn't necessarily require adding another API client to the app. For users, the relationship with their data changes. The agent gathers on their behalf, their device holds the result, and using an application doesn't inherently require making that application's backend the custodian of their content.

What Changes

The practical difference is mostly about where responsibility lives:

Apps Can Compete on the Experience

If the integration work can move outside the application, the relationship between the number of integrations an app supports and the complexity of the app itself starts to come apart.

The pattern is strongest where external integrations are necessary but aren't the product's main differentiation. A feed reader can focus on making a feed good to use. A research tool can focus on helping someone understand what they've gathered. A dashboard can focus on presenting information well rather than knowing how every underlying system works.

Instead of every competitor solving the same access problem before it can build the experience it actually cares about, that access problem can move into the agent layer. If the user's data isn't trapped inside the application providing the interface, switching applications becomes easier too. The data remains; the tool operating on it changes.

There's a user benefit beyond choosing a different interface. Platforms don't just provide content; they also decide how it's ranked, how you move through it, and how difficult it is to stop. If an agent gathers content independently, those decisions don't have to stay with the platform. I could combine the sources I'm interested in, set my own rules for what matters, ask for summaries, or limit how much time I spend reading.

None of that automatically makes the experience better. An agent that gathers everything might just give me a bigger feed to scroll through. The opportunity is to build an experience around what I actually want from the content, rather than inheriting the incentives and interaction patterns of the places it came from.

An Early Exploration: ScrolLess

ScrolLess is my experiment in this direction: a unified social and news feed built around the separation between gathering content and deciding how to consume it. An external agent handles the platforms I follow and structures the results into a common format. The application stores the resulting feed locally and renders it without having direct integrations with those platforms itself.

The project is still in active development. I'm using it to test whether independent access to content can support a more deliberate experience: one where I can curate what matters and decide how much attention to give it. Gathering content is only half the problem.

There are significant obstacles between that idea and ordinary consumer software. Platforms may not want agents accessing them this way. Giving an agent broad access introduces its own trust problem. Local data ownership only means much if the architecture actually enforces it. And today's personal-agent tooling still asks considerably more of users than a normal application does.

Those problems don't make the pattern uninteresting. They determine whether it can actually work. That's where I'll go next.