DEV Community: Rijul Rajesh

Keep Up With AI by Building Your First Vector Database with ChromaDB

Rijul Rajesh — Wed, 12 Aug 2026 19:59:39 +0000

Hello, I'm Rijul. I'm building git-lrc, a micro AI code reviewer that runs on every commit. It's free and source-available on GitHub. Star git-lrc to help more developers discover the project. Do give it a try and share your feedback

ChromaDB is a term you might have heard being mentioned quite often when working with AI applications.

ChromaDB is a vector database.

It is the kind of database you will often see being used in AI applications such as chatbots, RAG systems, and other applications that need to search for information based on semantic meaning.

What Is a Vector Database?

Let's say we have two sentences:

How can I get my money back?

and

What is your refund policy?

The words are different, but the meaning is similar.

To allow a computer to work with this kind of semantic similarity, we can convert text into numbers called embeddings.

An embedding is a numerical representation of the meaning of a piece of text.

A vector database allows us to store these embeddings and later search for information based on their semantic similarity.

ChromaDB is one such vector database.

Installing ChromaDB

Let's start by installing ChromaDB:

pip install chromadb

Once installed, we can import it and create a client:

import chromadb

chroma_client = chromadb.Client()

Now we can create a collection:

collection = chroma_client.create_collection(name="my_collection")

You can think of a collection as a place where we store related pieces of data.

Adding Documents

Now let's add some documents to our collection:

collection.add(
    ids=["id1", "id2"],
    documents=[
        "This is a document about pineapple",
        "This is a document about oranges"
    ]
)

We use collection.add() to add the text to the database.

One useful thing here is that we don't have to manually generate the embeddings ourselves for this basic example.

ChromaDB can generate embeddings for the documents for us.

When you run this for the first time, ChromaDB will download the embedding model it uses to generate these embeddings.

Once the documents and their embeddings are stored, we can search the collection.

Querying the Database

Let's query the database:

results = collection.query(
    query_texts=["This is a query document about hawaii"],
    n_results=2
)

print(results)

Here:

query_texts contains the text we want to search for.
n_results specifies how many results we want to retrieve.

ChromaDB will generate an embedding for the query and compare it with the embeddings stored in the collection.

It then returns the most relevant results.

The output might look something like this:

{
    'ids': [['id1', 'id2']],
    'embeddings': None,
    'documents': [
        [
            'This is a document about pineapple',
            'This is a document about oranges'
        ]
    ],
    'uris': None,
    'included': ['metadatas', 'documents', 'distances'],
    'data': None,
    'metadatas': [[None, None]],
    'distances': [[1.0404, 1.2431]]
}

Notice the distances field.

These values represent how far the results are from the query in the embedding space. The exact interpretation depends on the distance function being used.

In this example, the pineapple document has a smaller distance than the oranges document, meaning ChromaDB considers it more similar to the query.

Getting the Embeddings

By default, the embeddings aren't included in the query result.

If we want to see them, we can explicitly request them:

results = collection.query(
    query_texts=["This is a query document about hawaii"],
    n_results=2,
    include=[
        "distances",
        "metadatas",
        "embeddings",
        "documents"
    ]
)

print(results)

Now the output will include the actual embedding vectors:

{
    'ids': [['id1', 'id2']],
    'embeddings': [
        array([
            [-0.0071,  0.0655, -0.0116, ...,  0.0897,  0.0134],
            [-0.0265,  0.0688, -0.0377, ...,  0.0654,  0.0778]
        ])
    ],
    'documents': [
        [
            'This is a document about pineapple',
            'This is a document about oranges'
        ]
    ],
    'uris': None,
    'included': [
        'distances',
        'metadatas',
        'embeddings',
        'documents'
    ],
    'data': None,
    'metadatas': [[None, None]],
    'distances': [[1.0404, 1.2431]]
}

The actual embedding contains many numbers, so I've shortened the output with ....

The important thing to understand is the flow:

Document
    ↓
Embedding
    ↓
Stored in ChromaDB
    ↓
Query
    ↓
Query embedding
    ↓
Similarity search
    ↓
Relevant documents

And that's the basic idea behind using ChromaDB as a vector database.

Wrapping Up

In this article, we looked at the basics of ChromaDB:

This is only the basic usage.

The more interesting part is seeing how we can use ChromaDB in a real application, such as a RAG system, where we can store documents, search for relevant information, and provide those results to an LLM.

We can explore that in another article.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

You've Heard of RAG. But What Does It Actually Do?

Rijul Rajesh — Mon, 10 Aug 2026 19:56:22 +0000

Have you been scrolling through AI content and constantly seeing the term RAG?

Maybe it sounds like some complicated, high-level AI concept that is difficult to understand.

But RAG is actually fairly simple.

And if you're trying to build AI systems, it is a concept worth understanding.

Let's look at some of the different types of AI systems we see today and understand where RAG fits in.

Types of AI Systems We See Today

There are many different ways of building AI systems today, such as:

Generative AI
RAG systems
Agentic systems
Multi-agent systems

In this article, we'll focus on RAG.

What Is RAG?

RAG stands for Retrieval-Augmented Generation.

The basic idea is simple:

Instead of asking an LLM to answer a question using only what it already knows, we retrieve relevant information and give it to the LLM along with the question.

To understand how this works, we need to look at the main components of a RAG pipeline.

Understanding the RAG Pipeline

