A few weeks ago I wrote about why I built ViaMind Radar. That post was about the problem: too much noise and too little clarity about what deserves attention.
Since then Radar has changed quite a bit. I thought it was going to be simpler: connect sources, let AI detect the interesting stories, and publish the best ones.
It was not. The hard part was not getting an AI to find news or write. It was deciding what the model should do and what had to stay under software control.
How much power do I actually want to give the model?
Over time, ViaMind Radar stopped feeling like a news site with AI and started becoming an automated editorial system with AI, software, and rules.
Radar is not a giant agent
From the outside it might look like a super-agent that browses the internet and publishes whatever it considers important.
That is not how it works.
It is a robust editorial pipeline: software, rules, and model calls in specific stages. And this was one of the first things I had to learn: using AI for everything does not necessarily make the system better. There are tasks where I want exactly the opposite: predictable behavior.
Finding new URLs, scheduling, publishing, budget limits, and story states are mainly software. AI comes in where it adds judgment: interpreting language, evaluating relevance, checking evidence, and writing.
Radar works on a controlled catalog of media outlets, regulators, blogs, and documents. The model is not freely browsing the internet. First the software looks for signals and generates candidates. Then the filters begin, because spending expensive resources on noise makes no sense.
Deduplication happens at different points. Detecting the same URL is one thing. Detecting very similar texts is another. Understanding that two outlets are covering the same event is much harder. That is where the editorial funnel starts.
The main ViaMind Radar flow. AI steps in where it adds judgment; software keeps control over volume, rules, and operations.
One question is not enough
At first I thought of it as a single question: is this news item good or bad? That was too simplistic.
Today Radar separates at least two decisions: is this worth investigating? And then: once investigated, does it really deserve to be published?
A story can shine in the headline and lose strength when you review what sits behind it. Another may not look spectacular and end up showing a more relevant signal. The model analyzes editorial dimensions —a scoring, not a verdict— and returns signals. The code recalculates, applies rules, and decides how far something can go.
The model can have an opinion, but I do not hand it the keys to the system.
The expensive part starts later
When a story makes it through that funnel, the expensive part begins. Radar builds a dossier, separates reported facts from promises, inferences, and gaps, and compares the important claims with evidence from the allowed sources. Only after that comes the writing.
Verification happens before writing. I do not want a nice text that later has to be justified.
That does not mean Radar independently confirms everything it publishes. If a source says something, it can attribute it. Missing extra evidence does not make a claim false, just as finding it in a source does not make Radar an independent investigator. It looks like a small difference. It is not.
The ViaMind View is probably the hardest part
If Radar only summarized news, the project would interest me much less.
The part I try hardest to protect is the ViaMind View. I do not want only to explain what happened. I want the system to ask what actually changes, who wins, who loses, which part of the announcement might be exaggerated, what signal sits behind it, and what could happen next.
A model can write well fairly quickly. Getting it to think in a relatively consistent way inside an editorial line takes prompts, rules, examples, testing, and often going back because an “improvement” made another part worse.
READY: when the last mile stopped being intelligent
One of the changes that has helped me most was a simple idea: READY. A story cannot enter a publication window until it is ready. Only then does it get scheduled.
When the time comes, the system does not call a model again or decide again. It publishes something that was already prepared.
At first I imagined that an intelligent system should make decisions close to the end. Today I prefer the opposite. The last mile should be boring.
Operating Radar does not cost the same as developing it
Talking about the cost of an AI system without separating operation and development can be misleading. I try to spend tokens where they actually add value, and there is a daily budget limit so a defective flow cannot fire calls indefinitely.
In normal operation, Radar runs at around a dollar a day. That number can still improve. But it is not the cost of building it.
When I make an important change, I have to run the system almost completely: an end-to-end test from scratch. On some days I have run four of those tests in preproduction and another three when moving to production. Easily US$5 or US$7 in Radar calls alone.
And that is not all. Building it is not just the product API. It is Claude, Codex, and Cursor: the tools I use to write, review, debug, and test again. That spend does not show up on the bill for publishing a story, but it is a real part of the cost. If you only look at production calls, the number is incomplete.
That is development cost, not product cost. But it does change how the work has to be thought about. Every realistic test of an AI system also has a price.
Control: automating does not mean looking away
That gap between operating and building shows up here too. As Radar became more autonomous, I started to need a layer from which to understand what it is doing. That is how Control was born.
It does not exist to manually approve every story. That would destroy the point of automating. It exists to observe, detect blockages, and step in if something leaves the path. Autonomy does not mean absence of supervision.
Control is the operational layer where I can follow stories, states, and flows, and step in when something needs human supervision.
Radar no longer has a single flow
The project started as a newsdesk and gradually created other lanes: the Home Editor for the homepage, a weekly flow for the week’s key takeaways, and social distribution to LinkedIn and Buffer.
I do not want Radar only to produce content. I want it to distribute that content consistently as well.
Radar is no longer a single process. Newsdesk, homepage, weekly briefing, distribution, and Control work as specialized lanes around the same editorial system.
Most of the improvements were born from things that went wrong
Many of the most important changes did not come from new features. They came from problems.
At one point it looked as if the system was not finding enough stories to fill the day. News was not missing: the time budget to prepare them was too short. A single candidate could take one or two minutes, and the process ran out of time.
Another problem came from images. There could be a valid story, researched and ready, but without a sufficiently safe image, and that broke a publication window. The solution was to validate the image before reserving the slot. It seems obvious afterwards. Before, it was not.
I also had infrastructure problems. On August 29, in production, the kernel killed the Radar service five times for running out of memory (OOM). The host had less than 4 GB of RAM and Radar was peaking at 2.5 to 3.2 GB. That same day a NeuraPRO process went down too. Days later, in preproduction, the Node heap ran out with too many abandoned jobs overlapping.
I put memory and process limits in place. An autonomous system without ceilings can not only spend more tokens; it can also take down the infrastructure.
I have also had unstable scoring, invalid structures, and truncated answers. Each of those problems ended in a rule, a fallback, or an architecture change. That is the least visible part when someone sees a system working.
Building with AI is still building
From the outside there is still a fairly simplified idea: you have an idea, you explain it to an AI, and the AI builds the application. My experience has been different.
Yes, I can write code, explore alternatives, and build on my own things that a few years ago would probably have needed a team. But the work does not disappear. The more autonomous I want Radar to be, the more precise I have to be about how it should behave.
That is why I look with caution at a fairly common idea in companies: asking teams, on top of everything they already do, to start building AI solutions as well. Not because AI does not help. It helps a lot. But using it well and maintaining what gets built also takes real hours.
AI does not eliminate engineering work. It changes where that work concentrates.
ViaMind Radar is far from finished. But an AI editorial pipeline already exists that a few months ago was only an idea. And the more autonomous it becomes, the more important something else feels: understanding exactly what it is doing and keeping the ability to control it.
That has been one of the most interesting lessons of building it. Not only learning what artificial intelligence can do. Also learning where it should stop deciding, and the system should start deciding instead.
All of this is what is running today behind the stories that appear on ViaMind Radar.
Related reading:
- The Problem Is No Longer Finding News. It’s Knowing Which Stories Matter.
- AI Did Not Give Me New Ideas. It Gave Me a Way to Build Them.
- The AI Bill: the Problem Almost Nobody Is Talking About
✍️ Claudio from ViaMind
“Dare to imagine, create and transform.”
FEATURED POSTS
ABOUT ME
ViaMind Ecosystem
- ViaMind — The brand hub for ideas, technology and strategy.
- NeuraPRO — Practical software for managing real operations.
- ViaMind Radar — Less noise, more signal. AI-curated technology stories.