In today’s newsletter:

• [Hands-On] Build a Research Assistant With Memory

• Coding Agents Need an Engineering Process

Reading time: 5 minutes.

[Hands-On] Build a Research Assistant With Memory

Say you've got a folder of research papers, an operations manual, and a stack of meeting transcripts, and the answer to today's question is buried somewhere in there. You don't have time to read all of it yourself, so you upload it to a chatbot and ask questions related to the documents.

A normal chatbot reads it once and answers immediately, no second look. If the documents don't actually contain the answer, it guesses anyway, and nothing checks that guess before it lands in your chat window. This project replaces that single guess with a research team:

• Planner agent plans the research

• Research agent gathers evidence from your documents stored in Actian VectorAI DB

• Writer agent composes the answer

• Critic agent grades it before you ever see it.

The system only answers from what you've actually given it, so a claim it can't back up in your documents doesn't get generated at all.

What We're Building

• An ingestion pipeline that chunks and embeds whatever you feed it, papers, manuals, transcripts, into a shared vector database.

• A four-agent LangGraph state machine that plans, retrieves, writes, and grades every answer against that database.

• And a Streamlit app on top, where you ask questions, watch the agents work, and manage the documents and memory underneath.

Tech Stack

• LangGraph for the four-agent state machine and revision loop

• Actian VectorAI DB as the shared memory layer, running in Docker

• Ollama running Gemma 4 E2B for generation, fully local

• sentence-transformers (BGE) for embeddings

• Streamlit for the UI

Prerequisites

• Python 3.10+ and uv

• Docker Desktop or Docker Engine, running

• Ollama installed, with gemma4:e2b pulled

How a Question Actually Moves Through the System

Say you've ingested your company's onboarding docs, a security policy PDF, and a couple of engineering runbooks, and you ask: "what's our process for rotating a leaked API key?" Here's what happens between typing that and getting an answer.

1. Planner reads the question and the conversation so far. It returns a JSON plan: what kind of question this is (a single document, a comparison, a synthesis, or a followup), one to four search queries, in this case something like "API key rotation procedure" and "leaked credential incident response", and whether to also check long-term memory

2. Research retrieves, but never reads a document directly. It only has tools: doc_search, get_section, memory_search. Every fact that ends up in the final answer has to trace back to a logged tool call, which is what makes the citations real instead of decorative

3. Writer drafts the answer from Research's notes alone, not from the question, not from what the model already knows. If the runbook and the security policy disagree on a step, the citations show you exactly which document said what

4. Critic grades the draft against the evidence it was given. Correctness, completeness, and clarity, each 1-5, plus a separate check for whether every claim is actually grounded in a retrieved passage

5. A failing grade sends it back, not forward. Say the Writer's answer skipped the step where you have to revoke the old key in your secrets manager, not just issue a new one. If the average score is below 3.5, or grounding fails, the graph routes back to Research with that specific gap attached. The second pass retrieves against it instead of repeating the first attempt. This can happen up to twice before the graph accepts the best effort it has

6. Only a passing answer gets remembered. If the Critic approves, the finding is embedded and written into a separate memory collection, so the next person who asks about key rotation benefits from this answer too. A rejected answer is never persisted

Research Talks to the Database

Planner and Writer never touch the database, and neither can open a raw document. Research is the only agent with that access, and its job is simple: turn each of the Planner's search queries into real evidence.

Every result comes back with a relevance score, and anything scoring below 0.30 gets thrown out as noise before Research even looks at it.

The Critic's Verdict

The Critic grades the Writer's answer on three things, correctness, completeness, and clarity, each on a 1 to 5 scale, plus a separate check for whether every claim actually traces back to the evidence Research found.

A low average, or a single ungrounded claim, is enough to fail the answer. That one pass-or-fail result is what the rest of the system runs on.

A failing grade sends the question back to Research with the Critic's specific complaint attached, up to twice, before the system gives up and keeps its best attempt. A passing grade moves on to the last step, which checks that same pass-or-fail result one more time before writing anything to the database.

If you skip this step, a rejected answer could still end up stored as a past finding, indistinguishable from one that was actually verified. The Critic's grade decides whether an answer gets a second try. This second check decides whether it ever reaches the database at all.

Run It

git clone https://github.com/Sumanth077/Hands-On-AI-Engineering.git
cd Hands-On-AI-Engineering/ai_agents/research_assistant_with_memory
cp .env.example .env

Start the vector database and make sure Ollama is running:

docker compose up -d
ollama serve

Install dependencies and ingest the sample documents:

uv sync
uv run python scripts/ingest_docs.py data/

Then launch the app:

uv run streamlit run app.py

Open http://localhost:8501. The sample data are two papers, a manual, and a transcript, enough to try real questions to test the agents.

Where This Fits Best

Nothing you ingest or ask ever leaves your machine. Actian VectorAI DB runs in your own Docker container, embeddings run through sentence-transformers, and generation runs through Ollama, so your documents and memory stay on hardware you control.

This makes internal documentation, compliance material, and unpublished research safe to index.

Full implementation on GitHub →

Coding Agents Need an Engineering Process

Chrome engineering lead Addy Osmani open-sourced Agent Skills, a pack of 24 skills that teach coding agents the workflows senior engineers follow.

The repo is currently trending on GitHub and has picked up over 75,000 stars since February. With one command, it installs into 70+ agents, including Claude Code, Cursor, Codex, and Copilot.

The problem it targets is process. Coding agents don't usually fail because they write bad code. They fail because they start building before the requirements are clear, treat tests as an afterthought, and merge without review.

The pack organizes everything around the development lifecycle, with 8 slash commands as entry points:

• /spec writes a PRD before any code exists

• /plan breaks the spec into small, atomic tasks

• /build implements one thin slice at a time

• /test enforces red-green-refactor, because tests are proof

• /review runs a five-axis quality check before merge

• /ship handles the path to production

Verification Gates

What separates this pack from a folder of prompts is enforcement. Each skill is a structured workflow with explicit steps, verification gates the agent has to pass, and anti-rationalization tables, which pre-empt the excuses a model generates to skip a step ("this change is too small to test").

That design shows up clearly in the autonomous mode. /build auto lets the agent implement every planned task in one approved pass, and it removes the human stepping between tasks, not the verification. Every task is still test-driven, still committed individually, and the run pauses on failures or risky steps.

The Skills Worth Reading First

A few skills stand out even if you never install the pack:

• interview-me: interrogates you one question at a time until it reaches roughly 95% confidence about what you actually want, instead of what you first asked for

• doubt-driven-development: runs an adversarial fresh-context review of every non-trivial decision while the work is in flight, for high-stakes or unfamiliar code

• context-engineering: covers feeding agents the right information at the right time, and when output quality drops, this is usually the fix

• source-driven-development: grounds framework decisions in official documentation and flags anything unverified

Each of these encodes a habit good engineers apply by instinct. Written down as a skill, the habit becomes something an agent applies every time instead of when it happens to remember.

Models will keep leapfrogging each other, and the code they write keeps getting better on its own. Process is the part that doesn't improve with the next model release. That's the part worth writing down.

Agent Skills On GitHub →

That’s all for today. Thank you for reading today’s edition. See you in the next issue with more AI Engineering insights.

PS: We curate this AI Engineering content for free, and your support means everything. If you find value in what you read, consider sharing it with a friend or two.

Your feedback is valuable: If there’s a topic you’re stuck on or curious about, reply to this email. We’re building this for you, and your feedback helps shape what we send.

WORK WITH US

Looking to promote your company, product, or service to 200K+ AI developers? Get in touch today by replying to this email.