A basic RAG pipeline looks like this:

Documents
    ↓
Chunking
    ↓
Embeddings
    ↓
Vector database
    ↓
User question
    ↓
Question embedding
    ↓
Similarity search
    ↓
Relevant chunks
    ↓
Prompt + retrieved chunks
    ↓
LLM
    ↓
Answer

Let's break down each part.

What Is Chunking?

Suppose I have a file called policies.md.

It contains 1,000 lines of information.

I don't want to send the entire document to the LLM every time a user asks a question.

Instead, we break the document into smaller pieces.

This process is called chunking.

Chunking = breaking documents into smaller pieces that can be independently retrieved.

For example:

policies.md
    ↓
Chunk 1
Chunk 2
Chunk 3
...
Chunk 50

Now, instead of searching through or sending the entire document, we can retrieve only the chunks that are relevant to the user's question.

What Are Embeddings?

An embedding represents the semantic meaning of text as numbers.

For example, this sentence:

"What is your refund policy?"

can be converted into an embedding such as:

[0.021, -0.183, 0.442, ...]

The actual embedding contains many more numbers, but the important idea is that text is converted into a numerical representation.

This is useful because we can compare these numerical representations to determine how semantically similar two pieces of text are.

For example, these two questions use different words:

"How can I get my money back?"

and

"What is your refund policy?"

But they have a similar meaning.

Their embeddings should therefore be relatively close to each other.

Understanding the Vector Database

We can store the chunks and their embeddings in a vector database.

We also keep information about where the chunk came from.

Something like:

{
    "text": "Customers can request a refund within 30 days...",
    "embedding": [...],
    "source": "policies.md"
}

So the vector database gives us a way to store our knowledge and later search for information based on semantic similarity.

What Does Retrieval Mean?

Now let's see how retrieval actually works.

Suppose the user asks:

What is the refund policy?

First, we convert the question into an embedding.

Then we search the vector database using that embedding.

The database might return something like:

1. policies.md
   "Customers can request a refund within 30 days..."

2. policies.md
   "Subscriptions can be cancelled at any time..."

3. pricing.md
   "The Pro plan costs $29/month..."

The first result is highly relevant to the question.

Finding these relevant pieces of information is called retrieval.

How RAG Changes the Prompt

Now we have the relevant information.

We can add it to the prompt that we send to the LLM.

Before

User: What is the refund policy?

The model has to answer using only the information it already has.

After

System:
Answer using the provided context.

Context:
Customers can request a refund within 30 days...

Question:
What is the refund policy?

Now the LLM has the relevant information available in its context.

It can generate:

Customers can request a refund within 30 days.

And that's essentially what Retrieval-Augmented Generation means.

Retrieval

Find relevant information.

Augmentation

Put that information into the prompt.

Generation

Ask the LLM to generate an answer using that information.

That's RAG.

Building Your Own RAG: A Simple Example

Now let's take a simple use case and see this in action.

I have a small repository that you can clone and try yourself.

Suppose I have a chatbot that is supposed to answer questions about a company.

The project contains a documents folder with four files:

Company
Policies
Pricing
Products

The chatbot uses Gemini as the underlying LLM.

First, Let's See the Problem Without RAG

First, activate the virtual environment:

source .venv/bin/activate

Then run the chatbot without RAG:

python chat.py --no-rag

Now I'll ask:

What is the company's refund policy?

As you can see, the response is generic.

The chatbot doesn't have access to the company's actual information.

Let's try another question:

Who is the CEO?

Again, we get a generic response.

The problem is that the LLM doesn't have our company's documents in its context.

Now Let's Run the RAG Version

Now let's run the RAG version of the chatbot:

python chat.py

We'll ask the same question:

What is the company's refund policy?

This time, you can see the retrieved chunks.

The system first searches the documents and finds the pieces of information that are relevant to the question.

It then provides those chunks to the LLM so it can generate an answer based on the company's actual information.

Now let's ask something that isn't present in the knowledge base:

Who is the CEO?

This time, the chatbot can recognize that the information isn't available in the knowledge base instead of simply making up an answer.

That's one of the useful properties of RAG.

Wrapping Up

We have built and demonstrated a basic RAG system.

Along the way, we got familiar with concepts such as:

Chunking
Embeddings
Vector databases
Retrieval
Knowledge bases
Retrieval-Augmented Generation

Once we break the process down, these concepts are much simpler than they might initially seem.

Of course, this is only a basic example of RAG.

There are many deeper topics to explore, such as different chunking strategies, embedding models, retrieval methods, reranking, hybrid search, and evaluation.

But for now, you have a basic understanding of what RAG actually does and how the pieces fit together.

See you in the next article.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

Stop Making Your AI Agent Rediscover Your Codebase

Rijul Rajesh — Sun, 09 Aug 2026 19:49:12 +0000

As I use AI coding agents to work on my repositories, I often find myself opening new sessions for different tasks.

The problem is that every new session starts with the same challenge.

The agent may have to rediscover the codebase.

It may search for files, follow imports, look through related code, and try to understand the project structure all over again.

This gets annoying pretty quickly.

It also means spending additional time, tokens, and context on work that has already been done in previous sessions.

So I started looking for a way to solve this problem, since I imagine many people using coding agents run into the same issue.

That's when I came across codebase-memory-mcp.

What Is codebase-memory-mcp?

You can find the repository here:

https://github.com/DeusData/codebase-memory-mcp

