🤔 What if a coding agent could actually remember?
AI coding agents are becoming surprisingly capable.
They can write code, inspect repositories, debug errors, interact with tools, and reason through complex development tasks.
But there is still a frustrating limitation:
They forget.
A new session often starts without the useful experience accumulated during previous sessions.
A developer might have already explained:
🔐 security requirements
🏗️ architectural constraints
💼 customer requirements
💰 commercial conditions
🧠 important project decisions
🛠️ recurring development patterns
Yet the next session may require the agent to rediscover that context.
That made me ask a different question:
What if an AI coding agent could remember important project knowledge and also learn from repeated patterns in its own interactions?
That question led me to build DIAS — Deal Intelligence Agent Skill.
DIAS combines persistent memory, telemetry, reflection, and controlled tool evolution using Hindsight.
The core idea is simple:
🧠 Remember
↓
👀 Observe
↓
🔎 Reflect
↓
🛠️ Adapt
↓
⚡ Execute
🧩 The Problem: Coding Agents Have Short-Term Context
A coding agent usually works within a session.
Imagine this workflow:
👨💻 Developer
↓
🤖 Coding Agent
↓
💻 Solve Problem
↓
✅ Task Completed
↓
🔚 Session Ends
The problem appears when the next session begins.
The project still has context, but the agent may not have access to everything it learned previously.
For a real engineering workflow, that can mean repeatedly explaining the same things.
DIAS approaches this by treating useful project information as persistent memory rather than temporary conversation context.
🧠 Two Different Types of Memory
One of the key design decisions in DIAS is separating memory into two dimensions.
1️⃣ dias_deals — Domain Memory
dias_deals focuses on information that should remain useful across sessions.
Examples include:
👤 customer disclosures
🔐 security mandates
💰 commercial terms
🏗️ architectural constraints
📋 important domain context
The purpose isn't to remember every conversation.
The purpose is to preserve information that can influence future decisions.
2️⃣ dias_telemetry — Developer Interaction Memory
The second memory dimension is:
dias_telemetry
This captures patterns around agent usage and developer interaction.
For example, imagine an agent repeatedly performing relational database queries through a manual workflow.
One occurrence may be completely normal.
But if the same pattern keeps appearing, it may indicate developer friction.
That makes telemetry useful for something beyond logging.
It becomes input for reflection.
🧠 Where Hindsight Fits
DIAS uses Hindsight as the persistent memory and reflection layer.
The architecture can be represented like this:
🤖 Coding Agent
│
▼
┌───────────┐
│ DIAS │
└─────┬─────┘
│
┌────────┴────────┐
▼ ▼
🧠 dias_deals 📊 dias_telemetry
Domain Memory Telemetry
│ │
│ ▼
│ 🔎 Hindsight Reflect
│ │
│ ▼
│ 🔁 Friction Pattern
│ │
│ ▼
│ 🛠️ Tool Proposal
│ │
│ ▼
│ 👤 Human Approval
│ │
│ ▼
│ 🐘 Neon PostgreSQL
│ MCP
└─────────────────┘
This creates an important distinction:
Memory isn't only about retrieving old information.
It can also provide the history needed to identify recurring patterns.
🔎 From Memory to Reflection
This is where the architecture becomes more interesting.
Traditional memory might answer:
"What happened previously?"
Reflection asks:
"What can we learn from what happened previously?"
DIAS explores that second question.
The conceptual flow is:
💻 Agent Interaction
↓
📊 Telemetry Captured
↓
🧠 Persistent Memory
↓
🔎 Reflection
↓
🔁 Recurring Pattern
↓
💡 Potential Improvement
This means previous interactions can become useful signals for future agent behavior.
🗄️ Example: Repeated Database Work
Consider a developer working on an application that repeatedly requires relational database operations.
Without persistent telemetry:
💻 Database Task
↓
🔧 Manual Workflow
↓
✅ Task Completed
↓
🔚 Session Ends
The next session can repeat the same workflow.
With DIAS:
💻 Database Task
↓
📊 Telemetry Recorded
↓
🧠 Pattern Retained
↓
🔁 Repeated Behavior Detected
↓
🔎 Hindsight Reflect
↓
💡 Friction Identified
Now the system has additional information it can use to reason about the workflow.
🛠️ From Friction to Tool Evolution
This is where MCP becomes important.
If repeated database interactions suggest that the agent would benefit from a dedicated database capability, DIAS can stage the Neon PostgreSQL MCP server.
But there is an important safety boundary.
The agent should not simply be allowed to install or activate arbitrary capabilities without oversight.
DIAS therefore introduces a human approval step:
🔎 Detect
↓
🧠 Reflect
↓
💡 Propose
↓
👤 Human Approval
↓
🛠️ Activate
↓
⚡ Use
The idea is controlled adaptation, rather than unlimited autonomy.
🔄 Before vs After
❌ Before DIAS
👨💻 Developer
↓
🤖 Coding Agent
↓
🗄️ Repeated Database Work
↓
🔚 Session Ends
↓
❌ Experience Lost
↓
🔁 Next Session Repeats
✅ With DIAS
👨💻 Developer
↓
🤖 Coding Agent
↓
🗄️ Database Interaction
↓
📊 Telemetry
↓
🧠 Persistent Memory
↓
🔎 Hindsight Reflect
↓
💡 Friction Identified
↓
👤 Human Approval
↓
🛠️ Neon PostgreSQL MCP
The important change isn't simply:
"The agent remembers more."
It is:
Previous experience can become an input into future decisions.
💻 How the Implementation Works
The DIAS repository contains the implementation of the memory and agent workflow.
🧠 1. Persisting Memory
⚠️ Replace the following placeholder with the actual DIAS code.
INSERT REAL HINDSIGHT RETAIN CODE FROM DIAS REPOSITORY
The important part to demonstrate here is how information is actually persisted into Hindsight.
🔎 2. Recalling Memory
⚠️ Replace with the actual DIAS recall implementation.
INSERT REAL HINDSIGHT RECALL CODE FROM DIAS REPOSITORY
This snippet should demonstrate how previously retained information becomes available to the agent.
📊 3. Telemetry / Reflection
⚠️ Replace with the actual telemetry or Reflect implementation.
INSERT REAL DIAS TELEMETRY / REFLECT CODE
This is especially important because it demonstrates the bridge between:
📊 Observation
↓
🧠 Memory
↓
🔎 Reflection
↓
🛠️ Adaptation
The submission guide specifically asks for 2–4 small real code snippets, so these should be taken directly from the actual repository rather than invented examples.
👤 Human-in-the-Loop Safety
Adaptive systems create another important question:
If an agent identifies a tool it needs, should it activate that tool automatically?
DIAS keeps a human approval boundary.
That gives the workflow an explicit control point:
🤖 Agent observes
↓
🔎 System reflects
↓
💡 Potential capability identified
↓
👤 Human reviews
↓
🛠️ Capability activated
This makes the architecture more controlled.
The objective isn't to give an agent unlimited autonomy.
It is to allow the agent to identify potential improvements while keeping humans in the loop for capability changes.
📸 Screenshots to Add
The submission guide asks for screenshots or images that show the system in action.
Add these underneath the relevant sections:
📸 Screenshot 1 — DIAS Architecture
Show:
Agent → DIAS → Hindsight → Reflection → MCP
📸 Screenshot 2 — Memory
Show the Hindsight memory/recall workflow.
📸 Screenshot 3 — Telemetry
Show dias_telemetry or the relevant telemetry workflow.
📸 Screenshot 4 — Tool Evolution
Show the Neon PostgreSQL MCP activation / approval flow if available.
📚 What I Learned
1️⃣ Persistent memory should be selective
An agent doesn't need to remember everything.
It needs to remember information that has future value.
2️⃣ Domain memory and telemetry are different
Project knowledge answers:
"What should the agent know?"
Telemetry answers:
"What patterns are emerging?"
Separating them makes the architecture easier to reason about.
3️⃣ Reflection is different from retrieval
Retrieval asks:
"What happened before?"
Reflection asks:
"What pattern can we learn from what happened before?"
That distinction is central to DIAS.
4️⃣ Tool evolution needs boundaries
Giving an agent more tools is relatively easy.
Giving it a controlled mechanism for recognizing when another tool may be useful is a different problem.
That is why the human approval boundary matters.
5️⃣ The goal isn't memory itself
The real goal isn't:
"Make the agent remember everything."
It is:
"Make previous experience useful."
⚠️ Limitations
DIAS is an exploration of this architecture, not a claim that persistent memory solves every problem with coding agents.
There are still important engineering questions around:
🧠 deciding what information is worth retaining
🧹 avoiding irrelevant memories
🔄 handling outdated information
📏 measuring whether reflection improves outcomes
🔎 determining when repeated behavior actually represents friction
🛠️ deciding which tool should be proposed
👤 maintaining appropriate human approval boundaries
Adding memory doesn't automatically solve these problems.
It creates another layer that the agent can use to reason about its previous experience.
🎯 Conclusion
The most interesting property of an AI coding agent may not be how much context it can process in one session.
It may be whether useful experience from previous sessions can change what happens next.
That's the idea explored with DIAS.
The architecture can be summarized as:
🧠 Remember
↓
👀 Observe
↓
🔎 Reflect
↓
🛠️ Adapt
↓
⚡ Execute
Hindsight provides the persistent memory and reflection foundation.
DIAS uses that foundation to explore an agent that can:
🧠 retain domain context
📊 observe interaction patterns
🔎 identify recurring friction
💡 propose capability changes
👤 keep humans in the approval loop
The goal isn't an agent that remembers everything.
It's an agent that remembers what matters. 🚀
🔗 Resources
💻 DIAS GitHub
https://github.com/Manibhushanamk/DEAL-INTELLIGENCE-AGENT-SKILL-DIAS-
🧠 Hindsight GitHub
https://github.com/vectorize-io/hindsight
📚 Hindsight Documentation
https://hindsight.vectorize.io/
🔎 Vectorize Agent Memory
Top comments (0)