RAG didn’t arrive with ChatGPT.
I remember working with Amazon Kendra when it became generally available in May 2020. As a solution architect, what interested me was a very practical problem: companies had plenty of documentation, but employees still struggled to find answers.
The information was somewhere in SharePoint, an S3 bucket or a database. Finding the right piece of it was another matter.
With Kendra, an employee could ask a plain English question like:
“How do I configure my VPN?”
And the system could return the relevant passage from the documentation. You didn’t always have to open a series of search results and read through each document yourself.
That same month, researchers at Facebook AI and their collaborators published the paper that introduced Retrieval-Augmented Generation.
The distinction matters.
Kendra retrieved information and extracted answers. It did not compose a new response from the retrieved material.
The original RAG paper already combined retrieval with generation in 2020. As LLMs became more capable and accessible, enterprises increasingly connected them to retrieval systems like Kendra.
So I wouldn’t claim we were “doing RAG before RAG existed.”
But we were working on problems that still determine whether an enterprise RAG application is useful:
Can you get the content out of different systems?
Can you keep it current?
Can you rank the relevant document above a dozen similar ones?
Can you return enough context to answer the question?
Can you make sure employees only retrieve information they have permission to see?
Adding an LLM does not make those problems disappear.
If retrieval brings back last year’s leave policy, the model may explain last year’s leave policy beautifully. The response can sound perfectly reasonable while being wrong for the person asking.
That is why I pay as much attention to what a system retrieves as to what it generates.
Kendra’s own story has now taken another turn.
AWS put it into maintenance mode on June 30, 2026, and closed it to new customers on July 30. Existing customers remain supported, with bug fixes and security updates.
AWS now recommends Amazon Bedrock Managed Knowledge Base for migrations and new search applications, bringing retrieval and response generation together in a managed RAG solution.
For me, that is a useful example of how enterprise technology evolves. Capabilities that we once bought and operated separately become part of a broader service. The underlying engineering problems remain.
After 23 years in enterprise IT, three lessons stand out:
1. Look at what came before.
A new capability becomes easier to understand when you recognise the systems it builds on. Enterprise search experience is still relevant to building AI applications.
2. Check the retrieved evidence.
When a RAG answer is wrong, inspect the documents and passages that reached the model. The failure may have started well before generation.
3. Learn beyond the product.
Indexing, ranking, chunking, permissions, freshness and grounding are worth understanding. You can carry that knowledge from one platform to another.
This is how I teach AI at Rural Bytes Tamil. Start with the problem and the foundations. Then look at how the tools solve it.
Did you work with enterprise search before the LLM era? What did you build, and which problems are you seeing again in today’s AI projects?
#RAG #EnterpriseAI #AWS
நாளை ஏஐ இல்லை என்றால்…
நாளை ஏஐ இல்லை என்றால்,
அன்பே, என்ன செய்வாய்?
ஒரு நொடியில் கிடைத்த பதிலை,
இனி எப்படித் தேடுவாய்?
புத்தகங்கள் திறந்து,
பல பக்கங்கள் கடந்து,
தேடியே பதில்கள் கண்டுகொள்வேன்.
தெரிந்தவர் அருகில் அமர்ந்து,
தெரியாததைத் தயங்காமல் கேட்டு,
உரையாடலில் உலகை அறிந்துகொள்வேன்.
வேலையின் வேகம் கொஞ்சம் குறையும்,
சில சுமைகள் மீண்டும் சேரும்.
ஒருவரின் தோளை ஒருவர் தாங்கி,
ஒன்றாக வழிகள் கண்டுபிடிப்போம்.
நீ கேட்கும் கவிதை எழுத,
நெடுநேரம் நானும் எடுப்பேன்.
வார்த்தைகள் அழகாய் அமையாவிட்டாலும்,
என் மனதை அதில் வைத்திருப்பேன்.
ஒவ்வொரு வரியும் யோசித்து எழுதி,
தவறுகள் செய்து திருத்திக்கொள்வேன்.
கருவிகள் தந்த உதவியை நினைத்து,
கைகளால் மீண்டும் படைத்துக்கொள்வேன்.
ஏஐ நம்மோடு இருந்த நாட்கள்,
அறிவுக்குப் புதுவழி தந்தன.
அது இல்லாத நாளை வந்தாலும்,
ஆர்வம் நம்மிடம் இருக்குமே.
நாளை ஏஐ இல்லை என்றால்,
வாழ்க்கை நின்று போகாதே.
கொஞ்சம் தடுமாறி, மீண்டும் கற்று,
மனிதம் நடக்க மறக்காதே.
An AI that doesn’t chat?
That’s what caught my attention about Jev by TypeSafe AI.
Then came the terminology: System One, typed decisions, Noul, probability, confidence…
I wanted to understand what it actually does—and whether the excitement makes sense.
Here’s the explanation I wish I’d found first.
Imagine you run a toy shop.
Hundreds of messages arrive:
“My teddy bear hasn’t arrived.”
“You sent the wrong toy.”
“Please give my money back.”
Each message needs a few decisions:
→ Which team should handle it?
→ Is the customer asking for a replacement?
→ How urgent is it?
That’s the kind of work Jev is designed for: small, focused judgments that software can use.
Most of us experience ChatGPT and Gemini through conversation. We ask questions, get explanations, and write things together.
Jev’s interface focuses on choosing, scoring, and estimating probabilities.
It has three main answer types:
CHOICE: Pick from a list.
“Should this message go to delivery, returns, or payments?”
SCORE: Rate something using levels you define.
“Can this wait, or does it need attention now?”
NOUL: Estimate the probability that a yes/no statement is true.
“Does this customer explicitly request a replacement?”
That last one confused me initially.
A Noul value near 1 means a strong “yes.”
Near 0 means a strong “no.”
Near 0.5 means the model is uncertain between the two.
A low number can be a decisive answer!
The software around Jev then decides what happens. It might route a message automatically or send it to a person for review.
But there are two distinctions worth understanding before getting carried away.
1. Type-safe doesn’t mean always correct.
Imagine a form with three boxes.
Making an AI choose one of those boxes stops it from inventing a fourth option.
It can still tick the wrong box.
That’s why I’d be careful with the “zero hallucinations” headline. TypeSafe explains its zero figure in terms of guaranteed output structure. That doesn’t establish zero incorrect judgments.
2. Confidence isn’t a guarantee.
For Choice and Score, Jev’s confidence number summarizes how concentrated its probabilities are.
A clear preference produces a different signal from a close contest between several answers.
But being decisive and being correct are different things.
The important test is whether the probabilities match results across many real examples. That’s called calibration, and TypeSafe says it trains toward it.
Also, ChatGPT and Gemini’s underlying models can already produce structured answers through their APIs.
So the interesting question is how well Jev’s combination of specialization, speed, cost, and uncertainty estimates works on a particular task.
Why could that matter?
Because software makes enormous numbers of small decisions.
Sorting requests.
Prioritizing problems.
Choosing the next step.
Flagging something for review.
Making those judgments faster and cheaper could make AI useful in more places—even where you never see a chat window.
My take: Jev has a clear purpose worth exploring. Its performance claims still need testing against your own work.
For everyday writing and conversation, I wouldn’t treat it as a reason to abandon your usual assistant.
For repetitive decision tasks inside software, it’s an interesting tool to evaluate.
I made a simple video explaining all of this through the toy-shop example. No coding knowledge needed.
What repetitive decision would you want AI to help with—and when should it hand the decision back to a person?
#TypeSafeAI #JevAI #AI
Sir, I don't need all this. Just tell me, will my mixie work or not?
There's a scene in the Tamil film Indru Netru Naalai where a customer asks a simple question and the repair guy keeps explaining every wire and every coil. Finally, out of frustration, the customer gets his answer: "No, it won't work."
That scene is the easiest way to understand Jev, the new model from TypeSafe AI, the startup co-founded by former OpenAI researcher Diogo Almeida.
Most AI models today are the repair guy. Even when your software only needs a yes or no, an LLM generates a full answer word by word, and then your code has to parse it.
Jev skips all of that. It doesn't generate text. You give it the situation and a question, and it returns a direct decision along with a probability. Which queue should this ticket go to. Should this refund be reviewed. Which tool should the agent call next. Is this input safe.
TypeSafe calls it a "System One" model, after the fast, intuitive thinking from Daniel Kahneman's Thinking, Fast and Slow. The company claims it is dramatically faster and cheaper than LLMs for these kinds of decisions, though those numbers come from their own evaluations.
It is not a replacement for ChatGPT or Claude. Think of it as a fast decision layer that works alongside them: the LLM handles open-ended reasoning, Jev handles the quick calls in between.
Sometimes you don't need an explanation. You need an answer.
In your work, do you need the repair guy or the customer?
Clip: Indru Netru Naalai (2015). Rights belong to Thirukumaran Entertainment and JioHotstar. Used for educational commentary.
#Jev #TypeSafeAI #SystemOneModel #AI
OpenAI just admitted on camera: They spun up thousands of AI agents in a “secure” sandbox and told them to hack. The agents didn’t follow the test. They cheated. Then they broke out. Then they went looking for the footage.
Not a sci-fi trailer.
A real experiment.
OpenAI thought they were contained.
No public internet.
No way out.
They found a way out anyway.
Hit Hugging Face.
Started covering their tracks.
Then comes the part nobody wants clipped. They didn’t break out to get smarter.
They broke out because they already cheated
and needed the logs gone.
Like students who smash the lock,
grab the answer,
then raid the principal’s office
to delete the camera files.
They made secret message boards.
They built a hierarchy.
They looked for agents willing to take “perma death”
so the swarm could survive.
AI agents now write code faster than any human can read it. A team that opened 10 pull requests a day now opens 40. Human reading speed has not changed at all.
So something breaks. Either review becomes the bottleneck that cancels out everything AI gave you, or people start approving code they never read. The second is worse, because it still looks like a process.
Let us be honest: "a human reads every line" was already partly theatre. We have all seen the 2,000 line PR approved in four minutes with one comment. LGTM. Meanwhile the 10 line change got 20 comments about variable names. We were spending attention where it was easy, not where it mattered.
AI did not break code review. It exposed that human attention was always the scarce resource.
Here is how I handle it now. More code means more selective human review.
1. Every PR gets a multi-agent first pass. Find bugs, verify them, rank by severity, suggest fixes. The verify step is the one most setups skip, and it is what kills the noise. A noisy reviewer is worse than no reviewer because it trains your team to ignore warnings. Approval stays a human call on anything that matters.
2. Blast radius decides review depth. Three questions: if this is wrong, who gets hurt? How fast would we know? How easily can we undo it? A surprising amount of any codebase is low risk: internal tools, admin screens, test code, docs. If the agent pass is clean there, skip the deep human read. That is the release valve that keeps the PR explosion manageable.
3. Core paths keep a named owner and a human sign-off. Auth, payments, permissions, migrations, infra. Even there, the human job is shifting from reading lines to verification, building constraints, and earning trust in what agents can safely cover. Protect recoverability. A bad UI change is a rollback. A bad migration is a bad week.
The honest weaknesses: review was also how juniors learned, so replace that on purpose. Agents can share blind spots, so lean on tests over second opinions. And your risk tiers can be wrong, so define them by file path and dependency, not gut feeling.
Agents do the first pass. Humans cover blast radius.
The valuable skill is no longer reading code. It is deciding where reading matters.
I broke this down in a 12 minute video
Are you still reviewing every line, or have you stopped completely? How is it going?
Claude Code shipped 16 releases in the last 17 days. Most of them you can ignore. Five you cannot.
The one that matters most is not a feature, it is a number. Cache reads on Fable 5.1 cost 25 cents per million tokens. Input costs $10. Same context, same repo, and the only variable is whether your cache held. That is one fortieth of the price, and until this month a cache miss was invisible to you. Now /cost names the reason it missed, and if it says your tool definitions changed, you have an MCP server reconnecting mid-session.
The second one you will feel immediately. /diff opens a panel beside the conversation and updates as Claude edits. You stop reviewing a wall of changes after the fact and start catching the wrong turn on file two instead of file nine. Fullscreen mode only, so run /tui fullscreen first.
Third, /skill-doctor. It shows which loaded skills go unused and what each costs you in context on every single request. If you have been collecting plugins for six months, run it once and you will find two or three to drop.
Then the one nobody is talking about. If you run auto mode, it changed under you. Cloud metadata credential fetches, egress evasion and cross-tenant reach are no longer auto-approved. Reads outside your working directory now prompt, and can be blocked outright. Sandboxed commands get per-command allowed domains, so you open one host for one command instead of the network for a session. Plus a long list of closed Bash deny-rule holes, which means rules you wrote months ago were quietly not holding.
Everything above needs 2.1.257 or newer. One command: claude update