The basic idea is to create a persistent knowledge graph of your codebase that an AI agent can query.

Think about a textbook.

A textbook usually has an index that tells you where to find specific topics instead of requiring you to read the entire book to locate something.

codebase-memory-mcp applies a similar idea to your codebase.

Instead of making the agent repeatedly explore files and related code to figure out where something is, it can query the indexed representation of the codebase and use that information to find the relevant parts.

This gives the agent a better starting point when working on a repository.

Rather than repeatedly asking:

Where is this functionality implemented?

Which files are connected to this component?

Where is this function used?

The agent can use the codebase index to navigate the repository more efficiently.

Installing codebase-memory-mcp

You can follow the installation instructions in the repository's README.

For Linux, you can install it with:

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

Once the installation is complete, you can run:

codebase-memory-mcp install

This configures the MCP server for a number of supported AI coding agents, including OpenCode and Claude Code.

After that, you need to index your project before the agent can query the indexed codebase. The project's README recommends restarting your coding agent and asking it to "Index this project".

Wrapping Up

When we start using AI agents for software development, there are new limitations that we don't encounter in the same way with traditional development.

One of them is the amount of time and context an agent can spend rediscovering a codebase.

Tools like codebase-memory-mcp are interesting because they try to solve that problem by giving agents a persistent representation of the codebase that they can query instead of starting from scratch every time.

As we adapt to agent-based development, understanding these limitations and finding ways to work around them can make the overall development process much smoother.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

I Was Underusing OpenCode. Then I Discovered Its Agents

Rijul Rajesh — Sat, 08 Aug 2026 20:21:19 +0000

OpenCode is one of the popular coding agents available right now.

I've been using it as my daily driver for a while, and there are still many of its features that I haven't explored yet.

In this article, we'll take a look at the agent functionality in OpenCode.

There are two types of agents in OpenCode:

Primary agents
Subagents

Primary Agents

These are the main agents that you interact with directly.

There are two types of primary agents:

Build

This is the primary agent with all the tools enabled.

This is what you would normally use when you want the agent to actually work on your codebase.

Plan

This agent is more restricted.

If you want to repeatedly plan and think through something before actually going into execution mode, this is the agent you can use.

The idea is to separate planning from execution.

Subagents

Subagents are specialized assistants that primary agents can invoke for specific tasks.

For example, instead of having the primary agent explore an entire codebase itself, it can delegate that task to a specialized subagent.

You can also invoke these specialized agents directly using @.

OpenCode comes with three built-in subagents.

General

A general-purpose subagent designed for research and multi-step tasks.

You can use it when you want to delegate a task that requires some investigation or multiple steps.

Explore

This is a read-only agent designed for exploring codebases.

For example, if you want to find files based on patterns or understand how something is implemented across a project, this is the agent you can use.

Since it is read-only, it can explore the codebase without making changes.

Scout

Scout is another read-only agent.

It is useful for researching external documentation or comparing external code, such as another repository or upstream implementation.

So if you need to investigate something outside your current codebase, Scout can be useful.

Creating Your Own Agent in OpenCode

You can also create your own agents in OpenCode.

Agents can be defined using JSON in opencode.json or using Markdown files.

For global agents, you can place them under:

~/.config/opencode/agents/

For project-specific agents, you can use:

.opencode/agents/

For example, let's create a copywriter.md agent:

---
description: Writes clear, engaging, and audience-focused copy
mode: subagent
model: anthropic/claude-sonnet-4-20250514
temperature: 0.7
permission:
  edit: deny
  bash: deny
---

You are in copywriting mode. Focus on:

- Clear and engaging writing
- Matching the tone to the target audience
- Strong messaging and compelling language
- Concise structure and readability
- Preserving the intended meaning and voice

Produce polished, ready-to-use copy without making direct changes.

This creates a specialized copywriting agent.

You can then invoke it using:

@copywriter

The filename becomes the agent name, so copywriter.md becomes @copywriter.

This is where things start getting interesting.

Instead of repeatedly explaining to the main agent how you want a particular task to be handled, you can create a specialized agent with its own instructions, model, temperature, and permissions.

Wrapping Up

So that's it for agents in OpenCode.

We looked at:

Primary agents
Build and Plan modes
Subagents
The built-in General, Explore, and Scout agents
Creating your own custom agents

There are several other features in OpenCode that are worth exploring.

The more we understand these features, the more we can customize OpenCode around our own workflow.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

Common Multi-Agent Architectures Every AI Developer Should Know

Rijul Rajesh — Thu, 06 Aug 2026 22:39:16 +0000

We often hear terms like AI agents and Agentic AI, but they're usually discussed in the singular, as if one agent is responsible for everything.

You can think of an AI agent like a person. An individual can accomplish impressive tasks on their own, but a team of people with different skills can solve much larger and more complex problems. The same idea applies to AI agents.

Instead of relying on a single agent, a multi-agent system brings together multiple specialized agents that collaborate toward a shared goal. One agent might research, another might write code, while another reviews the final output. By dividing responsibilities, the system becomes more capable, scalable, and easier to maintain.

Why Use Multiple Agents?

A single agent has to plan, reason, use tools, and generate the final response. As tasks become more complex, this quickly becomes difficult to manage.

By splitting work across multiple specialized agents, each one focuses on a specific responsibility. This makes the overall system easier to extend, maintain, and scale.

