DEV Community: Sunil Prakash

The State of Memory in Java AI Agents (April 2026)

Sunil Prakash — Tue, 07 Apr 2026 17:12:08 +0000

This post was originally published on jamjet.dev.

TL;DR

If you're building AI agents in Java today, your options for persistent memory range from "store the last 20 chat messages in Postgres" to "run a Python service in a sidecar container and call it over HTTP." There is no Java-native equivalent to Mem0, Zep, or Letta — the libraries Python developers reach for when they need real memory.

This post is a tour of every option a Java developer has in April 2026, why most of them stop at chat history, what "real memory" should actually mean, and one library we shipped to fill the gap.

The scenario every Java AI developer recognises

You're building an AI agent in Spring Boot. Maybe it's a customer support copilot, maybe it's a coding assistant, maybe it's a research agent. You wire up Spring AI or LangChain4j, write a few tools, and the first conversation works.

Then your user comes back the next day. The agent doesn't remember them. It doesn't remember they're allergic to peanuts. It doesn't remember they're working on the Acme migration. It doesn't remember they prefer verbose explanations. Every conversation starts from zero.

You search for "Java AI agent memory" and end up with three kinds of results:

Tutorials on how to store chat messages in Postgres
Marketing pages for Mem0 and Zep — Python only
GitHub issues asking why there's no Java SDK

This is the gap.

"Memory" means three different things

Before we tour the libraries, we need to be precise. There are at least three different things people mean when they say "agent memory":

1. Conversation history. The last N messages of the current session. Solved problem — every framework ships this.

2. State checkpointing. Snapshots of agent execution state for resume and replay. Solved by LangGraph, Koog persistence, Temporal-style runtimes.

3. Long-term knowledge memory. Facts about the user, their preferences, their projects, their history — extracted from conversations, stored durably, retrievable across sessions, and de-conflicted when they change. This is what Mem0 and Zep do. It is not solved on the JVM.

The rest of this post is about the third one.

What real memory needs

Fact extraction. An LLM reads a conversation and pulls out discrete, atomic facts.
Conflict detection. When a new fact contradicts an old one, the system invalidates the old fact.
Hybrid retrieval. Vector + keyword + graph walk fused together.
Temporal reasoning. Facts have validity windows.
Token-budgeted context assembly. Pick which facts go in the prompt and respect the budget.
Decay and consolidation. Stale facts fade, frequent facts get promoted, duplicates merge.

Tour: every option Java developers have today

LangChain4j ChatMemory

Most popular JVM AI framework. Ships ChatMemory interface with MessageWindowChatMemory and TokenWindowChatMemory. Persistence via developer-implemented ChatMemoryStore.

What it does: stores message objects, respects token/count limits. What it does not do: extract facts, deduplicate, retrieve semantically, reason about time. The docs are explicit — ChatMemory is a container abstraction.

Spring AI ChatMemory

Shipped GA in 2025 with broad backend support: JDBC, Cassandra, Mongo, Neo4j, Cosmos DB. Three advisors plug it into ChatClient.

The VectorStoreChatMemoryAdvisor is the closest thing to "semantic memory" — it indexes raw messages in your VectorStore. But it indexes raw messages, not extracted facts. No entity model, no relationship graph, no conflict detection.

Google ADK for Java

Ships 1.0.0 with two memory implementations: InMemoryMemoryService (keyword matching only) and VertexAiMemoryBankService (Vertex AI only). Memory Bank is excellent but Google Cloud-locked.

Koog (JetBrains)

Kotlin-first framework with AgentMemory storing facts by Concept, Subject, Scope. Closest competitor on the "facts about subjects" axis.

Two caveats: Java consumption is awkward, and GitHub issue JetBrains/koog#1001 documents that AgentMemory floods prompts as facts accumulate — no token budgeting.

Embabel

Rod Johnson's JVM agent framework. Uses a blackboard pattern — shared state per agent run.

Per the maintainers: "in Embabel it's not about conversational memory so much as domain objects that are stored in the blackboard during the flow." Long-term memory is an explicit non-goal.

