Play 25
Conversation Memory
Persistent agent memory — short-term, long-term, and episodic stores.
Gives agents the ability to remember across sessions. Three-tier memory architecture: short-term (Redis, current conversation context), long-term (Cosmos DB, user preferences and facts), and episodic (AI Search, past interaction summaries). Agents learn from interactions, personalize responses, and build knowledge over time. Semantic recall finds relevant memories even when exact keywords differ. Memory decay prevents stale data from poisoning responses.
Architecture Pattern
Memory layer: 3-tier (short/long/episodic), semantic recall, decay policies
Azure Services
DevKit (.github Agentic OS)
- agent.md — root orchestrator with builder→reviewer→tuner handoffs
- 3 agents — Memory Builder (gpt-4o), Reviewer (gpt-4o-mini), Tuner (gpt-4o-mini)
- 3 skills — deploy (102 lines), evaluate (103 lines), tune (101 lines)
- 4 prompts — /deploy, /test, /review, /evaluate with agent routing
- .vscode/mcp.json — FrootAI MCP with Cosmos DB + Redis inputs + envFile
TuneKit (AI Config)
- config/openai.json — embedding model for memory search
- config/memory.json — tier definitions, TTL per tier, max memories
- config/guardrails.json — PII filtering in memories, consent rules
- evaluation/eval.py — Recall accuracy >85%, Memory relevance >0.80
Tuning Parameters
Machine evidence
FrootAI evidence lifecycle
This is an internal evidence maturity label, not third-party certification, accreditation, legal compliance, or a production guarantee. Missing or expired evidence demotes automatically; catalog claims cannot promote a play.
This play currently has design evidence only. A runnable scenario, endpoint evaluation, and build receipts are the next contiguous gates.
Repo Intelligence
v1A no-clone, revision-pinned map for agents and humans. Observed evidence is separated from inferred flow so the output stays useful without pretending to be a full call graph.