Common Architectures

Manager-Worker

Think of an engineering manager leading a team. The manager doesn't write every line of code. Instead, they understand the requirements, assign work to the right people, and combine the results.

A manager-worker architecture follows the same idea. A manager agent delegates tasks to specialized worker agents, each responsible for a specific job, before assembling the final response.

Sequential Pipeline

Imagine an assembly line in a factory. A product moves along a conveyor belt, with each station adding something before passing it to the next.

A sequential pipeline works the same way. Each agent performs one step of the workflow and hands its output to the next agent until the task is complete.

Research → Analysis → Writing → Review

Parallel Workers

Not every task depends on another. When work is independent, teams often tackle it simultaneously to save time.

Parallel worker architectures follow the same principle. Multiple agents work on different parts of a problem at the same time, and their outputs are merged once everyone finishes.

Debate

Think about an engineering design discussion. Multiple engineers propose different approaches, challenge each other's ideas, and eventually arrive at the best solution.

A debate architecture works similarly. Multiple agents generate different answers, critique each other's reasoning, and together refine the strongest response before presenting it to the user.

Shared Memory

For agents to collaborate effectively, they often need access to the same information.

Instead of every agent maintaining its own copy of data, they can read from and write to a shared memory.

This keeps every agent working with the same context and avoids duplicated information.

Routing

Not every request needs every agent.

A router decides which agent is best suited for a task and forwards the request accordingly.

User
 │
 ▼
Router
 ├── Math Agent
 ├── Search Agent
 └── Writing Agent

This reduces unnecessary work, lowers cost, and improves response time.

When Should You Use Multi-Agent Systems?

Multi-agent systems are a good fit when:

A problem can be divided into specialized responsibilities.
Different agents need access to different tools or data.
Tasks can run in parallel.
You want one or more agents to validate or review another agent's work.

For simpler applications, however, a single well-designed agent is often faster, cheaper, and easier to maintain.

As with any software architecture, the goal isn't to use more agents. It's to use the right number of agents for the problem you're solving.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

Before You Build an AI Agent, Know These Three Agentic Frameworks

Rijul Rajesh — Mon, 03 Aug 2026 21:47:33 +0000

Back in the day, when someone mentioned the word framework, it usually referred to developer-oriented frameworks like React, Next.js, Angular, or Django.

Today, that term has expanded.

When people talk about frameworks in AI, they are often referring to agentic frameworks as well.

If you're not familiar with agentic frameworks, let's first understand what they are.

What Is an Agentic Framework?

Just like React is a framework for building web applications, agentic frameworks are software toolkits and libraries that help developers build autonomous AI agents.

These agents can pursue goals, reason, plan, and perform tasks with minimal human intervention.

You can think of an agentic framework as the middle layer between an LLM and a production-ready AI system.

The LLM generates responses.

The agentic framework turns that model into something that can repeatedly reason, take actions, observe results, and continue until a goal is achieved.

Traditional generative AI is reactive.

You give it a prompt, it generates a response, and the interaction ends.

Agentic AI is goal-driven.

An agent can:

Receive a high-level goal (for example, "Research this topic and write a report")
Break it into smaller tasks
Decide which tools or APIs to call
Observe the results
Adjust its plan if necessary
Continue until the goal is completed

Common Capabilities of Agentic Frameworks

Most agentic frameworks provide these capabilities out of the box.

Capability	Why it matters
Orchestration	Controls the flow of reasoning and actions, turning one-shot prompts into multi-step workflows.
Tool Integration	Lets agents call APIs, databases, browsers, code interpreters, and more.
Memory / State	Maintains short-term context and long-term memory across tasks.
Planning & Reflection	Helps agents break down tasks, recover from errors, and improve reliability.
Multi-Agent Support	Allows multiple specialized agents to collaborate on complex tasks.
Human-in-the-Loop	Lets humans review or approve actions before they are executed.
Observability	Provides logging, tracing, evaluation, and debugging for production systems.

Now that you have an idea of what agentic frameworks are, let's look at some of the major players.

Major Agentic Frameworks

Some of the most popular agentic frameworks today are:

LangChain + LangGraph
OpenAI Agents SDK
Google ADK

LangChain + LangGraph

LangChain is a broad framework for building LLM-powered applications.

LangGraph is the modern layer that extends LangChain into a production-grade agentic framework.

Core Model

You model your agent as a graph.

Nodes

Nodes represent units of work, such as:

LLM calls
Tool execution
Custom functions

Edges

Edges define the control flow between nodes.

State

A shared state object flows through the graph, allowing different nodes to exchange information.

OpenAI Agents SDK

The OpenAI Agents SDK is a lightweight, production-oriented SDK from OpenAI, available in both Python and TypeScript.

It is the successor to OpenAI's earlier experimental Swarm project.

Core Model

An Agent is an LLM configured with instructions, tools, and optional guardrails.
Handoffs allow one agent to transfer control to another specialized agent.
A built-in agent loop continues until the task is completed.
Support for sandboxed agents.

Google ADK (Agent Development Kit)

Google ADK is Google's open-source, code-first framework for building production AI agents.

It is model-agnostic and deployment-agnostic, but is optimized for Gemini models and the Google Cloud ecosystem.

Core Model

LLM agents for reasoning and dynamic decision-making.
Workflow agents for deterministic execution.

Workflow agents include:

SequentialAgent
ParallelAgent
LoopAgent

