Agent memory/state - Memory patterns

 External Storage — most common by far in production

Almost every production system uses this. User data, session history, preferences, task state — all of it needs to survive beyond a single session. In your Spring Boot world this maps directly to what you already know:

Redis      → short-lived session state, fast retrieval
PostgreSQL → long-term user history, structured data
MongoDB    → flexible document storage for conversation history

It's the default choice because production systems almost always need state to survive restarts, deploys, and user return visits.

---

No Persistent Memory — second most common

More common than people expect. A large category of production agents are pure task executors:

"Classify this ticket"          → stateless, done
"Summarize this document"       → stateless, done
"Convert this data to JSON"     → stateless, done
"Answer this one-off question"  → stateless, done

These don't need memory at all. Each request is fully self-contained. Zero overhead, zero complexity. For pipeline-style workloads this is the right default.

---

In-context Memory — situationally common

Used within a single session naturally — every chatbot does this by passing conversation history in the messages array. But as a deliberate persistence strategy it's limited to short sessions. In production it's rarely a standalone choice — it's always combined with external storage to handle the cross-session problem.

---

Summarized Memory — least common

Technically elegant but operationally complex. You need a reliable summarization prompt, you accept detail loss, and you add an extra API call at session boundaries. Most teams solve the same problem more simply by storing structured state in a database rather than summarizing free-form conversation. Used mainly in long-running conversational AI products — therapy bots, coaching assistants, companion apps — where the narrative continuity matters more than specific facts.

---

The typical production combination:

Most real systems don't pick just one — they layer them:

In-context memory     → within the current session (automatic)
     +
External storage      → user profile, preferences, task history (database)
     +
No persistent memory  → stateless tool-execution steps within the agent

Summarized memory gets added only when conversation history genuinely threatens to overflow the context window across sessions — which is a specific problem, not a general one.

SKILL.md vs CLAUDE.md

Where they are used and who uses them

These are primarily Claude Code concepts — the CLI tool developers use to let Claude work directly in their codebase. Not something you'd typically use in a Messages API integration you're building for end users.

Claude Code CLI          → developer opens terminal, runs Claude against codebase
                                       CLAUDE.md and Skills live in the project directory
                                       Claude reads them automatically

Your Spring Boot Agent   → you build the loop yourself
                                           you inject instructions via system prompt
                                           CLAUDE.md / Skills not relevant here

Think of it this way — CLAUDE.md and Skills are for developers using Claude as a coding assistant, not for developers building Claude-powered applications.

---

Who uses them in practice:

CLAUDE.md   → the team that owns the codebase
                      "Here are our coding standards, commit message format,
                       test requirements — apply these to everything"

Skills      →     individual developers or the team
                      "Here is how to do a security review"
                      "Here is how to write our API documentation"
                      "Here is our deployment checklist"
                       Loaded only when that specific task is requested

---

Why CLAUDE.md still exists if Skills are more efficient

This is the right question. Skills are more efficient — but only for instructions that apply to some tasks. CLAUDE.md exists for instructions that genuinely apply to every single task without exception.

Consider these instructions:

"Never commit secrets or API keys"
"All code must be Java 21 compatible"
"Always write unit tests for new methods"
"Our package structure is com.accenture.project.*"

These apply whether Claude is:

• Reviewing security vulnerabilities
• Writing a new feature
• Fixing a bug
• Writing documentation
• Refactoring existing code

There is no task where these don't apply. Putting them in a Skill means they only load when a description matches — which means they might not load when Claude is doing a simple bug fix, and Claude violates a core team standard.

CLAUDE.md = constitutional rules
            apply unconditionally to everything
            zero risk of being missed

Skills    = specialist playbooks
            apply only to specific task types
            zero cost when not relevant

---

The production reality

In Claude Code usage — which is the primary home for both:

Most commonly used:   CLAUDE.md
                      Almost every team using Claude Code has one
                      It's the first thing you set up
                      Simple, unconditional, always works

Second:               Skills
                      Used by teams with mature Claude Code workflows
                      Who have identified specific recurring task types
                      Worth the overhead of maintaining skill files

Least common:         In-context instructions
                      Ad hoc, one-off, exploratory work
                      No maintenance overhead but no reuse either