Codersarts Blog.

Context windows keep growing. Models now accept inputs that once seemed impossible, and it is tempting to conclude that retrieval is obsolete. Why build an index when you can paste everything into the prompt? The answer is that capacity is not the same as capability. A model can accept a very long input and still use it unevenly. As the input grows, answers can become less reliable, details in the middle can be missed, and irrelevant text can pull the model off course. This p

Standard RAG retrieves for every question, whether or not it needs to. It passes the same number of passages to the model, whether they help or not, and it rarely checks whether the final answer actually follows from them. Self-RAG proposes a different design. A single language model learns to decide when retrieval is needed, to judge whether each retrieved passage is relevant, and to critique whether its own output is supported by the evidence. It does this by producing spec

A user asks a short, vague question. Your RAG system turns it into a vector and searches for similar passages. The best passage is in the index, and the search misses it, because a question and its answer rarely look alike. HyDE, short for Hypothetical Document Embeddings, attacks this gap. Instead of embedding the question, a language model first writes a short hypothetical answer. That draft may contain mistakes, and it does not matter. The system embeds the draft and uses

Standard RAG has a quiet weakness. It retrieves passages, passes them to the language model, and trusts that they are relevant. When retrieval returns weak or wrong passages, the model often builds a confident answer on top of them. Corrective RAG, often shortened to CRAG, adds a checkpoint. After retrieval, a lightweight evaluator grades the results. Good results are cleaned and used. Poor results are discarded, and the system looks elsewhere. Uncertain results are combined

Standard RAG finds text chunks that look similar to a question and hands them to a language model. It works well for questions answered by a single passage. It struggles when the answer depends on connections spread across many documents. LightRAG is a retrieval approach that adds a lightweight knowledge graph to the retrieval step. Instead of searching only chunks, it searches entities, relationships, and themes extracted from your documents, and it can add new content witho

Retrieval-augmented generation became the default way to give language models private knowledge. A retriever finds relevant passages at question time, and the model answers from them. It works, and it adds moving parts: an index, a retriever, ranking, and the chance of fetching the wrong passages. Cache-augmented generation, or CAG, takes a different route for the right cases. Instead of retrieving at question time, you load the whole knowledge set into a long-context model a

Every homoeopath knows how much goes into a single case. Long consultations, careful symptom selection, and repertory work all come before a remedy is chosen. Homeo AI is a clinical copilot that brings AI into this process while leaving every decision with the doctor. This blog explains what Homeo AI is, how its main capabilities work, and how doctors can try it. Everything here is based on the information Homeo AI shares about its platform. What Is Homeo AI? Homeo AI is an A

Connecting an agent to more tools sounds like pure progress. Each new MCP server adds capability, and each one also adds text that the model must read before it can do anything useful. Tool names, descriptions, and input schemas all take up space in the context window. Large tool results take up more. Left unmanaged, this context bloat raises cost, slows responses, and can make the agent worse at choosing the right tool. This blog explains where the tokens go, how to measure

Teams building AI agents keep running into two ideas that sound similar and do different jobs: skills and MCP. Both extend what an agent can do. Mixing them up leads to bloated prompts, missing connections, and systems that are harder to maintain than they need to be. In short, MCP gives an agent access to tools and data. Skills give an agent know-how: instructions, procedures, and resources for doing a kind of task well. One answers the question of what the agent can reach.

AI agents are learning to use websites the way people do. They read the page, find a button, click it, and hope the layout has not changed since the last visit. It works, and it is fragile and slow. WebMCP proposes a different approach. Instead of guessing how a page works, an agent asks the page what it can do. The website publishes a list of tools with clear names, descriptions, and inputs, and the agent calls them directly. This blog explains what WebMCP is, how it works,

Most teams build their first MCP server as a single process on one machine. It works well in development, and the design questions only appear later, when traffic grows, a second instance is added, or a deployment restarts the server in the middle of someone's work. At that point, one question decides a lot: does the server remember anything between requests? A stateless MCP server does not. Every request carries what the server needs, and any instance can answer it. This blo

Two protocol names keep appearing in discussions of AI agents: MCP and A2A. They are often mentioned together, and they are sometimes treated as rivals. In practice, they solve different problems. MCP, the Model Context Protocol, connects an agent to tools and data. A2A, the Agent2Agent protocol, connects one agent to another. A single agent system can use both, and many serious multi-agent designs will. This blog explains what each protocol does, how they differ, how they fi

When a RAG assistant gives a wrong answer, the first reaction is usually to blame the language model. Teams try a bigger model, rewrite the prompt, or add more instructions. Often none of it helps, because the model never saw the right information. A model cannot use a passage it was never given, and it will confidently answer from whatever it was given instead. This blog explains why retrieval should be evaluated first, how to separate retrieval failures from generation fail

Every useful AI agent needs a way to act: search a database, send a message, create a ticket, read a file. Two approaches dominate how language models are connected to such tools. Direct function calling defines the tools inside your application. The Model Context Protocol, or MCP, defines them in separate servers that any compatible application can use. Both work, and they suit different situations. This blog explains how each one works, compares them on the points that matt

The usual way an AI agent uses tools is simple. The model picks a tool, the system runs it, the result goes back to the model, and the cycle repeats. It works well for a handful of tools and short tasks. It strains as the number of tools grows. Every tool definition sits in the model's context, and every intermediate result passes through the model on its way to the next step. Code Mode MCP takes a different route. Instead of calling tools one at a time, the agent writes a sm

Most AI systems today are built around one idea: a large language model reads a prompt and writes text, one token at a time. That approach is flexible, and it has shaped how teams think about every AI problem. Many decisions inside business software do not need flexibility. They need a fast, reliable answer to a narrow question, such as which queue a request belongs in or whether a case should be escalated. In September 2026, TypeSafe introduced Jev, a model it describes as t

Large language models are impressive, and many teams reach for one first. For a surprising number of business problems, a smaller and older approach does the job better, faster, and for far less money. Classic machine learning means models such as gradient boosted trees, logistic regression, and random forests, trained on structured data for one specific task. They are not glamorous, and in the right setting they are hard to beat. This blog explains when classic ML wins over

Reviewing AI outputs by hand is slow and expensive. So many teams ask a language model to do the grading. A judge model reads an answer, scores it against a rubric, and moves on to the next thousand. The idea works well in some settings and fails quietly in others. A judge that agrees with your reviewers on easy cases can still miss the mistakes that matter most, and it can reward the wrong things without anyone noticing. This blog explains when an LLM judge tends to agree wi

A RAG system lives or dies on what it retrieves. If the right passage never reaches the language model, the answer will be wrong, however good the model is. Re-ranking is a popular fix. The system retrieves a larger set of candidate passages, then a second model reads each one alongside the question and puts the best at the top. It often improves relevance. It also adds time to every request, and that time is paid by every user. This blog explains what re-ranking does, what i

When an AI system makes a decision, someone will eventually ask why. A customer disputes a result, a regulator requests evidence, or a team member wants to know why the assistant behaved oddly last Tuesday. Without a good record, the honest answer is that nobody knows. With one, the question can be answered in minutes. This blog explains what to record in audit logs for AI decisions, why each item matters, and how to store the logs safely. It reflects the approach of the Code