Wrapping Up

These are some of the major agentic frameworks available today.

As a simple guideline:

Need maximum control, long-running agents, or complex graphs? → LangGraph
Want a clean developer experience, especially with OpenAI models? → OpenAI Agents SDK
Building on Google Cloud or working with Gemini models? → Google ADK

Each framework has its own strengths, so the right choice depends on the kind of AI agent you're building.

That's it for this article, see you on the next one.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

AI Agents Are Not Magic. They Are Just Good Feedback Loops

Rijul Rajesh — Tue, 28 Jul 2026 18:35:54 +0000

Past few years, when things like GPT came out, we were mainly learning how to use them.

Which basically meant using better prompts.

So we were continuously refining prompts and trying to get better outputs.

And that is fine.

This was basically an exchange back and forth between us and the bot.

We ask something.

The AI responds.

We refine our prompt.

The AI responds again.

This loop continues.

Agents coming into the picture

But now we are seeing the rise of AI agents.

We see them everywhere, in every LinkedIn post, every YouTube video.

The main idea behind agents is to hand over our work to them, and they will handle the remaining tasks with less constant back and forth compared to traditional chatbots.

Here, agents are expected to work in loops.

They do one thing.

Then they review the result, identify additional things that need to be done, take action again, and repeat.

The main input we give is usually a goal or a prompt.

But this alone will not give us better control over how the agent works.

Reliable agents also need things like success criteria, access to the right tools, feedback mechanisms, and rules for when to stop or ask for human input.

The agent works in loops.

So we need a better way to design and control these loops.

Introducing Loop Engineering

Agents perform tasks through loops.

So instead of only focusing on prompt engineering, we also need to engineer the loop in which the agent operates.

This is where Loop Engineering comes in.

The term has recently gained attention as people started exploring better ways to build reliable workflows around AI agents.

The idea is simple:

Instead of only telling an agent what to do, we design the process that helps the agent complete the task reliably.

Prompting is still an important part of this process.

But it becomes one layer in a bigger system that includes actions, feedback, memory, verification, and stopping conditions.

The 3 pillars of Loop Engineering

There are many ways to think about designing agent loops.

A simple way to understand them is through three important parts:

Actions
Feedback
Stop conditions

Actions

Actions are anything that an agent needs to perform.

Take us humans as an example.

When we build software, we write code, read code, interact with files, create new files, run commands, and test our changes.

These are actions.

Similarly, for an agent, actions are the things it can perform using its available tools.

Examples:

Reading files
Writing code
Running tests
Calling APIs
Searching information

Without actions, an agent has limited ability to interact with the world and becomes closer to a traditional chatbot.

Feedback

Just performing actions is not enough.

As humans, we don't just complete a task and assume it is correct.

We verify our work and look for feedback.

The same applies to agents.

Feedback helps the agent understand whether the task is completed or whether more iterations are required.

For example, a coding agent might:

Make a code change
Run tests
Check if the issue is fixed
Continue improving if something fails

The feedback helps decide what happens next in the loop.

Stop conditions

As developers, we stop working on a task once the feedback shows that everything is correct.

The same stopping mechanism is required for agents.

Without stop conditions, an agent can keep performing actions without knowing when the task is actually complete.

Examples:

Tests are passing
The expected output is achieved
Performance goals are reached
Human approval is received

A good loop knows when to continue and when to stop.

There are also other important parts of production-level agent loops, such as memory, state management, tool permissions, recovery strategies, and verification systems.

The exact design depends on the type of task the agent is solving.

Prompt Engineering vs Loop Engineering

Prompt Engineering	Loop Engineering
Focuses on improving instructions	Focuses on improving the entire workflow
One prompt gives one response	A goal creates multiple iterations
Human provides continuous feedback	Agent uses feedback from the environment
Controls what the AI says	Controls how the AI works

Example: Coding Agent

Suppose we are creating a coding agent.

If we simply tell it:

Fix this bug

It will look at the code, try to fix it, and probably say that the task is complete.

But what do we do as developers?

We don't just write code and stop.

We verify it.

We run tests.

We check if the issue is actually fixed.

We look for side effects.

So just prompting an agent is not enough.

We need to define the loop.

A normal prompt:

Fix this bug

A loop-based approach:

Find the bug
 ↓
Understand the code
 ↓
Create a fix
 ↓
Run tests
 ↓
Analyze failures
 ↓
Improve solution
 ↓
Repeat until tests pass

The difference is not just the prompt.

The difference is the process around the AI.

Wrapping up

As we see this AI space constantly evolving, we have only recently started seeing terms like Loop Engineering become popular.

But the important thing is understanding where the industry is moving.

AI is moving from simple chat-based interactions to systems that can take actions and complete tasks with less human intervention.

The next challenge is not only creating smarter models.

It is creating better systems around those models, where prompts, tools, memory, verification, and feedback loops work together.

And that is where concepts like Loop Engineering become important.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

Build Your Own Personal AI Agent That Works for You With Hermes

Rijul Rajesh — Sun, 26 Jul 2026 19:32:48 +0000

AI assistants can remember things about you now.

But what if you wanted to run your own personal AI agent that acts as your assistant across different parts of your life?

One that can:

Access your environment
Use tools
Remember the things you want it to remember
Continue working beyond a single chat window

For that, I want to introduce you to Hermes Agent.

What Is Hermes Agent?

