The Problems Don't Disappear
The first article explored what happens when personal agents gather content independently of the apps we use to consume it. It could give us more control over our feeds, our data, and the experience built around them.
But moving content acquisition out of an app doesn't make the hard problems disappear. It moves them. An agent still needs access to the source, still needs to gather the right information reliably, and still needs to be trusted with what it can see. Even if all of that works, somebody has to make the result worth using.
Access Is Still Access
An agent needs some way to reach the content. Sometimes that's an API. Sometimes it's browser automation or scraping an interface built for a person. Those approaches have very different reliability and permission constraints.
Platforms can limit what their APIs expose, restrict unofficial clients, and change the interfaces that automation depends on. The legal position on scraping also varies by jurisdiction and use case; there isn't a universal answer. Giving an agent the task doesn't resolve those questions.
There's a product tension here too. A platform's interface is often where it delivers recommendations, advertising, moderation, and the rest of its experience. Taking content elsewhere changes that relationship, so we shouldn't assume platforms will make it easy. Open banking offers a useful contrast: in regulated settings, users can authorise access through supported interfaces. Content platforms generally don't offer an equivalent.
Two Different Trust Problems
The first is trusting the agent. An agent that can gather content across services might have access to social accounts, email, subscriptions, financial information, or private documents. Where does it run? What does it retain? Who can read its logs? What happens to credentials if the service changes hands or shuts down?
The second is trusting what receives the results. Once data from several sources is combined, it can reveal more about someone than any individual source does. Who stores that history? Can the developer read it? Can the user take it somewhere else, or delete it?
I don't think a privacy policy is enough to answer those questions. If the argument is that users should own their data, the architecture should make that credible. In ScrolLess, that means trying to keep the resulting data on the device and the relay unable to read what passes through it. The next article covers that design.
It Has to Work Repeatedly
A successful demo isn't the same as something you can rely on every day. Websites change. Automated sessions fail. Content gets duplicated, misclassified, or presented as fresh when it isn't. A feed that quietly misses things can be harder to trust than one that fails outright.
That's why I want the repeatable parts to be deterministic. The agent can decide what to gather and how to prioritise it, but source-specific operations and the format passed to the app should be structured. Protocols such as MCP can help expose reusable tools, though a protocol alone doesn't make the underlying integration reliable.
There's also a mismatch between scheduled collection and the expectation of a live feed. Periodic updates might be enough for what I actually want from a reading app, but the experience needs to make that trade-off understandable rather than looking like a broken version of a social platform.
Access Doesn't Make a Good Experience
Most people don't want to configure an agent, manage credentials, or debug a failed sync. They want an app that works. Setup and ongoing maintenance are part of the product problem, not something we can hand-wave away.
More importantly, gathering everything I'm interested in doesn't mean I'll want to consume it all. I could end up with a larger, noisier feed than the ones I'm trying to escape. Independent access creates the option to curate across sources, change ranking, limit screen time, or replace scrolling with a digest. Somebody still has to design those choices well.
That's the gap I'm exploring with ScrolLess. The agent gathers content; the application should help me decide what deserves my attention and how much of it to give.
What Comes Next
I still think separating content access from the application opens up more flexible, personal software. But access, trust, reliability, and experience don't become optional because an agent is involved.
The next article looks at the ScrolLess architecture: how the agent, relay, and device fit together, and what it takes to make data ownership more than a promise. That solves only part of the experience problem, but it's a foundation I want to be able to trust.