Share your best AI workflow. We could show it to 2M+ people.

I read the news every day, but it had become increasingly depressing and was making me miserable. What bothered me most was that it also felt inaccurate: although bad things are happening, there have been many positive developments over the past five years that rarely receive sustained coverage. Major news sites might publish an article or two about them, but those stories are quickly buried under negativity. I wanted a way to get only positive news stories in my feed each day. Keyword filters did not work: “record” and “breakthrough” also appear in stories about record wildfire seasons, while “war” can appear in “war ends.” Off-the-shelf sentiment analysis was not useful either. A happy press release about layoffs can be classified as positive, while a dry factual story about a disease being eliminated may be classified as neutral. So I trained a basic artificial version of my personality using a series of prompts about what I consider positive in the world. I connected it to Mistral through OpenRouter and gave it access to public RSS feeds from news sites I already trusted. This eventually became Rally News, which I published on Google Play. iOS has been more difficult. The app surfaces positive stories from more than 20 news sites in an endless scroll, giving me an alternative to my uncomfortable TikTok addiction. Because I made it public, I decided not to host article text: publishers keep their traffic and revenue, while the tool remains ethical. The system runs on a GitHub Actions cron job that pushes stories to a PHP and MySQL database. I built the app without coding experience for about $25 per month. Step-by-step: 1. I collected RSS feeds from established publishers I already trusted and stored the list as configuration. I started with about 10 feeds instead of a few hundred so I could realistically read the output. 2. I set up a scheduled GitHub Actions cron job to run a Python script that pulls new items from every feed. 3. I deduplicated incoming articles against the database using the URL and a normalized title. Syndicated stories frequently reappear under slightly different URLs, and I did not want to pay to evaluate the same article twice. 4. I wrote the filter prompt as a long persona document rather than a one-line instruction. It explains what I consider progress, what I consider a puff piece, and which cases should fail—for example, celebrity news is not good news, a company announcing an intention is not the same as taking action, and a local feel-good story without wider significance does not qualify. 5. I sent each new article to an LLM through OpenRouter and required JSON output containing a pass-or-fail decision and a short justification. 6. For the first few weeks, I read the justifications every day. Whenever I disagreed with the model, I added a new rule to the persona document. That review loop required nearly all of the actual work. 7. I wrote passing articles to MySQL with only the headline, source, link, and metadata, leaving the article body with the publisher. 8. I pointed the website and mobile app to the same database. 9. I added a second GitHub Actions job that assembles a daily newsletter from the same data through Brevo, allowing one evaluation pass to feed three surfaces.

After about 18 months of building software with AI, I realized that reliability wasn't primarily a model problem. Bigger context windows and more clever prompts didn't fix it. What did help was treating the AI like a developer joining an existing team instead of like a chatbot. Real developers don't work from memory. They inspect production, read the documentation, check the tickets, and use proven tools. I built an environment that lets the AI do the same. The workflow is tool-agnostic, so it can be rebuilt with whatever AI client and stack you already use. Step-by-step: 1. I gave the AI a persistent task and history store that it can read from and write to. This is the core of the workflow. Mine lives behind an MCP tool, but any queryable store can work. Every architectural decision, blocker, and progress note gets written there instead of being left in the chat. 2. I open every session with a stand-up. Before writing a single line of code, the AI pulls what was in progress, what's blocked, what changed since the last session, and which architectural decisions still hold. About 30 seconds later, we're both looking at the same project. Then we build. 3. I exposed real operations as MCP tools instead of relying on "write code" prompts. I wrapped specific, tested actions—such as creating a page, defining a data model, wiring an integration, and running a migration—as tools. The AI composes these known-good building blocks into larger solutions instead of regenerating infrastructure every session. I call this wave coding, and it's the biggest reason the output stays consistent. 4. I made verification a rule: before touching anything, the AI reads the live database, API state, logs, and files. It checks ground truth first instead of making assumptions. 5. I made the chat disposable and the log canonical. If it isn't logged, it didn't happen. The task store is the single source of truth, not the conversation. The payoff is that I can stop halfway through a feature, close my laptop, and come back days later. The AI reconstructs the project from its own history, so I don't spend 20 minutes re-explaining it. Full disclosure: I built this into my own platform, WebsitePublisher.ai, which currently has 43 MCP tools and 105 integration building blocks. It's delivered as an add-on that plugs into the AI client I already use over MCP, so there's no new app to learn. Nothing here is locked to that platform, though: the workflow itself works with any MCP client and any store the AI can query. I'm curious whether anyone else is running their AI this way or solving the amnesia problem from a different angle.