Hermes Agent is an open-source personal AI agent developed by Nous Research.

At its core, it is a program that connects a language model to an environment where it can actually perform tasks.

You give Hermes a task.

Hermes sends that task to an AI model, receives the model's decisions, and then gives the model access to tools that can perform actions in the real world.

This makes it more than just a chatbot.

It is also different from traditional coding agents.

Coding agents are primarily designed to work on software projects.

Hermes is designed to act more like a personal AI assistant.

You can use it for tasks such as:

Research this topic.

Check my server.

Fix this code.

Search my previous conversations.

Run this workflow every morning.

Message me on Telegram when it's done.

The idea is to have an AI agent that can work across different areas instead of being limited to a single coding environment.

Now let's see how quickly we can set it up.

Setting Up Hermes Agent

You can find the repository here:

https://github.com/nousresearch/hermes-agent

The installation instructions are available in the README.

For this article, I'll demonstrate the Linux installation.

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Once the installation is complete the setup wizard is launched, where you can configure the agent.

Once the setup is complete, we can start Hermes:

hermes

Hermes Agent in Action

Now let's try a simple example.

I'll give Hermes a workflow that I regularly follow when publishing technical articles.

I regularly publish technical articles.

When I finish an article, my usual workflow is:

1. Check the article structure
2. Create a thumbnail
3. Create a short LinkedIn post

Remember this workflow.

At this point, Hermes has been told about my workflow.

Now I'll close Hermes.

Later, I start it again and ask:

I just finished an article.

What should I do next?

Hermes is able to retrieve the workflow I previously told it about and suggest the next steps.

It even offers to help me with those steps.

This is the interesting part.

The memory belongs to an agent that I can run myself.

It is not limited to a single chat session.

I can run the agent, give it information, close it, and return later.

The agent can then use the information I previously asked it to remember.

That starts to feel much more like a personal assistant than a traditional chatbot.

More Than Just Memory

Memory is only one part of Hermes Agent.

It also supports various connectors and tools that allow the agent to interact with different systems.

This means you can potentially build workflows around things like:

Your local environment
Servers
Messaging platforms
Research
Scheduled tasks
Other external services

I'll cover some of those connectors in a separate article.

For now, the main idea is simple:

You can run your own personal AI agent, give it access to tools, teach it your workflows, and allow it to remember information across sessions.

That's it for this introduction to Hermes Agent.

Thanks for reading. I'd love to hear your thoughts in the comments.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

Your AI Agent Has a Backpack. It's Called Retrieval Memory.

Rijul Rajesh — Sat, 25 Jul 2026 20:40:54 +0000

Imagine your AI agent has a backpack.

It stores your preferences, project details, past experiences, and procedures.

But it doesn't carry everything in that backpack into every conversation. When something becomes relevant, it reaches in and retrieves what it needs.

This is the basic idea behind retrieval memory.

The Context Problem

When you interact with an AI agent, it has a limited context window.

As the conversation continues, more information gets added to that context.

Eventually, the context can become full.

At that point, the system may need to:

Start a new session
Compress the existing context
Remove information that is no longer relevant

But there is another way to prevent the context from becoming unnecessarily large.

Instead of keeping every piece of information inside the active context, the system can store information externally and retrieve it only when it is needed.

This is the basic idea behind retrieval memory.

What Is Retrieval Memory?

Retrieval memory is a way for an AI system to remember information by storing it externally and retrieving the relevant parts when needed.

The basic flow looks like this:

User asks something
       ↓
Search stored memory
       ↓
Retrieve relevant information
       ↓
Add it to the AI's context
       ↓
Generate a response

The important idea is that the information does not need to remain inside the active context all the time.

It can be stored somewhere else and brought back when it becomes relevant.

A Simple Example

Suppose I tell an AI assistant:

My favourite programming language is Rust.

The system might store this as:

User preference:
Favourite programming language = Rust

Later, I ask:

Suggest a programming language for my next project.

The system can then:

Search its stored memories.
Retrieve the fact that I prefer Rust.
Add that information to the current context.
Use it when generating the response.

The AI might then suggest Rust, or at least consider it as one of the options.

The important point is that the preference did not need to remain in the active context between the two conversations.

It was stored externally and retrieved when relevant.

That is retrieval memory.

The memory is not directly inside the model. It is retrieved into the context when relevant.

How Is This Different From RAG?

Retrieval memory is similar to RAG, or Retrieval-Augmented Generation.

The basic process is similar:

Query
  ↓
Retrieve relevant information
  ↓
Add it to the context
  ↓
Generate a response

The main difference is usually the source of the information.

With traditional RAG, the system might retrieve information from:

Documentation
PDFs
Websites
Knowledge bases
Company documents

With retrieval memory, the system usually retrieves information specific to:

A particular user
A particular agent
A previous interaction
A project
A specific workflow

So the source is often personal or agent-specific memory, rather than a general document collection.

What Kind of Information Can Be Retrieved?

Retrieval memory can contain many different types of information.

User Preferences

The user prefers the Fetch API over Axios.

Facts

The user is working on Project X.

Past Experiences

This approach failed previously because the API rate limit was exceeded.

Procedures

When deploying this project, run these commands in this order.

Conversation Summaries

The previous discussion concluded that the system should use PostgreSQL instead of SQLite.

The system can then retrieve the relevant information when it becomes useful.

The Big Idea

