Most products add AI the same way: a chat panel bolted onto the side of what already exists. An RSS reader can do the opposite. It can apply AI exactly where you already are — summarize the item you're looking at, rank the items you're about to see, triage the firehose before it reaches you — and never open a separate surface at all. That's the design tribb takes, and this essay argues it's the right one.
The distinction sounds small. It isn't. A chatbot bolted onto a reader is a different application sharing a sidebar; it makes you switch context, restate what you're looking at, and copy answers back. AI at the point of need is a property of the surface you're already using. The reader gets smarter; you don't change tools.
Why this matters now
RSS solved distribution and gave up on triage. It moves items reliably from a thousand sources into one place, then leaves you alone with the pile. LLMs are good at exactly the part RSS skipped — reading a thing and telling you whether it's worth your time. So the question isn't whether to put AI in a reader. It's where.
The default answer, everywhere, is "add a chat box." It's easy to build and easy to demo. But a chat box is a second job: you leave the item, describe it to the assistant, read the reply, and carry the conclusion back to where you were. The reading never got easier. A second interface got added next to it.
Two designs, side by side
The contrast is easiest to see than to describe.
On the left, the AI lives beside the reader. Every use of it costs a round trip you perform manually: leave the item, phrase a question, read a reply, return. On the right, the AI is aimed at the three things a reader actually does with a firehose — understand one item, order the next hundred, and cut what shouldn't reach you at all.
Summarize the item you're on
When you're deciding whether to read something, the useful question is narrow: is this worth my next ten minutes? Point-of-need AI answers it in place. You ask for a summary of the item in front of you, and the summary appears against the item — no new window, no restating what "this" is. Then you open it, save it for later, or dismiss it and move on.
A chatbot can also summarize, but you have to hand it the context first. The reader already has the context. Applying the model where the item lives removes the step that made the chatbot a chore.
Rank on signals you control
Triage is ranking. The reader has to decide what floats to the top of your queue, and an LLM is a good ranker — it can read an item and estimate how well it matches what you care about. The risk is obvious: a ranker you don't understand is a feed you don't trust.
So the signals have to be yours. When you downrank a source, that's an instruction, not a vote the system is free to reinterpret. When you save consistently from one kind of item, that's a signal you can see reflected in what rises. Point-of-need ranking is legible because it's wired to the same canonical actions you already take — save, dismiss, downrank, archive — rather than to an opaque model with opinions of its own. You steer; the model does the reading.
The tradeoffs
This design costs something, and the honest move is to say what before you find it.
You bring your own key. tribb is bring-your-own-key (BYOK): the model is yours, billed to you, and tribb doesn't rotate or subsidize it. That's real friction — a key to obtain, a bill to watch, and a cold-start moment before AI features do anything. We chose it on purpose, because the alternative is your reading becoming someone's training data. With BYOK, your reading is not training data. That's the trade: setup friction and per-call cost, in exchange for the model working for you and no one reading over your shoulder.
There's latency, and it's yours. A summary is a network round trip to a model provider. It's usually a second or two, sometimes more, and it lands on the exact action you took. We'd rather show you an honest spinner than pre-summarize everything and bill you for reading you'll never do.
The model gets things wrong. A summary can miss the point; a ranker can bury something you'd have wanted. So point-of-need AI stays advisory. It orders and condenses; it never runs dismiss or archive on its own. The item is always one tap from the source, and the ranking never hides an item — it only changes the order you meet it in.
Over-automation is the real temptation. The tempting next step is to let the AI read for you — auto-summarize the whole queue, auto-dismiss the low-ranked, and hand you a digest of a digest. That's a different product, and a worse one: it optimizes you out of your own reading and quietly decides what you never see. Point-of-need AI is deliberately AI that reads with you. It acts when you ask and on what you're looking at, and it leaves the judgment where it belongs.
And it demos worse. A chatbot is a great demo — you type a question, an answer streams back, the room nods. "The summary appeared where you were already looking, and you didn't switch apps" is a harder thing to show and an easier thing to live with. We're optimizing for the second one.
Where this leaves us
The reader is the right place to put AI precisely because it's where the work already happens. Bolting a chatbot on the side adds a second surface and a manual round trip to every question. Aiming the model at the item you're reading and the queue you're triaging makes the reader itself do more, on signals you control, without moving you anywhere. It's less flashy and more useful — which, for a tool you open every day, is the trade worth making.