Mem0 Java SDK (the one that doesn't exist)

The top Google result is me.pgthinker:mem0-client-java, a community wrapper at version 0.1.3, last updated nine months ago, with 9 GitHub stars. It's a thin REST client requiring a Python Mem0 server alongside your JVM app.

No official Mem0 Java client exists. Python and Node.js only.

Zep Java SDK (also doesn't exist)

Zep's official clients are Python, TypeScript, and Go. No Java SDK.

DIY (what most teams actually do)

When Java teams need real memory today, they assemble:

Postgres + pgvector (or Qdrant) for embeddings
JdbcChatMemoryRepository for messages
Custom advisor that calls an LLM to extract facts
Custom retrieval layer combining vector and keyword search
Nightly cron job for decay and dedup
Custom token-budgeting in the prompt builder

Roughly 1,500–3,000 lines of bespoke Java per team. Quietly diverges between projects. Rarely gets temporal reasoning right. Almost never gets consolidation right.

The pattern

Every Java memory option lives in one of two boxes:

Chat history persistence (LangChain4j, Spring AI core, Embabel)
State checkpointing (LangGraph4j, Koog persistence)

Nothing in between. No JVM-native library that does fact extraction + conflict resolution + temporal graph + hybrid retrieval + consolidation in one dependency.

The Python ecosystem has had Mem0 since 2024 and Zep/Graphiti since early 2025. The Java ecosystem is roughly 18 months behind.

What we built

I run JamJet. As we built our agent runtime, the memory gap kept showing up. So we built a memory layer.

Engram is a durable memory system that does the things on the list:

Fact extraction from conversation messages via LLM
Conflict detection — vector similarity threshold plus LLM resolution
Hybrid retrieval — vector + SQLite FTS5 keyword + graph walk
Temporal knowledge graph with validity windows
Token-budgeted context assembly with three output formats
5-operation consolidation engine: decay, promote, dedup, summarize, reflect
MCP server option

Runs against SQLite by default. No Postgres, no Qdrant, no Neo4j, no Python sidecar.

import dev.jamjet.engram.EngramClient;
import dev.jamjet.engram.EngramConfig;

import java.util.List;
import java.util.Map;

try (var memory = new EngramClient(EngramConfig.defaults())) {
    memory.add(
        List.of(
            Map.of("role", "user",      "content", "I'm allergic to peanuts and live in Austin"),
            Map.of("role", "assistant", "content", "Got it, I'll remember that.")
        ),
        "alice", null, null
    );

    var context = memory.context(
        "what should I cook for dinner",
        "alice", null, 1000, "system_prompt"
    );

    System.out.println(context.get("text"));
}

Maven Central:

<dependency>
    <groupId>dev.jamjet</groupId>
    <artifactId>jamjet-sdk</artifactId>
    <version>0.4.3</version>
</dependency>

Apache 2.0. Rust runtime published as jamjet-engram on crates.io.

What it doesn't do (yet)

No Spring Boot auto-configuration yet (starter on roadmap)
No JDBC backend (SQLite-first, Postgres in 0.5.x)
No managed cloud option
No published LongMemEval / DMR scores yet (benchmarks running, not going to cherry-pick)

Try it

<dependency>
    <groupId>dev.jamjet</groupId>
    <artifactId>jamjet-sdk</artifactId>
    <version>0.4.3</version>
</dependency>

Or run it as an MCP server:

cargo install jamjet-engram-server
engram serve --db memory.db

GitHub: github.com/jamjet-labs/jamjet

If you've been quietly rolling your own memory layer in Java, I'd love to hear what you ended up with. Reach out via GitHub issues or the comments below.

Introducing Agentic AI for Serious Engineers: A Free Practical Book + Code Repo

Sunil Prakash — Fri, 27 Mar 2026 04:33:12 +0000

Agentic AI is moving fast.

There are new frameworks, new demos, new orchestration patterns, and new opinions almost every week. That is exciting, but it also creates a problem for engineers trying to build real systems.

A lot of the material online is either too abstract, too framework-specific, too hype-heavy, or too focused on demo magic instead of production reality.

I wanted something different.

So I started writing Agentic AI for Serious Engineers - a free practical book and code repo for engineers who want to build agent systems that are not just impressive in a demo, but usable, testable, observable, and trustworthy in real environments.

Why I wrote it

I kept running into the same gap.

There is plenty of excitement around agents, but much less practical material on questions like:

What actually makes a system agentic?
When should you use an agent instead of a workflow?
How should tools be designed so they are safe and reliable to call?
What does good context design look like?
How do you evaluate an agent system beyond “it seemed to work”?
Where should human approval sit in the architecture?
How do you think about reliability, security, and observability from the start?

Those are the questions this book tries to answer.

Who this is for

This book is for engineers and architects building real AI systems:

backend engineers
platform engineers
staff+ engineers
software architects
technical leads
data engineers working on production AI applications

It assumes you already understand software systems.

It does not assume you already know how to design agent systems well.

What makes it different

This project is intentionally practical.

It is not a catalog of trendy frameworks.
It is not a collection of magical claims.
It is not “plug in this library and everything works.”

Instead, it focuses on the engineering questions that matter when systems move closer to production:

tool contracts
control flow
context boundaries
evaluation
approval gates
reliability
hardening
traceability
operating tradeoffs

The goal is not just to help someone build an agent.

The goal is to help them build one with better judgment.

What’s inside

The repo currently includes:

7 chapters
2 threaded end-to-end projects
per-chapter code
tests and eval-oriented structure
diagrams, principles, and roadmap
a free online version of the book

Some of the topics include:

what “agentic” actually means
tools, context, and the agent loop
workflow-first design
multi-agent systems
human-in-the-loop architecture
evaluating and hardening agents
when not to use agents

The kind of engineer I wrote this for

I wrote this for the engineer who looks at agentic AI and thinks:

This is interesting.

But how do I build it in a way I can actually trust?

That is the center of gravity of the book.

Not anti-agent.

Not pro-hype.

Just serious about engineering.

Read it free

You can read the book and explore the code here:

[https://github.com/sunilp/agentic-ai]

If you end up reading it, I’d genuinely love feedback on:

what feels most useful
what is still unclear
what you’d want covered more deeply

I’m continuing to improve it, and I’d love for it to become a genuinely useful resource for engineers building the next generation of AI systems.

Your AI CLI Writes Code. Mine Tells You What It'll Break.

Sunil Prakash — Sun, 22 Mar 2026 15:18:05 +0000

AI CLI tools are everywhere right now. Claude Code, Gemini CLI, GitHub Copilot in the terminal — they'll write your code, refactor your modules, even run your tests.

But ask any of them: "If I rename this function, what breaks?"

They'll scan the files they can see, make their best guess, and probably miss the SQL view that reads the column you're about to change. Or the Java batch job that calls your Python function through a stored procedure. Or the dbt model downstream of the table your migration is about to alter.

That's not a knock on AI. It's just not what LLMs are built for. Dependency analysis needs deterministic static analysis, not probabilistic text generation.

The gap in every AI CLI

Here's what I noticed building with these tools: they're incredible at writing code but terrible at understanding what already depends on it.

Ask Claude Code to "add retry logic to the HTTP client" — brilliant. Ask it "what will break if I change the response shape of getUser" — it'll read a few files and give you a confident answer that misses half the callers.

That's because LLMs work with whatever fits in context. Your codebase has thousands of files. The SQL stored procedure that calls your function through EXEC isn't in the context window.

Static analysis that crosses language boundaries

I built Jam to fill this gap. It's a developer CLI with 40+ commands, but the one that keeps saving me is jam trace --impact.

It uses tree-sitter to parse your entire workspace — TypeScript, Python, Java, and SQL — builds a SQLite index of every function, every call site, every import, and every SQL column reference. Then gives you a deterministic answer:

$ jam trace updateBalance --impact

Impact Analysis for updateBalance
───────────────────────────────────
Direct callers:
  PaymentService.processRefund()  [Java]
  BATCH_NIGHTLY_RECONCILE         [SQL]

Column dependents:
  VIEW v_customer_summary   (reads customer.balance)
  PROC_MONTHLY_STATEMENT    (reads customer.balance)

Risk: HIGH — 2 callers across 2 languages, 2 column dependents

No hallucination. No "I think these files might be affected." Two callers in two languages, two column dependents, risk level HIGH. Deterministic.

Why LLMs can't do this (yet)

Context window limits — Your 200-file Java project with SQL migrations doesn't fit in any context window. Static analysis indexes everything.
Cross-language boundaries — A Java class running EXEC update_user is calling a SQL stored procedure. LLMs see a string. Tree-sitter sees a cross-language call.
Column-level tracking — When a SQL view reads customer.balance, and your function writes to customer.balance, that's a dependency. No LLM tracks this.
Determinism — Ask an LLM the same question twice, get different answers. Ask jam trace twice, get the same graph. For impact analysis, you need guarantees, not guesses.

Not replacing AI — complementing it

Jam isn't anti-AI. It literally has AI built in — jam ask, jam go (agentic execution), jam commit (AI-powered commit messages), jam review. It works with Ollama, Copilot, OpenAI, Anthropic, and Groq.

But for the question "what breaks if I change this?" — AI is the wrong tool. You wouldn't ask ChatGPT to run your test suite. You shouldn't ask it to trace your dependency graph either.

The best workflow: use Claude Code or Gemini CLI to write the change, then use jam trace --impact to verify the blast radius before you ship.

# Trace any symbol's callers and callees
jam trace createProvider --depth 5

# Get the full impact report
jam trace updateBalance --impact

# Output as Mermaid diagram for docs
jam trace handleRequest --mermaid

# JSON for CI/automation
jam trace processPayment --impact --json

How it works

Tree-sitter parsing — Builds ASTs for TypeScript, Python, Java, SQL
Symbol extraction — Functions, classes, methods, imports, call sites
Cross-language detection — Java EXEC/CALL → SQL procedures. SQL column refs in SELECT/UPDATE/INSERT/DELETE
SQLite index — Local database, fast graph queries, incremental updates
Impact analysis — Walks the graph upstream, finds column dependents, calculates risk

The index rebuilds in seconds. No cloud. No API calls. Pure local static analysis.

Try it

npm install -g @sunilp-org/jam-cli
jam trace <any-function-name>
jam trace <any-function-name> --impact

No API key needed for trace — it's pure static analysis. The AI features (ask, go, commit, review) auto-detect your provider.

978 tests. MIT licensed. Works everywhere Node runs.

GitHub | Website | npm | VSCode Extension