Retrieval memory allows an AI agent to separate storage from active context.

Instead of keeping every piece of information in the context window all the time:

Store information externally
            ↓
User asks a question
            ↓
Search stored memory
            ↓
Retrieve what is relevant
            ↓
Add it to the current context

This helps the agent access information from previous interactions without carrying the entire history into every new conversation.

So when you see terms like semantic memory, episodic memory, or retrieval memory, they are describing different ways an AI system can store and use information.

Understanding these concepts makes it easier to understand how modern AI agents build memory systems that go beyond simply keeping a giant conversation history.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

Context Compression: Making AI Agents Forget Without Losing the Plot

Rijul Rajesh — Fri, 24 Jul 2026 20:09:52 +0000

Suppose you are working with an AI agent to fix an API.

You give it a simple instruction:

Fix the API 500 error.

The agent might go through a workflow like this:

Agent:
→ Reads the logs
→ Searches the codebase
→ Checks the database
→ Checks recent commits
→ Runs tests
→ Tries a fix

After 30 tool calls, the agent's context can become huge.

But most of that information may no longer be useful.

The agent does not need to keep every detail of the investigation forever.

It does not need:

Every line from every log
Every failed search
Repeated information
Old tool outputs
Intermediate steps that are no longer relevant

What it really needs is the current state of the investigation.

The Context Problem

Imagine the agent has accumulated 40,000 tokens of context during the investigation.

That context takes up valuable space.

As the agent continues working, the context window gradually fills up.

Eventually, the agent may have less room for new information, which can lead to:

Higher costs
Slower processing
Less room for future tool calls
Important information being pushed out of context

So instead of carrying the entire history forward, we can compress it.

The original 40,000 tokens might become:

Goal:
Fix the API 500 error.

Found:
The error started after deployment v1.4.
The database is healthy.
The payment service is missing PAYMENT_API_KEY.

Tried:
Restarting the service. No effect.

Next:
Fix the environment configuration and retest.

This is context compression.

What Is Context Compression?

Context compression is not simply about making the context shorter.

The goal is to:

Remove the information that is no longer useful while preserving what the agent needs to continue working.

The agent does not need to remember every step it took.

It needs to remember the important conclusions from those steps.

Three Basic Context Compression Techniques

1. Pruning

The simplest technique is pruning.

You remove information that is no longer useful.

For example:

Agent:
→ Searched for config.yaml
→ Found nothing

Agent:
→ Searched for settings.yaml
→ Found nothing

Agent:
→ Searched environment variables
→ Found PAYMENT_API_KEY is missing

Once the agent has found the actual cause, the failed searches may no longer be useful.

They can be removed from the active context.

The important information is:

PAYMENT_API_KEY is missing.

Pruning is essentially:

Remove what the agent no longer needs.

2. Distillation

Instead of keeping the entire conversation, we can convert it into a structured summary.

For example:

Goal:
Fix the API 500 error.

Facts:
- The database is healthy.
- The error started after deployment v1.4.
- PAYMENT_API_KEY is missing.

Decisions:
- Do not modify the database.
- Fix the environment configuration.

Completed:
- Checked the logs.
- Verified database connectivity.
- Inspected environment variables.

Next Action:
- Add PAYMENT_API_KEY.
- Restart the service.
- Retest the API.

The original investigation may have taken thousands of tokens.

But the distilled state contains the information the agent needs to continue.

A useful structure might be:

Goal
Facts
Decisions
Completed Work
Next Action

Distillation is essentially:

Turn a long history into a structured state.

3. Generalisation

Sometimes an investigation contains knowledge that can be reused in future situations.

For example:

Specific experience:

Missing API key caused the payment API to fail.
              ↓
Reusable knowledge:

Check environment variables when an API integration fails.

The agent is no longer just remembering what happened in one specific incident.

It is extracting a general rule from that experience.

This can be useful for:

Future investigations
Runbooks
Agent skills
Long-term memory

Generalisation is essentially:

Turn a specific experience into reusable knowledge.

The Big Idea

An AI agent does not need to carry its entire history forever.

It needs to preserve the parts of that history that are still useful.

A long investigation might look like this:

40,000 tokens of raw history
              ↓
       Context compression
              ↓
      Goal + Facts + Decisions
              ↓
          Next Action

The agent can then continue working with a much smaller context while retaining the information that actually matters.

Context compression is not about forgetting everything.

It is about forgetting the right things.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

AI Runbooks Explained: How to Give AI Agents Procedures to Follow

Rijul Rajesh — Tue, 21 Jul 2026 19:59:48 +0000

If you have read about AI agents, you may have come across the term AI runbook.

You may also have seen people confidently talk about agents handling routine tasks, running commands, investigating issues, and performing actions much like a human engineer would.

But there is an important distinction here:

Just because an agent can use tools does not mean it knows what to do or what procedure to follow.

Think about the difference between an experienced engineer and a new employee joining a team.

An experienced engineer may already know the team's standard procedures.

A new employee might have the technical ability to do the work, but still needs to learn:

What to check first
Which tools to use
What actions to avoid
How the team normally handles a particular situation

AI agents are similar.

Suppose you tell an agent:

The API is broken. Fix it.

The agent might start investigating broadly.

It could check different files, inspect various configurations, run multiple commands, and try several approaches before figuring out what is actually wrong.

This can lead to:

Wasted time
Wasted tokens
Unnecessary tool calls
More iterations than necessary

