Signal is the part of DEVKEV where I publish selected AI developments, tools and ideas that I think are worth paying attention to.
When I started building Signal, the obvious temptation was to automate the whole thing.
Find a story. Decide whether it is interesting. Research it. Write something. Publish it. Move on.
I built some of that. Then I started taking parts back out.
The mechanical work was easy to justify automating. Checking feeds, removing duplicates, moving information between n8n, Discord, Hermes and WordPress, validating fields and checking that a post arrived correctly are all repeatable jobs.
The harder question was what happened when the system stopped handling content and started making editorial decisions.
At one point I had AI scoring incoming stories and deciding which ones were worth putting in front of me.
It worked.
I removed it anyway.
The question had changed from “how much of this can I automate?” to “which decisions do I actually want to keep?”
Why I took the scoring out
Signal uses The Rundown as a discovery feed. It gives the system a regular stream of AI stories, but I never wanted DEVKEV to become a rewritten version of somebody else’s newsletter.
The first version went further than discovery. AI scored each incoming story for relevance, applied a threshold and only showed me the ones it thought were worth considering.
From an efficiency point of view, that made sense. Why look through stories an AI system could filter first?
Because the filtering was not really administration. It was editorial judgement.
If the system decided what deserved my attention before I had seen it, I was handing over one of the decisions that gave Signal a reason to exist.
Now the automation collects the feed, removes duplicates and tracks what I have already seen. It does not decide what I ought to find interesting.
I would rather reject a story myself than never know the system rejected it for me.
What I automated instead
New stories arrive in Discord as a short numbered digest rather than becoming drafts automatically.
I choose the story.
My Agent CEO, the general-purpose agent I run through Hermes to coordinate the wider setup, then asks what interests me about it before the research begins.
Sometimes I have a clear angle. Sometimes I simply find the story interesting. Both are valid.
What I do not want is the system manufacturing an opinion because it thinks the article needs one.
Once that context is captured, the research moves beyond the discovery feed. The workflow looks for the underlying announcement, documentation, paper, repository or other primary material wherever possible and builds the article around that rather than simply paraphrasing the newsletter that surfaced it.
There is also a citation layer which checks that referenced sources exist in the research ledger and that the draft has sufficient source coverage before it moves further through the process.
It is a mechanical check, not proof that every sentence is true.
The feed tells me something happened. The research has to establish whether there is enough underneath it to justify publishing the story.
Publication requires explicit approval
The system could publish automatically. I chose not to let it.
Once an article has been researched, drafted and reviewed, I see the complete version before anything is sent to WordPress. If I want something changed, it is changed and shown again.
Only an explicit Publish or Go moves it forward. That rule became stricter after an early test showed how easily a conversational system could interpret the wrong response as permission to continue.
Selecting a story is not approval. Giving it an angle is not approval. Saying I like the result is not approval. Silence is not approval.
I originally described that as a hard boundary.
During a review of the first draft of this article, that phrase was challenged.
Was publication actually prevented without my approval, or had I given the Agent CEO a very clear instruction not to publish without it?
So I audited the workflow.
The answer was the second.
My Agent CEO has broader system access because it also oversees other parts of my automation environment. The approval requirement is an operating rule for a trusted agent rather than a security control built to contain a hostile agent.
I am comfortable with that distinction.
The checks downstream of that decision are different. Once an approved article reaches n8n, validation, duplicate protection and read-back verification are enforced by the workflow itself, not by instruction.
Not every boundary in an agent system has to be a security boundary. But you do need to know which kind you have.
Why I added a separate Editor
The Editor is the newest part of the workflow, and its role is deliberately narrow.
It receives the completed draft together with the context, evidence and citations already gathered. It is instructed not to conduct its own research or take over authorship.
Instead, it reviews the finished piece and returns a verdict: READY, REVISE or BLOCKED.
The originating agent owns the draft and any revision. I own approval.
The Editor is there to ask different questions. Is the wording too certain? Does something technically correct still sound artificial or assembled? Could a reader take something from the wording that I did not intend?
There is another deliberate difference.
The Editor uses a different model from the rest of the workflow.
I did not want the same model helping to produce an article and then effectively reviewing its own work.
That risks creating a closed loop where the second pass reinforces the same assumptions, habits and stylistic choices as the first.
Using another model does not make the second opinion automatically right.
It gives me a second opinion with different habits.
So far, that is exactly what I wanted from it. The review of this article has already challenged wording, identified assumptions and made me describe parts of the system more accurately.
A filter, not a slop machine
There is an extraordinary amount happening around AI, and most of us do not have the time to follow everything, read every announcement or work out which stories deserve another look.
I am hoping Signal can do a small part of that sifting.
Something that stood out amongst the releases, research, claims and noise.
Something that made me stop for a few minutes and think it might be worth passing on.
That does not mean I agree with every development I cover.
Signal is not an endorsement. It is a filter.
Once the factual reporting is finished, I close each Signal with WHY I’M PAYING ATTENTION.
Not because my view is definitive, but because I do not want DEVKEV to simply repeat what already exists. I want there to be a reason I selected the story, and I want the reader to know what that reason was.
The easiest version of this project would have been simple.
Take an existing article. Rewrite it. Publish it. Repeat.
It would probably have been easier to scale too.
I was more interested in building the opposite.
AI can help me discover stories, research them, organise sources, draft, critique and improve the writing. Automation can handle deduplication, data movement, publication mechanics, verification and distribution.
Those things remove work without necessarily removing judgement.
The decisions I have kept are different.
What caught my attention?
Why did I choose this story?
Does the reporting support what is being said?
Did the Editor actually improve it?
Does the finished piece represent what I intended?
Is it worth publishing?
Those are still mine.
That is the line I was trying to draw when I started building Signal, even if I could not articulate it properly at the beginning.
I am not trying to automate authorship. I am trying to automate the support system around it.