agent-decision-memory

Decides memory and state storage per category for agent system designs.

1|9|Updated Jul 11, 2026
One-click install
npx skills add https://github.com/agenticgogol/Edureka_Coding_Agent_Enabled_Demo_11Jul --skill agent-decision-memory-agenticgogol
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: agent-decision-memory
Source: https://github.com/agenticgogol/Edureka_Coding_Agent_Enabled_Demo_11Jul/tree/main/.claude/skills/agent-decision-memory
Command: npx skills add https://github.com/agenticgogol/Edureka_Coding_Agent_Enabled_Demo_11Jul --skill agent-decision-memory-agenticgogol

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Designing memory and state for an AI agent system is easy to get wrong: teams either over-engineer storage they don't need or forget durable state and audit trails that later stages depend on. This Skill walks through a six-category memory taxonomy and produces an approved, written memory design consistent with earlier architecture decisions. ## Core Features & Use Cases - Six-category memory taxonomy: Evaluates conversation context, user preferences, task/scratch state, business records, long-term knowledge, and audit history, deciding for each whether it is needed and how it is stored and scoped. - Cross-stage consistency checks: Aligns task-state durability with the runtime shape from stage 3 and audit history with the tool inventory from stage 4, flagging inconsistencies instead of silently re-deciding earlier choices. - Approval-gated output: Writes a structured system_design/05_memory.md decision table and stops for explicit user approval before the pipeline continues. - Use Case: As stage 5 of an agent-system-design pipeline, after topology, pattern, runtime shape, and tools are approved, use it to decide that a support agent needs per-session conversation context, checkpointed task state for human approvals, and an append-only audit log, while skipping user preferences for anonymous usage. ## Quick Start Run stage 5 of the agent system design pipeline to decide memory and state storage for my approved agent design and write the memory design document for my review.

Frequently Asked Questions about agent-decision-memory

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design memory for an AI agent system?▼

Walk through six categories: conversation context, user preferences, task/scratch state, business records, long-term knowledge, and audit history. For each, decide if it is needed, then specify store type, scope, and TTL based on your usecase and prior architecture decisions.

What memory categories should an agent architecture consider?▼

The six categories are conversation context, user preferences, task/scratch state, business records, long-term knowledge, and audit history. Not every agent needs all six; a batch job may skip conversation context while an audited workflow requires append-only logs.

When does agent task state need durable storage?▼

Task state needs durable, checkpointed storage when the runtime shape decision requires persisted state or when tools have human-approval gates. If the runtime is synchronous and non-durable, in-memory state is sufficient.

Should agent business records use a separate database?▼

Business records should default to the existing system of record such as the current database or API, not duplicated agent-specific storage. Only treat it as a real decision when the usecase genuinely has no existing store to read or write.

When should I not add a vector store for agent memory?▼

Do not introduce a vector store for long-term knowledge unless the earlier pattern decision already chose a RAG-flavored approach. Adding one independently creates inconsistency; flag it back to the user instead of silently re-deciding the pattern.