But what if we already had a standard procedure for handling this particular problem?

The agent could follow that procedure and focus its investigation.

That is where AI runbooks come in.

What Is an AI Runbook?

A runbook is simply a documented procedure for handling a specific situation.

For example, suppose an API starts returning HTTP 500 errors.

A runbook might say:

The API is returning 500 errors.

1. Check if the API is running.
2. Inspect the logs.
3. Check the database configuration.
4. Verify that the database is accessible.
5. Make the smallest necessary fix.
6. Verify that the API is working again.

This gives the agent a procedure to follow.

The agent still has to perform the investigation and use its tools.

The runbook simply provides a structure for that investigation.

A Small AI Runbook Demo

To demonstrate this, I created a small task management API using FastAPI and SQLite.

You can also try the demo yourself through my repository

The project contains a runbook for handling API failures:

runbooks/
└── api-500-error.md

Now let's look at the scenario.

First, I start the server.

The API is working correctly.

Next, I intentionally break the application by changing the database path from:

./data/app.db

to:

./data1/app.db

Now, when I call the health endpoint, the API returns an error.

At this point, I ask my AI agent to investigate the issue.

The API is returning HTTP 500 errors.

Please check whether there is a relevant runbook in the runbooks/ directory and follow it.

Diagnose the root cause, make the smallest safe fix, and verify that the API is working again.

Instead of immediately changing application code, the agent can follow the procedure defined in the runbook:

Find the relevant runbook.
Check the API.
Inspect the logs.
Check the database configuration.
Identify the incorrect database path.
Fix the configuration.
Verify that the API is healthy again.

The agent still performs the investigation.

The runbook simply gives that investigation a structure.

In this case, the agent finds the root cause and applies the fix.

Prompt vs Runbook

Compare these two instructions.

A simple prompt might say:

Fix the API.

A runbook provides something more specific:

When the API returns a 500 error, check these things in this order.

Avoid making unnecessary changes.

After applying a fix, verify that the API is working again.

The difference is important.

With a simple prompt, the agent has to figure out the entire process by itself.

With a runbook, the agent gets procedural knowledge.

It knows:

What to check
In what order to check it
What actions to take
What actions to avoid
How to verify the result

This makes the agent's behavior more predictable.

The Big Idea

AI agents already have the ability to use tools.

They can:

Read files
Run commands
Inspect logs
Modify code
Call APIs

But tools only provide capabilities.

A runbook provides a procedure.

That is the key idea behind AI runbooks.

You are not just telling the agent:

Here are some tools. Figure it out.

You are giving it:

Here is how this team normally handles this situation. Follow these steps, use your judgment where necessary, and verify the result when you are done.

That is how you give an AI agent procedural knowledge.

And in many cases, that can lead to a much more predictable outcome than simply giving an agent a vague instruction and hoping it figures out the best approach.

That's it for this introduction to AI runbooks.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

Semantic Memory: How AI Builds Knowledge About You

Rijul Rajesh — Mon, 20 Jul 2026 20:40:07 +0000

When building personal AI systems, one of the most important types of memory to understand is semantic memory.

In simple terms, semantic memory is a structured store of knowledge such as:

Facts
Concepts
Preferences
Relationships

It is the part of an AI memory system that helps answer:

"What do I know about this person, project, company, or concept?"

Episodic Memory vs Semantic Memory

Let's say the following conversation happens:

User: I usually use React and TypeScript for frontend projects.

AI: Got it.

This single conversation can be stored in two very different ways.

Episodic Memory

Episodic memory stores the event itself.

On July 21, 2026, the user said:

"I usually use React and TypeScript for frontend projects."

The system remembers:

What happened, when it happened, and what was said.

This is similar to remembering an experience.

Semantic Memory

Semantic memory extracts the knowledge from that conversation.

User
├── frontend_framework → React
└── primary_language → TypeScript

The system no longer needs to remember the original conversation to understand the underlying information.

It has converted the conversation into structured knowledge.

This is the key difference:

Episodic memory remembers the event.

Semantic memory remembers what was learned from the event.

Semantic Memory as a Knowledge Layer

You can think of semantic memory as a knowledge layer for an AI system.

For example, an AI assistant might maintain a structured representation of a user like this:

User
├── prefers → React
├── uses → TypeScript
├── prefers → Linux
├── works_on → E-commerce platform
├── interested_in → AI agents
└── prefers → concise technical explanations

This is semantic memory.

The information is no longer stored as a conversation.

Instead, it is stored as knowledge about entities and the relationships between them.

What Are Entities?

An entity is something that the AI system knows about.

Examples include:

User
Customer
Company
Product
Project
Document
Location
Organization

For example:

User ──works_on──> E-commerce platform

Here:

User is an entity
E-commerce platform is an entity
works_on is the relationship between them

This structure allows an AI system to reason about information instead of simply searching through old conversations.

Why Does This Matter?

Imagine an AI assistant that has stored hundreds of conversations with you.

If it only has episodic memory, it may need to search through those conversations every time it wants to answer a question about your preferences or projects.

With semantic memory, it can directly access structured knowledge such as:

User
├── uses → React
├── uses → TypeScript
├── works_on → E-commerce platform
└── interested_in → AI agents

The assistant does not need to reread every conversation to discover these facts.

The knowledge has already been extracted and organized.

That is what makes semantic memory such an important part of personal AI systems.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github