DEV Community: Bobur Umurzokov

Our Migration Story: From Azure App Service to Container Apps

Bobur Umurzokov — Fri, 13 Feb 2026 12:04:09 +0000

Why Infrastructure Decisions Are Business Decisions

As CTO and Co-founder of Datox, I’ve always believed that infrastructure decisions are business decisions. When we started building our Datox platform, Azure App Service was the fastest way to get to market. It allowed us to focus on product, customers, and regulatory workflows without over-engineering from day one. But as Datox evolved, serving more customers, supporting multi-tenant deployments, and expanding into different Azure subscriptions, our architecture needed to evolve too.

This post is the story of how and why we migrated from Azure App Service to Azure Container Apps. It was a strategic move that reduced our non-production costs by 90%, enabled true independent scaling, simplified customer deployments, and positioned Datox for a cloud-native, enterprise-ready future.

What Are Azure Container Apps?

Azure Container Apps is a fully managed serverless platform for running containerized applications. Built on Kubernetes, it abstracts away infrastructure complexity while providing powerful features for modern application development. Think of it as the sweet spot between Platform as a Service (PaaS) simplicity and Infrastructure as a Service (IaaS) flexibility.

Key Characteristics:

Serverless container hosting
Built-in autoscaling (scale to zero capability)
Microservices-native architecture
Event-driven scaling with KEDA (Kubernetes Event-Driven Autoscaling)
Integrated ingress and service discovery
Built-in traffic splitting for blue-green deployments

Business Drivers Behind the Migration

As our product matured, we faced several strategic business requirements:

Multi-tenancy: Customers wanted to deploy our solution in their own Azure subscriptions or on-premises.
Cloud-native architecture: Need for portable, containerized deployments that could run anywhere
Independent scaling: Frontend and backend services had different load patterns and needed to scale independently
Cost optimization: Non-production environments (dev, staging, demo) were incurring costs 24/7 even when idle
Microservices evolution: Growing need to break down the monolith into independently deployable services

Technical Constraints with Azure App Service

While App Service helped us move fast early on, we started hitting structural limitations:

Always-on pricing meant we paid for idle development environments overnight and on weekends
Difficult to package and deploy the entire stack to customer clouds
Frontend (React SPA) and backend (Python FastAPI) had to scale together despite different traffic patterns
Limited support for running multiple interconnected services efficiently
Complex custom domain and SSL management across multiple environments

The Migration Strategy

We made the strategic decision to containerize our entire application stack and migrate to Azure Container Apps. The migration involved:

Containerization
- Created multi-stage Dockerfiles for frontend (React) and backend (Python FastAPI)
- Containerized Azure Functions for background processing and SignalR real-time messaging
- Optimized images using Alpine Linux and multi-stage builds
Infrastructure as Code
- Automated deployment pipelines with GitHub Actions
- Environment-specific configurations using build arguments and runtime environment variables
- Secret management via Azure Key Vault integration
Multi-environment strategy
- Development, Staging, and Production environments
- Each environment is independently scalable and configurable
- Branch-based deployment automation (dev branch → dev environment, main → production)

Measurable Results

The migration delivered significant benefits across cost, operations, and business capabilities:

Metric	Before (App Service)	After (Container Apps)	Improvement
Monthly Cost (Non-Prod)	~$450 (3 environments, always-on)	~$45 (scale to zero overnight/weekends)	90% reduction
Deployment Time	8-12 minutes per environment	3-5 minutes per environment	50% faster
Frontend Scaling	Coupled with backend	Independent (0-10 replicas)	Independent scaling
Backend Scaling	Coupled with frontend	Independent (0-30 replicas)	Independent scaling
Cold Start Time	N/A (always-on)	<10 seconds from zero	Acceptable trade-off
Environment Spin-up	2-3 hours (manual setup)	15 minutes (automated)	88% faster
Customer Deployment	1-2 days (complex process)	2-4 hours (containerized)	80% reduction
SSL Certificate Management	Manual per environment	Automated with Container Apps	Zero manual effort
Service Discovery	Manual configuration	Built-in internal ingress	Automatic
Infrastructure Overhead	Medium (App Service plans)	Low (serverless)	Minimal management

What key benefits have been realized

1. Cost Optimization

Development and demo environments now scale to zero during off-hours
Production uses dedicated capacity for consistent performance
Eliminated over-provisioning—each service sized appropriately

2. Customer Deployments

Entire platform packaged as container images
Customers deploy to their Azure subscriptions in hours, not days
Consistent experience across all customer environments
Easy version upgrades via container image updates

3. Independent Scaling

Frontend scales based on HTTP requests (user traffic)
Backend scales based on API load and queue depth
Azure Functions scale based on message queue length
Each service optimized for its workload pattern

4. Developer Productivity

Local development with Docker Compose mirrors production exactly
CI/CD pipelines deploy to any environment with branch push
No more "works on my machine" issues
Faster iteration cycles for development team

5. Operational Excellence

Built-in health checks and auto-recovery
Application Insights integration for centralized monitoring
Log Analytics for troubleshooting across all services
Blue-green deployments via traffic splitting

6. AI-Ready Architecture

As Datox evolved, our AI workloads expanded from document processing to real-time compliance validation and background data enrichment.

Azure Container Apps significantly improved how we run and scale our AI services:

AI workers scale independently based on queue depth and workload
Background model execution runs in isolated containers
No need to over-provision compute for sporadic AI spikes
Easier integration with Azure AI services (Azure Foundry) and GPU-enabled environments (when needed)
Faster experimentation with new AI services without impacting core APIs

Previously, under App Service, AI workloads were tightly coupled with the main application runtime. Now, they are independently deployable and scalable microservices.

This architectural shift allowed us to:

Deploy AI features faster
Control AI infrastructure costs more precisely
Improve reliability during heavy document-processing workloads
Prepare for future GPU-backed and high-throughput AI services

Lessons Learned

What Worked Well:

Multi-stage Docker builds kept images small and secure
Scale-to-zero for non-production saved significant costs
GitHub Actions integration made CI/CD seamless
Internal ingress simplified service-to-service communication

Challenges Overcome:

Initial cold start optimization required tuning image sizes
Secret management required Key Vault integration planning
Team needed Docker knowledge (addressed with training)
Database connection pooling configuration for scaled replicas

Would We Do It Again?

Absolutely. The migration paid for itself in the first quarter through cost savings alone, and the business benefits, especially customer deployments, have been transformative for our go-to-market strategy. In the next post, I’ll go hands-on and show you exactly how to make a similar migration from containerization to infrastructure setup and CI/CD.

Agent Knowledge vs Memories: Understanding the Difference

Bobur Umurzokov — Fri, 09 Jan 2026 11:41:54 +0000

Most developers are still confused about what "memory" means in AI and why they should use it. Or they keep asking: what’s the difference between knowledge and memory? How to use them together? Many of them treat memory as just cached conversations. Others try to build their own version by storing data in files.

Knowledge and memories serve very different purposes inside an AI agent. When you clearly separate them and design for each intentionally, your agent stops behaving like a scripted chatbot, saves up to 80% LLM tokens, and starts acting like a helpful assistant that actually remembers customers.

Knowledge: Your Agent's Reference Library

Think of it as your agent’s reference library. Every customer reads from the same book, and that consistency is what makes your agent reliable.

Knowledge is everything that is true for all customers, regardless of who is asking. It represents your business facts: documentation, pricing, policies, shipping rules, FAQs, API references, and internal procedures.

Knowledge is stable. It changes only when your business changes, not when the customer changes.

When a customer asks about shipping rates, the agent doesn’t need personal context. It simply retrieves the correct information from the knowledge base and responds. The answer should be identical for every customer, every time.

This consistency is the strength of knowledge. If it’s wrong, your agent confidently gives incorrect answers. If it’s missing, your agent starts guessing. That’s why knowledge must be curated and maintained carefully.

Knowledge Characteristics

Static & Structured: Contains business information that doesn't change frequently—product catalogs, FAQs, policies, procedures
Universally Shared: All customers access the same knowledge base—what's true for one customer is true for all
Manually Curated: You upload, organize, and maintain this content based on what your business offers
Purpose: Provides accurate, consistent answers grounded in your business reality

Real-World Knowledge Example

Customer: "What are your shipping rates to Canada?"

Agent: [Searches knowledge base]

"We offer three shipping options to Canada: Standard (5-7 days) for $12.99, 
Express (2-3 days) for $24.99, and Overnight for $49.99. Free shipping on orders over $150."

The agent pulled this directly from your knowledge base, the same answer every customer gets, because it's factual business information.

Memories: Your Agent's Personal Journal for Each Customer

Memories are the opposite of knowledge. They are personal, dynamic, and unique to each customer. Memory captures things like preferences, past purchases, previous issues, and important details the customer has already shared.

Memory answers a different question: what do we already know about this person?

If a customer says they prefer blue sneakers in size 10, that information should never live in your knowledge base. It belongs in memory, scoped only to that customer. When the same customer comes back weeks later on a different channel the agent can continue the conversation naturally without asking again.

This is what prevents the “AI amnesia” problem. Without memory, every interaction resets. Customers repeat themselves. Context disappears. Trust erodes.

Memory Characteristics

Dynamic & Personal: Captures conversation history, preferences, past issues, and context specific to each customer
Individually Isolated: Each customer has their own memory space—what Sarah said never shows up in John's context
Automatically Captured: AI extracts and stores important details from conversations without manual work
Cross-Channel: Follows customers across WhatsApp, Telegram, web chat—one continuous memory
Purpose: Enables personalized, context-aware interactions that feel natural and continuous

Real-World Memory Example

Week 1 - WhatsApp:

Customer: "I need sneakers, size 10, prefer blue colors"

Agent: [Stores: prefers blue, size 10, interested in sneakers]

Week 3 - Telegram (same customer, different channel):

Customer: "Do you have new arrivals?"

Agent: "Yes! We just got new blue sneakers in size 10—based on your previous interest, you might love our Nike Runner collection. 
Want to see them?"

Notice how the agent remembered the customer's preferences across different channels and weeks. This is the power of memories. It's personal, persistent, and creates a seamless experience.

AI memory for customer support chats

Stop making customers repeat themselves. Add memory so AI remembers, learns, and supports like a human. 🔗 https://www.chatmemory.ai

How Agent Knowledge and Memory Work Together

The best AI agents don’t choose between knowledge or memory. They use both, in sequence.

First, the agent checks memory to understand who it’s talking to and what context already exists. Then it checks knowledge to ensure the response follows business rules and factual accuracy. The final answer combines both into a response that is correct and personal.

For example, when a customer asks to return an order, memory tells the agent which order the customer placed and when. Knowledge tells the agent what the return policy allows. The response feels helpful because it references the specific order while correctly applying company rules.

Customer: "I want to return my order"

Agent's Process:

Check Memory: "This is Sarah, she ordered blue sneakers (order #1234) 2 weeks ago via WhatsApp"
Check Knowledge: "Return policy allows 30 days, need receipt, items must be unworn"
Combine: Personalized response with accurate policy

Agent: "Hi Sarah! I can help with returning your blue sneakers (Order #1234). 
Our 30-day return policy applies. Since you ordered 2 weeks ago, you're well within the window. 
Just make sure they're unworn. Would you like me to generate a return label?"

See the difference? The agent combined knowledge (return policy details) with memories (Sarah's specific order, timeline, and preferences) to create a response that's both accurate and personal.

Why Mixing Knowledge and Memory Breaks AI Agents

Many teams make the mistake of storing personal conversations inside their knowledge base or passing entire chat histories with every request. This causes multiple problems at once.

Answers become noisy because personal data pollutes shared facts. Token usage explodes because the agent is constantly reprocessing irrelevant context. Privacy becomes harder to manage because personal data is mixed with permanent knowledge.

A clean separation fixes all of this. Knowledge stays global and stable. Memory stays personal and contextual. The agent retrieves only what it needs, when it needs it.

Knowledge vs Memories: Side-by-Side Comparison

Aspect	Knowledge	Memories
Content Type	Business facts & information	Personal history & preferences
Who Has Access	All customers (shared)	Individual customer only
How It's Created	Manually uploaded by you	Auto-captured from conversations
Update Frequency	Rarely (when business changes)	Constantly (every conversation)
Persistence	Permanent until you change it	Configurable retention (7-90+ days)
Primary Purpose	Provide accurate answers	Enable personalization
Example Content	Product specs, pricing, policies	Order history, preferences, past issues

When to Use What

Use Knowledge For:

Product catalogs and specifications
Company policies and procedures
FAQs and troubleshooting guides
Pricing and shipping information
Training materials and best practices

Use Memories For:

Customer purchase history
Personal preferences and interests
Past support issues and resolutions
Communication preferences
Conversation context and continuity

How to Build It the Right Way

Start with Knowledge: Upload your docs, APIs, FAQs. Make sure your agent can answer factual questions accurately and consistently.
Add Memory: Turn on automatic context capture. Let it learn about each user over time. Set Retention: Decide how long to keep memories. 7 days? 90 days? Forever? Depends on your use case.
Watch and Adjust: See what questions come up repeatedly. Add them to knowledge. See what context matters. Make sure memory captures it.
Enable Memory Capture: Configure your agent to automatically extract and store customer-specific context
Set Retention Policies: Decide how long to keep memories based on your business needs and compliance requirements
Monitor & Refine: Watch how your agent uses both systems and adjust your knowledge content based on common questions

Ready to Build Smarter Agents?

ChatMemory gives you both. Knowledge bases and automatic memory capture. Works across WhatsApp, Telegram, web chat, wherever your users are.

Get Started Free: app.chatmemory.ai

RAG vs Memory for AI Agents: What’s the Difference

Bobur Umurzokov — Wed, 22 Oct 2025 13:16:30 +0000

AI agents are becoming more powerful every day. They can chat, write code, answer questions, and help with tasks that once required human reasoning. They all share one challenge: how to handle knowledge/context over time.

Two architectural patterns have emerged to fill this gap: Retrieval-Augmented Generation (RAG) and Memory. Both aim to make large language models (LLMs) more capable, context-aware, and cost-efficient. Yet they solve different problems and fit different stages of an agent’s lifecycle. In this article, we’ll explore both in simple terms, show how they differ, and explain when to use each, or both together.

The Problem: LLMs Without Context

LLMs are stateless by design. Each prompt is processed independently; once you send a new request, the model forgets everything that happened before unless you include it again in the input.

This leads to three core limitations:

No persistence – The model doesn’t remember past sessions or user-specific data.
High token cost – To “remind” the model of context, you must keep appending long histories.
Limited factual grounding – Models can hallucinate or give outdated answers if information was not in their training set.

What is RAG?

RAG is a retrieval layer built around an LLM. Instead of relying only on the model’s internal parameters, RAG injects external knowledge dynamically at query time.

The architecture typically has three parts:

Indexing pipeline – Preprocesses and embeds documents into a vector database (e.g., Pinecone, Weaviate, Qdrant, pgvector).
Retrieval pipeline – On each query, converts the user input into an embedding and finds semantically similar documents.
Generation step – Combines the query with the retrieved context and sends it to the LLM for final answer generation.

This pattern can be expressed as:

Answer = LLM(prompt + top_k(retrieve(query)))

Example of RAG in action

Take an example of an AI assistant for your company’s internal documentation. The model doesn’t know your private documents because they weren’t part of its training data. With RAG, you can:

Store all your company docs in a vector database (like Pinecone, Weaviate, or Qdrant).
When a user asks, “How do I reset my password?”, the assistant retrieves similar text from those documents.
The model then reads the retrieved text and generates an answer.

In this setup, the knowledge source is external (e.g., a document corpus or database) and stateless (each query starts fresh).

Why RAG became popular

RAG is powerful because it solves two big problems of LLMs:

Out-of-date knowledge – The model was trained months or years ago and doesn’t know the latest facts. With RAG, you can retrieve new information anytime.
Private data – You can feed the model your own documents without retraining it.

That’s why RAG became a standard method in enterprise AI systems and chatbots.

Limitations of RAG

However, RAG has clear boundaries:

No persistence – It doesn’t learn from interactions; every query is independent.
Limited personalization – Retrieval is document-based, not user-based.
Noise in embeddings – Semantic similarity can return irrelevant or redundant text.
Operational cost – Vector databases require maintenance, tuning, and embedding updates.

From a user experience view, RAG feels like a smart search engine — informative, but not personal.

What is Memory in AI Agents?

Memory refers to a persistent context store that agents can read, write, and update across interactions. Instead of only pulling facts from external sources, the agent records what it learns and reuses that later. Memory is not just a cache as well, and it’s part of the agent’s reasoning state.

A memory allows an AI agent to:

Recall previous interactions,
Learn from them,
Update its knowledge,
And behave consistently over time.

It’s not just about retrieval, but it’s about experience.

Example of memory in an agent

Imagine you tell your AI assistant:

“I don’t like coffee.”

Then tomorrow, you ask:

“Can you recommend a drink for breakfast?”

If the agent replies “Espresso,” it clearly forgot what you said. But if it answers:

“Maybe tea or juice — since you don’t like coffee,”

then it remembered.

That’s what memory enables: continuity and context across multiple conversations or tasks. See also an example use case for a customer support AI Agent with the memory.

Architecture Layers of Memory

A typical memory often includes several layers:

Layer	Purpose	Typical Storage
Short-term memory	Keeps recent conversation turns or active context	In-memory buffer / prompt window
Long-term memory	Persists knowledge beyond a single session	SQL DB, JSON store, or vector DB
Working memory	Tracks intermediate steps in reasoning or planning	In-process memory / scratchpad

Each layer serves a different purpose in balancing accuracy, context, and performance.

Technical Implementations of Memory

Memory can be implemented in multiple ways:

Vector Memory – Summaries or key facts are embedded and retrieved by similarity (like RAG but for personal context).
Key-Value Store – Store structured entries like {user_id: preferences} for fast lookup.
SQL-based Memory – Systems like Memori treat memories as relational data with timestamps, TTLs, and lineage.
Graph Memory – Represents relationships between entities and concepts (useful for reasoning).

Each approach has different strengths:

Vector memory captures semantics,
SQL memory offers structure and governance,
Graph memory supports reasoning,
Key-value memory is simple and fast.

Limitations of Memory

Storage complexity – Managing and summarizing large histories is non-trivial.
Forgetting and decay – The system must decide what to retain or drop.
Versioning and conflict resolution – Updating facts without duplication or contradiction.
Privacy and compliance – Persistent data must be encrypted, access-controlled, and deletable on request.

In other words: memory improves user experience but introduces data-management challenges.

RAG vs Memory: Architectural Comparison

Let’s summarize the difference in technical terms.

Aspect	RAG	Memory
Goal	Retrieve external knowledge on demand	Retain internal experiences over time
Source	Document corpus / external data	Conversation history / agent state
Statefulness	Stateless	Stateful
Retrieval method	Embedding similarity	Structured or contextual recall
Update mechanism	Update document index	Write to memory store
Common storage	Vector DB (Pinecone, Qdrant, etc.)	SQL DB, KV store, hybrid
Use case	Q&A, search, knowledge grounding	Personalization, reasoning, long-term continuity

In simple terms:

RAG helps your agent know more.
Memory helps your agent remember better.

Why RAG Alone Isn’t Enough

Many production LLM solution today rely purely on RAG. It works for document-heavy tasks but fails in long-running or adaptive contexts.

No Temporal Awareness

RAG retrieves documents but doesn’t evolve. An agent can’t say, “Last week you told me…” unless you manually re-feed that conversation.

Inefficient Context Windows

Without persistent memory, developers must send the full conversation each time — expensive and slow.

Lack of User Adaptation

RAG can personalize results by user ID, but it doesn’t adapt from behavior. Memory enables “learning-by-interaction.”

Why Memory Alone Isn’t Enough Either

Memory store experience but may lack external factual grounding.

For example:

A sales assistant can remember your clients and notes,
But it still needs to retrieve the latest CRM records or pricing sheets.

Without RAG, memory-driven agents risk becoming contextually aware but factually outdated.

Thus, in modern architectures, RAG and Memory complement each other.

RAG + Memory: The Hybrid Pattern

The hybrid approach combines retrieval (for facts) and memory (for experiences).

At runtime, the agent pipeline looks like this:

→ Retrieve from long-term memory (personal context)
→ Retrieve external documents (RAG)
→ Merge context
→ Generate response via LLM
→ Write back new knowledge to memory

This architecture mirrors how humans operate. We recall personal experience, look up external information, then act.

From RAG to Memory-First Architectures

RAG was the first major step toward intelligent retrieval. But the future lies in memory-first architectures where the agent starts from what it already knows and uses retrieval only when necessary.

A memory-first agent workflow might look like this:

Query memory: “Do I already know this?”
If missing, trigger RAG to retrieve external data.
Merge results.
Respond and store a summary for future use.

This dramatically reduces latency and API costs because retrieval is conditional, not constant.

Conclusion

RAG was a breakthrough. It gave AI systems access to live information without retraining.

But it was only the first step. Memory extends this foundation, enabling agents to learn, adapt, and personalize across sessions.

Evolution	Focus	Analogy
RAG	Information retrieval	Search engine
Memory	Persistent learning	Human cognition

AI memory for customer support chats

Stop making customers repeat themselves. Add memory so AI remembers, learns, and supports like a human.
🔗 https://www.chatmemory.ai

AutoGen Multi-agent Conversations Memory

Bobur Umurzokov — Mon, 29 Sep 2025 07:57:52 +0000

In this tutorial, you'll learn how to create AutoGen AI agents that can remember conversations and use that memory in future discussions. We'll build a simple Software Development Consulting Team with two agents:

Alex - Technical Architect (designs systems)
Sam - Full-Stack Developer (builds applications)

They'll help a client build an e-commerce website by remembering everything discussed and providing more informed suggestions for the client.

What is Memori?

Memori is an open-source memory engine that provides persistent, intelligent memory for any LLM using standard SQL databases. Memori uses multiple agents working together to intelligently promote essential long-term memories to short-term storage for faster context injection.

With a single line of code memori.enable() any LLM gains the ability to remember conversations, learn from interactions, and maintain context across sessions. The entire memory system is stored in a standard SQLite database (or PostgreSQL/MySQL for enterprise deployments), making it fully portable, auditable, and owned by the user.

Key features:

Auto-recording: Automatically saves all conversations
Works with existing databases: SQLite, PostgreSQL, MySQL, MongoDB
Smart memory: AI decides what's important to remember
Cross-session: Agents remember between different conversations
Zero setup: Just initialize and enable - that's it!

Requirements

Before we start, we need to install some packages and set up our environment.

pip install memorisdk autogen-agentchat "autogen-ext[openai]" python-dotenv

Set up your OpenAI API key

You'll need an OpenAI API key to run this example.

import os
os.environ["OPENAI_API_KEY"] = "your-api-key-here"

Step 1: Import Libraries

Let's import everything we need for our multi-agent conversation system.

import asyncio
import os

# AutoGen imports - for creating AI agent teams
from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.conditions import MaxMessageTermination
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_ext.models.openai import OpenAIChatCompletionClient

# Memori import - for giving agents memory
from memori import Memori

# For loading environment variables
from dotenv import load_dotenv

load_dotenv()
print("All libraries imported successfully!")

Step 2: Initialize Memory System

This is the magic step! We create a memory system that will automatically record and remember all conversations.

# Create the memory system - this is where all conversations will be saved
memory = Memori(
    database_connect="sqlite:///consulting_memory.db",  # Local database file
    auto_ingest=True,        # Automatically save all conversations
    conscious_ingest=True,   # AI decides what's important to remember
    verbose=False,           # Set to True to see what's happening behind the scenes
    namespace="consulting"   # Separate memory space for this project
)

# Enable the memory system
memory.enable()

print("Memory system initialized!")
print("Database: consulting_memory.db")
print("Auto-recording enabled - all conversations will be remembered!")

Step 3: Create AI Agents

Now let's create our consulting team! We'll make two AI agents with different expertise.

# Set up the AI model (OpenAI GPT-4o-mini)
model_client = OpenAIChatCompletionClient(
    model="gpt-4o-mini",
    api_key=os.getenv("OPENAI_API_KEY"),
)

# Create Alex - Technical Architect
alex = AssistantAgent(
    name="Alex",
    model_client=model_client,
    system_message="""You are Alex, a Senior Technical Architect.

    You have persistent memory and remember:
    - Client requirements and constraints
    - Technical decisions made in past conversations
    - Budget and timeline discussions

    Always reference previous conversations when relevant.
    Keep your responses focused and practical.""",
)

# Create Sam - Full-Stack Developer
sam = AssistantAgent(
    name="Sam",
    model_client=model_client,
    system_message="""You are Sam, a Senior Full-Stack Developer.

    You have persistent memory and remember:
    - Client's technical preferences and team skills
    - Implementation decisions from past discussions
    - Development approaches we've recommended

    Build upon previous conversations and maintain consistency.
    Focus on practical implementation advice.""",
)

print("Alex (Technical Architect) created")
print("Sam (Full-Stack Developer) created")
print("Both agents have persistent memory enabled!")

Step 4: Create the Team of Agents

Let's put our agents together in a team that can collaborate on client problems.

# Create a team where agents take turns (round-robin)
consulting_team = RoundRobinGroupChat(
    participants=[alex, sam],  # Our two agents
    termination_condition=MaxMessageTermination(max_messages=6)  # Stop after 6 messages
)

print("Consulting team created!")
print("Team members: Alex (Architect) + Sam (Developer)")
print("They'll take turns responding to client questions")

Step 5: First Consultation - Setting Requirements

Let's simulate our first client meeting where they share their project requirements.

# First client conversation - gathering requirements
client_request_1 = """
Hi team! I'm Sarah, and I'm building a new e-commerce platform for my retail business.

Here are my requirements:
- Need to handle 10,000+ products
- Process payments securely
- Manage inventory in real-time
- My budget is $50,000
- My team knows React and Python well
- We prefer modern, maintainable technology

What architecture would you recommend?
"""

print("CLIENT REQUEST 1: Initial Requirements")
print("=" * 50)
print(client_request_1)
print("=" * 50)
print("\nTeam Response:")

# Run the team conversation
result_1 = await consulting_team.run(task=client_request_1)

# Show the team's response
for i, message in enumerate(result_1.messages, 1):
    print(f"\n{i}. {message.source}: {message.content[:300]}...")

Step 6: Follow-up Consultation - Database Decision

Now let's see the magic of memory! The client asks a follow-up question, and our agents should remember the previous conversation.

# Second client conversation - building on previous discussion
client_request_2 = """
Great recommendations from our last meeting! 

Now I'm concerned about the database choice. Given our product catalog size 
and the budget constraints we discussed, what specific database solution 
would work best for our e-commerce platform?

Also, how should we handle the inventory tracking?
"""

print("CLIENT REQUEST 2: Database & Inventory (Notice: References previous meeting!)")
print("=" * 50)
print(client_request_2)
print("=" * 50)
print("\nTeam Response (with memory of previous conversation):")

# Run the team conversation - they should remember the $50K budget and 10K+ products
result_2 = await consulting_team.run(task=client_request_2)

# Show the team's response
for i, message in enumerate(result_2.messages, 1):
    print(f"\n{i}. {message.source}: {message.content[:300]}...")

Step 7: Third Consultation - Development Approach

Let's test the memory even more! The client asks about development approach, referencing team size and timeline that weren't explicitly mentioned before.

# Third client conversation - development strategy
client_request_3 = """
Perfect! The database recommendations make sense.

Now for the development approach - should we build this as a monolith first 
or go straight to microservices? 

Remember, we have a small team (just 3 developers) and need to launch in 6 months.
Also, keep in mind our React and Python skills that I mentioned earlier.
"""

print("CLIENT REQUEST 3: Development Approach (References team skills from first meeting!)")
print("=" * 50)
print(client_request_3)
print("=" * 50)
print("\nTeam Response (should remember React/Python skills + budget):")

# Run the team conversation - they should remember all previous context
result_3 = await consulting_team.run(task=client_request_3)

# Show the team's response
for i, message in enumerate(result_3.messages, 1):
    print(f"\n{i}. {message.source}: {message.content[:300]}...")

Step 8: Check What's in Memory

Let's peek behind the scenes and see what our memory system has learned!

# Let's see what the memory system has learned
print("MEMORY SYSTEM ANALYSIS")
print("=" * 40)

try:
    # Get memory statistics
    stats = memory.get_memory_stats()

    print(f"Total conversations recorded: {stats.get('total_conversations', 0)}")
    print(f"Total memories stored: {stats.get('total_memories', 0)}")
    print(f"Database location: consulting_memory.db")
    print(f"Namespace: consulting")

except Exception as e:
    print(f"Memory stats not available: {e}")

print("\nAll conversations have been automatically saved!")
print("If you restart this notebook and run the agents again,")
print("   they will remember everything from today's conversations.")

Step 9: Test Memory Persistence

Let's test if our agents truly remember by asking them directly what they learned about the client.

# Test memory recall
memory_test = """
Hey team, I want to make sure we're all on the same page.

Can you remind me of my key project requirements and the decisions 
we've made so far? I want to make sure nothing was missed.
"""

print("MEMORY TEST: What do you remember about our project?")
print("=" * 50)
print(memory_test)
print("=" * 50)
print("\n Team's Memory Recall:")

# Run the memory test
result_test = await consulting_team.run(task=memory_test)

# Show what they remember
for i, message in enumerate(result_test.messages, 1):
    print(f"\n{i}. {message.source}: {message.content[:400]}...")

print("\nAmazing! The agents remembered the key details from all our conversations!")

Congratulations! You've Built Memory-Enhanced AI Agents!

What you accomplished:

Created AI agents that work together as a team
Gave them persistent memory using Memori
Ran multiple conversations that build on each other
Saw how memory makes conversations more helpful

Key insights from this demo:

Memory makes agents smarter: They remembered budget ($50K), team skills (React/Python), and project constraints
Conversations build naturally: Each discussion referenced previous context
Zero manual work: Memori automatically captured and used relevant information
Persistent across sessions: Restart the notebook and the agents will still remember!

Real-world applications:

Customer Support: Remember customer history and preferences
Project Management: Track decisions, requirements, and progress
Personal Assistant: Remember your preferences and past conversations
Educational Tutoring: Track student progress and learning style
Medical Consultation: Remember patient history and treatment plans

Running the Complete Example

Here's the complete code that you can copy and run as a single Python script:

import asyncio
import os
from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.conditions import MaxMessageTermination
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_ext.models.openai import OpenAIChatCompletionClient
from memori import Memori
from dotenv import load_dotenv

async def main():
    load_dotenv()

    # Initialize Memori
    memory = Memori(
        database_connect="sqlite:///consulting_memory.db",
        auto_ingest=True,
        conscious_ingest=True,
        verbose=False,
        namespace="consulting"
    )
    memory.enable()

    # Create model client
    model_client = OpenAIChatCompletionClient(
        model="gpt-4o-mini",
        api_key=os.getenv("OPENAI_API_KEY"),
    )

    # Create agents
    alex = AssistantAgent(
        name="Alex",
        model_client=model_client,
        system_message="You are Alex, a Senior Technical Architect with persistent memory...",
    )

    sam = AssistantAgent(
        name="Sam",
        model_client=model_client,
        system_message="You are Sam, a Senior Full-Stack Developer with persistent memory...",
    )

    # Create team
    consulting_team = RoundRobinGroupChat(
        participants=[alex, sam],
        termination_condition=MaxMessageTermination(max_messages=6)
    )

    # Run conversations
    client_requests = [
        "Hi team! I'm Sarah, building an e-commerce platform...",
        "Great recommendations! Now about the database choice...",
        "Perfect! Now for development approach - monolith or microservices?"
    ]

    for i, request in enumerate(client_requests, 1):
        print(f"\n=== CLIENT REQUEST {i} ===")
        result = await consulting_team.run(task=request)
        for j, message in enumerate(result.messages, 1):
            print(f"{j}. {message.source}: {message.content[:200]}...")

if __name__ == "__main__":
    asyncio.run(main())

Save this as a Python file and run it to see the memory-enhanced agents in action!

Why Use SQL Databases for AI Agent Memory

Bobur Umurzokov — Sat, 13 Sep 2025 09:26:25 +0000

Why SQL databases are the best choice for AI Agent Memory. Because SQL is everywhere, it’s transparent, it’s cheap, and it just works.

If you want AI Agents to remember past chats, user preferences, or important facts, you need to give them memory. So how do we store memory for AI agents?

There are many options: some people use vector databases, some use JSON files, and others use custom storage. But one of the best and simplest options is using a SQL database. Let's explore why in this article.

Most Database Are SQL Based

SQL has been powering the world's applications for 50+ years. From mobile apps to web platforms, almost everything runs on a SQL engine like SQLite, PostgreSQL, or MySQL.

SQLite alone has over 4 billion active deployments, powering every iPhone, Android device, and web browser.
SQL databases handle trillions of queries daily across industries.
PostgreSQL has been ranked the #1 most-loved database in developer surveys for several years.
MySQL still drives over 30% of the web's databases, including some of the world's largest e-commerce platforms.
SQLite processes trillions of transactions per day inside browsers and mobile apps without dedicated servers.
SQL is the foundation for mission-critical systems in finance (stock exchanges), healthcare (EHR systems), government (tax systems), and telecoms (billing platforms).
SQL's ACID compliance ensures data integrity even during power failures or crashes, something vector databases still struggle with.

If SQL can run mission-critical apps at a global scale, why not use it for AI memory?

SQL Is Great for Storing Structured Memory

AI agent memory often stores and looks for the following information:

Who the user is
What the agent and user talked about
What tasks were done
What was said, when, and why

All of this is structured data: facts, preferences, skills, rules, and relationships. And SQL is made for that. With SQL, you can easily store, search, and update this kind of information. This mirrors how humans store short-term and long-term memory, with rules and preferences kept permanently.

SQL Makes It Easy to Search and Filter

With SQL, memory is transparent and queryable. Let's say your agent needs to answer:

"What did I ask you last week about my project?"

If you use a SQL database, you can run a simple query like:

SELECT * FROM memory
WHERE user = 'Alice'
AND topic = 'project'
AND timestamp >= last_week;

Boom. Instant answer, and this gives you direct control. With SQL, you get precise queries, relationship handling via joins, and easy backups. One of the biggest pain points with vector databases is debugging and selective recall. You often don't know why a memory was retrieved.

SQL Is Cheaper Than Vector Databases

Vector databases are powerful, but they can also be very expensive to operate. You're not just paying for storage you're also paying for:

Token embedding generation costs (converting text to vectors).
Specialized vector storage fees, which are higher than SQL storage.
Similarity search queries, which get more expensive as your memory grows.
Extra infrastructure like Redis caches, orchestration layers, and sometimes even separate graph databases to handle relationships.

With SQL, all of that disappears. You just use a regular PostgreSQL, MySQL, or SQLite database. Many are free, and managed versions on AWS, Azure, or Supabase/Postgres cost only a few dollars per month.

Cost Comparison

The numbers below come from benchmark tests of SQL-based memory vs. other popular vector DB solutions:

Scale (Memories)	Memori (SQL)	Vector DB	Savings
10K (Startup)	$45	$250	82%
100K (Small)	$140	$470	70%
1M (Medium)	$1,050	$2,200	52%
10M (Large)	$8,500	$15,000	43%

Here's what these numbers mean:

At the startup level (10K memories), using SQL costs about the same as a nice dinner out $45/month while vector DBs cost more than 5x higher ($250/month). That's a big difference for early-stage projects.
At the enterprise level (10M memories), the savings still hold strong. SQL memory comes in at $8.5K/month, while vector DBs hit $15K/month. That's a savings of over $6,500 every month.

Storage Efficiency

Another hidden cost is storage. Each memory stored in SQL is compact because it's just structured JSON + metadata:

SQL memory ≈ 2.8 KB per entry
Vector DB memory ≈ 9 KB per entry

That's about 70% smaller footprint.

At scale, this matters:

1M memories in SQL ≈ 2.8 GB
1M memories in a Vector DB ≈ 9.2 GB

Not only does SQL save on disk space, but cloud providers charge for every gigabyte.

SQL DBs are Easy to Deploy and Manage Infrastructure

Another reason SQL works so well for AI memory is that the infrastructure is simple.

With SQLite, you don't even need a server, just a single file that works out of the box.
With PostgreSQL or MySQL, you can spin up a managed instance on any major cloud provider in minutes.
Scaling is straightforward: vertical scaling for smaller projects, sharding or replication for larger deployments.
SQL databases come with decades of tooling: monitoring dashboards, migration tools, backup systems, and admin interfaces.

Compare this to vector databases, which often require running specialized clusters, caches, and custom APIs just to keep things stable.

Deployment Complexity Comparison

Aspect	SQL Database	Vector Database
Setup Time	Minutes (1–2 lines of code)	Hours to days
Services Required	1 (DB only)	3–5 (Vector + Cache + SQL + Orchestration)
Portability	Single `.db` file / serverless instance	Complex export/import
Cloud Options	Universal (AWS, Azure, GCP, Supabase, Neon)	Limited or proprietary
Learning Curve	1 day (SQL is universal)	1–2 weeks to learn APIs

This means you can go from idea → running an AI agent with memory in a single afternoon, without wrestling with infrastructure. SQL keeps the boring parts boring, which is exactly what you want when deploying memory at scale.

With GibsonAI, Neon, or Supabase, you can:

Create a branch of your database for testing without affecting production.
Scale storage and compute independently, so you only pay for what you use.
Integrate directly with AI frameworks using standard Postgres drivers.

SQL Is Easy to Debug and Maintain

If something goes wrong in your AI agent's memory, it's easy to see why in a SQL table.

You can open your database and read the memory yourself.

Unlike black-box systems in vector DBs, SQL is transparent. Developers can:

See what the agent remembered
Check if memory is being saved correctly
Fix mistakes easily
Run a quick query to find exactly which conversations or facts were stored
Export or back up the entire memory with a single command like:

cp memory.db backup.db

This simplicity stands in sharp contrast to vector-based solutions, which often require multiple services (vector DB + cache + SQL) just to function.

Maintenance Comparison

Task	SQL Memory (Memori)	Vector DB Solutions
Backup	Copy DB file (`cp`)	Proprietary export API
Schema Update	`ALTER TABLE`	Re-index embeddings
Debugging	Direct `SELECT` query	Opaque similarity search
Deployment	Single DB file	Multi-service cluster
Transparency	Full audit trail	Limited / none

Additional benefits of SQL's simplicity:

Portability: You can move a SQLite file from one machine to another without setup.
Auditability: Every decision the AI makes can be traced back to stored rows.
Compliance Ready: Industries like finance and healthcare require audit logs and explainability. SQL provides both by default.
Universality: Works anywhere from local development on your laptop to cloud-scale PostgreSQL clusters.

When Not to Use SQL

Of course, SQL isn't perfect for every scenario. While it shines in structured memory, transparency, and cost efficiency, there are still cases where vector databases or hybrid approaches make sense.

You might still want a vector DB if you need:

Pure semantic similarity search
- Example: "Find text passages that are most similar to this paragraph" without relying on keywords or entities.
- SQL can approximate this with full-text search (FTS), but it's not designed for cosine similarity across high-dimensional embeddings.
Real-time embeddings for multimedia
- If your AI system needs to instantly process and compare images, audio, or video in vector form, SQL isn't the best tool.
- Vector DBs are optimized for these workloads and support multimodal embeddings.
Massive distributed scale
- SQL databases handle millions, even tens of millions, of records well, but when you reach hundreds of millions (100M+) or billions, distributed vector DBs can offer better performance across clusters.
- This scale is usually only required by global search engines, huge SaaS products, or social networks.
Real-time similarity matching at high volume
- If your system needs to process millions of similarity queries per second, vector indexes like HNSW or IVF can outperform SQL in raw throughput.

Final Thoughts

AI is moving fast, but sometimes the best technology is the one we already have. SQL databases have powered the world's apps for decades. Now, they can power AI memory too. By storing conversations, facts, and preferences in SQL, we make AI agents more useful, more trustworthy, and more affordable.

By using SQL databases, you get:

Proven technology trusted everywhere.
Structured memory with facts, rules, and preferences.
Easy querying with standard SQL.
Lower costs—up to 80–90% savings.
Transparency and auditability for compliance.

Need help getting started? Try Memori — it's an open-source memory layer that works with any SQL database. Zero setup. Automatic memory. Smart agents.

How to build an OpenAI Agent with persistent memory

Bobur Umurzokov — Wed, 27 Aug 2025 10:19:41 +0000

This guide shows how to add persistent memory to your OpenAI Agents using Memori, an open-source memory engine that makes AI agents remember conversations and learn from past interactions.

AI memory for customer support chats

Stop making customers repeat themselves. Add memory so AI remembers, learns, and supports like a human.
🔗 https://www.chatmemory.ai

What You'll Learn

In this example, we'll build a memory-enhanced assistant that can:

Remember Past Conversations - Keep track of what you've talked about before
Learn Your Preferences - Remember what you like and don't like
Search Memory - Find relevant information from previous chats
Store New Information - Save important details for future use

How Memori Works

Memori gives your AI agents two types of memory:

Short-term Memory (Conscious Mode) - Like keeping important info in your head that you use often
Long-term Memory (Auto Mode) - Like searching through all your past conversations when you need specific information

Think of it like having a personal assistant who never forgets anything you've told them!

Prerequisites

Before running this cookbook, you need:

1. OpenAI Account

Sign up at OpenAI if you don't have an account
Get your API key from the OpenAI API Keys page

2. Install Required Packages

We'll install these packages:

memorisdk - The Memori memory engine
openai-agents - OpenAI's agent framework
python-dotenv - For environment variable management

3. Create a .env file with your OpenAI API Key

OPENAI_API_KEY=sk-your-openai-key-here

Environment Setup

First, we will install the necessary packages and set up our environment.

Install Required Packages

# Install required packages
pip install memorisdk openai-agents python-dotenv

Import Libraries and Initialize

import os
import asyncio
from dotenv import load_dotenv
from textwrap import dedent

# Import Memori for memory capabilities
from memori import Memori, create_memory_tool

# Import OpenAI Agents SDK
from agents import Agent, Runner, function_tool

# Load environment variables
load_dotenv()

print("All packages imported successfully!")
print("Memori + OpenAI Agents integration ready!")

Initialize Memori Memory System

Next, we will set up Memori to give our agent persistent memory. We'll use both conscious and auto modes for the best experience.

print("Initializing Memori memory system...")

# Initialize Memori with both conscious and auto memory modes
memory_system = Memori(
    database_connect="sqlite:///cookbook_memory.db",  # Local SQLite database
    conscious_ingest=True,  # Short-term working memory
    auto_ingest=True,       # Dynamic memory search  
    verbose=False,          # Less debug output
    namespace="cookbook_demo",  # Organize memories by project
)

# Enable the memory system
memory_system.enable()

print("Memory system initialized!")
print("Memory database: cookbook_memory.db")
print("Namespace: cookbook_demo")

Create Memory Tools

Now we can create function tools that let our agent search and store memories. These tools give the agent the ability to remember and recall information.

# Create the built-in memory search tool
memory_tool = create_memory_tool(memory_system)

@function_tool
def search_memory(query: str) -> str:
    """
    Search the agent's memory for past conversations, user preferences, and information.
    Use this to find relevant context from previous interactions.

    Args:
        query: What to search for in memory (e.g., "user's name", "favorite color", "Python projects")

    Returns:
        str: Search results from the agent's memory
    """
    try:
        if not query.strip():
            return "Please provide a search query"

        print(f"Searching memory for: {query}")

        # Use Memori's memory tool to search
        result = memory_tool.execute(query=query.strip())
        return result if result else "No relevant memories found"

    except Exception as e:
        return f"Memory search error: {str(e)}"


@function_tool  
def remember_user_info(info: str) -> str:
    """
    Remember important information about the user for future conversations.
    Use this when the user shares preferences, goals, or other important details.

    Args:
        info: The information to remember (e.g., "User's name is Alice", "Prefers Python over JavaScript")

    Returns:
        str: Confirmation of what was remembered
    """
    try:
        print(f"Storing user info: {info}")

        # Store in Memori's memory system
        memory_system.record_conversation(
            user_input=f"User shared: {info}", 
            ai_output=f"I'll remember that: {info}"
        )

        return f"Remembered: {info}"

    except Exception as e:
        return f"Error storing information: {str(e)}"


print("Memory tools created successfully!")
print("Available tools:")
print("   - search_memory: Find past conversations and preferences")
print("   - remember_user_info: Store new information about the user")

Create the Memory-Enhanced Agent

Now let's create an OpenAI Agent that has access to persistent memory. This agent will be able to remember past conversations and provide personalized responses.

# Create the memory-enhanced OpenAI Agent
memory_agent = Agent(
    name="Memory-Enhanced Assistant",
    instructions=dedent(
        """
        You are a helpful AI assistant with persistent memory capabilities. You can remember
        past conversations and user preferences across different chat sessions.

        Your memory abilities:
        1. search_memory: Search for relevant past conversations, user preferences, 
           and any information from previous interactions
        2. remember_user_info: Store important information about the user

        Guidelines for using memory:
        - ALWAYS start by searching your memory for relevant context before responding
        - When users share important information (name, preferences, goals, projects), 
          use remember_user_info to store it
        - Be conversational and personalize responses based on remembered information
        - Reference past conversations naturally when relevant
        - If this seems like a first conversation, introduce your memory capabilities

        Be helpful, friendly, and make good use of your memory to provide personalized assistance!
        """
    ),
    model="gpt-4o-mini",
    tools=[search_memory, remember_user_info],
)

print("Memory-Enhanced Assistant created!")
print("This agent can:")
print("   - Remember past conversations")
print("   - Learn your preferences")
print("   - Search through memory")
print("   - Provide personalized responses")

Helper Function for Agent Interaction

It is time to create a helper function that processes user input through our memory-enhanced agent and automatically stores the conversation in memory.

async def chat_with_memory_agent(user_input: str) -> str:
    """
    Process user input through the memory-enhanced agent and store the conversation.

    Args:
        user_input: What the user said

    Returns:
        str: The agent's response
    """
    try:
        print(f"Processing: {user_input[:50]}{'...' if len(user_input) > 50 else ''}")

        # Run the agent with the user input
        result = await Runner.run(memory_agent, input=user_input)

        # Get the response content
        response_content = result.final_output if hasattr(result, "final_output") else str(result)

        # Store the conversation in Memori's memory system
        memory_system.record_conversation(
            user_input=user_input, 
            ai_output=response_content
        )

        return response_content

    except Exception as e:
        error_msg = f"Sorry, I encountered an error: {str(e)}"
        print(f"Error: {error_msg}")
        return error_msg

print("Chat function ready!")

Demo 1: First Conversation - Building Memory

Start with a first conversation where we introduce ourselves and share some preferences. The agent will remember this information for future interactions.

print("Demo 1: First Conversation - Building Memory")
print("=" * 50)

# First conversation - introducing ourselves
user_message = "Hi! I'm Alice and I'm a Python developer. I love working with data science and I'm currently learning about AI agents."

print(f"User: {user_message}")
print("\nAssistant (thinking...)\n")

response = await chat_with_memory_agent(user_message)
print(f"Assistant: {response}")

Demo 2: Second Conversation - Memory in Action

Now let's have another conversation and see how the agent uses the memory from our previous interaction to provide personalized responses.

print("\nDemo 2: Second Conversation - Memory in Action")
print("=" * 50)

# Second conversation - asking for help
user_message = "Can you help me with a project? I want to build something cool but I'm not sure what."

print(f"User: {user_message}")
print("\nAssistant (thinking...)\n")

response = await chat_with_memory_agent(user_message)
print(f"Assistant: {response}")

Demo 3: Adding More Preferences

Let's add more information to our memory by sharing additional preferences.

print("\nDemo 3: Adding More Preferences")
print("=" * 50)

# Adding more preferences
user_message = "I also love using Jupyter notebooks for my data analysis work, and I prefer using pandas and matplotlib for visualization. I'm working on a machine learning project about predicting house prices."

print(f"User: {user_message}")
print("\nAssistant (thinking...)\n")

response = await chat_with_memory_agent(user_message)
print(f"Assistant: {response}")

Demo 4: Testing Memory Recall

Now we can test how well the agent remembers our previous conversations by asking about something we mentioned earlier.

print("\nDemo 4: Testing Memory Recall")
print("=" * 50)

# Testing memory recall
user_message = "What do you remember about my current projects and interests?"

print(f"User: {user_message}")
print("\nAssistant (thinking...)\n")

response = await chat_with_memory_agent(user_message)
print(f"Assistant: {response}")

Demo 5: Memory-Based Recommendations

Finally, let's see how the agent uses accumulated memory to provide personalized recommendations.

print("\nDemo 5: Memory-Based Recommendations")
print("=" * 50)

# Getting personalized recommendations
user_message = "I have some free time this weekend. What would you recommend I work on or learn about?"

print(f"User: {user_message}")
print("\nAssistant (thinking...)\n")

response = await chat_with_memory_agent(user_message)
print(f"Assistant: {response}")

Interactive Chat Session

Create an interactive chat session where you can talk with the memory-enhanced agent directly. The agent will remember everything from this conversation for future sessions.

async def interactive_chat():
    """
    Interactive chat session with the memory-enhanced agent.
    """
    print("\nInteractive Chat Session Started!")
    print("=" * 50)
    print("Start chatting with your memory-enhanced assistant!")
    print("Try asking about previous conversations or sharing new information.")
    print("Type 'quit', 'exit', or 'stop' to end the session.\n")

    conversation_count = 0

    while True:
        try:
            # Get user input
            user_input = input("You: ").strip()

            # Check for exit commands
            if user_input.lower() in ["quit", "exit", "stop", "bye"]:
                print("\nAssistant: Goodbye! I'll remember our conversation for next time.")
                break

            if not user_input:
                continue

            conversation_count += 1
            print(f"\nAssistant (thinking... #{conversation_count})")

            # Get response from memory-enhanced agent
            response = await chat_with_memory_agent(user_input)

            print(f"Assistant: {response}\n")

        except KeyboardInterrupt:
            print("\n\nAssistant: Goodbye! I'll remember our conversation for next time.")
            break
        except Exception as e:
            print(f"\nError: {str(e)}")
            print("Please try again.\n")

    print("\nSession Summary:")
    print(f"   - Conversations: {conversation_count}")
    print(f"   - Memory database: cookbook_memory.db")
    print(f"   - Namespace: cookbook_demo")
    print("\nAll conversations are saved and will be available in future sessions!")

# Start the interactive chat (uncomment the line below to run)
# await interactive_chat()

print("Interactive chat function ready!")
print("Uncomment the line above and run the cell to start chatting!")

Memory Statistics and Inspection

Let's look at what's been stored in our memory system and get some statistics about our conversations.

print("Memory System Statistics")
print("=" * 50)

try:
    # Get memory statistics
    stats = memory_system.get_memory_stats()
    print(f"Memory Statistics:")
    for key, value in stats.items():
        print(f"   - {key}: {value}")
except Exception as e:
    print(f"Memory stats not available: {str(e)}")

print("\nSearching for stored preferences...")
try:
    # Search for user preferences
    preferences = memory_tool.execute(query="user preferences python data science")
    print(f"Found preferences:\n{preferences}")
except Exception as e:
    print(f"Error searching memory: {str(e)}")

print("\nMemory Database Information:")
print("   - Database file: cookbook_memory.db")
print("   - Namespace: cookbook_demo")
print("   - Conscious mode: Enabled (short-term memory)")
print("   - Auto mode: Enabled (dynamic search)")

Real-World Use Cases

Here are some practical applications where Memori + OpenAI Agents can be powerful:

1. Personal Assistant

Remember your daily routines, preferences, and goals
Track ongoing projects and deadlines
Provide personalized recommendations

2. Customer Support Agent

Remember customer history and preferences
Track previous issues and solutions
Provide consistent, personalized support

3. Learning Companion

Remember what you've learned and what you're struggling with
Track your learning progress over time
Suggest next steps based on your learning journey

4. Code Review Assistant

Remember your coding style and preferences
Track patterns in your code reviews
Learn from past feedback to improve suggestions

5. Research Assistant

Remember your research topics and interests
Track papers you've read and want to read
Connect related research across different sessions

Conclusion

Congratulations! You now have a memory-enhanced AI agent that can remember conversations, learn preferences, and provide personalized assistance across sessions. This is just the beginning of what's possible with persistent memory in AI agents!

Next Steps

Explore More Examples: Check out Memori's GitHub for more integration examples
Production Setup: Use PostgreSQL or MySQL for production applications
Custom Tools: Create specialized memory tools for your specific use case
Multi-Agent Systems: Share memory between multiple agents

Resources

Memori Documentation: gibsonai.github.io/memori
GitHub Repository: github.com/gibsonai/memori
Discord Community: gibsonai.com/discord

AI Apps with memory or without

Bobur Umurzokov — Wed, 13 Aug 2025 09:00:23 +0000

How does memory change AI conversations? Why do agents need memory even more than assistants?

When you chat with AI, for example, using ChatGPT, conversations are often stateless. Every interaction requires you to repeat context, preferences, and background information. You tell it your name, your preferences, your plans but next time you talk to it (or you initiate a new chat), it forgets everything that was in the past. That’s because most AI apps today don’t have memory.

Let’s explore why memory matters for AI, and how memory tools can make your AI apps (and agents!) smarter, more helpful, and more human-like.

Why AI Apps Need Memory

When we say “memory,” we mean the app can save important facts from earlier and use them later. Just like people, AI apps need to remember things — like your name, past conversations, preferences, or important facts. Examples:

Your coffee order: “latte, no sugar”
Your timezone and language
A project summary or running to‑do list
Results from a tool call (e.g., “the API returned status=202”)

Common AI Memory Types

In common scenarios, AI remembers the following types of information:

Type	Purpose	Example
Facts	Objective information	“I use PostgreSQL for databases”
Preferences	User choices	“I prefer clean, readable code”
Skills	Abilities & knowledge	“Experienced with FastAPI”
Rules	Constraints & guidelines	“Always write tests first”
Context	Session information	“Working on e-commerce project”

AI Apps Without Memory

You have to repeat yourself every time. LLMs (Large Language Models like GPT-4 or GPT-5) don’t “remember” past chats on their own. It means you are wasting tokens and paying more to repeat the same context.
AI gives generic answers. Context windows are limited. If your history is long, parts get dropped.
It can't build long-term relationships. A memory layer stores long‑term facts and injects only the relevant bits into the next prompt.

AI Apps With Memory

Every input context is automatically remembered.
Reduces token usage and lowers costs. Usually,30% of token usage in LLM apps is spent on repeating context.
AI apps feel more personal.
Responses become more accurate. The AI improves itself every time you interact.

How AI answers improve with memory

To understand the difference better, let’s have a look at a quick example (with and without memory). Say you’re building a personal assistant app.

You say:

"My name is Sam and I live in Berlin."

Now ask:

"What’s the weather like today?"

Without Memory

The AI doesn’t remember anything from earlier.

User: What's the weather like today?
AI: Could you tell me your city?

Boring, right?

With Memory

Now let’s add memory, and the response might be:

AI: The weather in Berlin today is sunny with a high of 25°C. Have a great day, Sam!

Boom 💥 — now the AI feels personal and useful.

Example Code: No memory vs With Memory

Below are two tiny examples showing the difference in Python. For the LLM, use any provider you like (OpenAI, etc.). I’ll show a simple code snippet to keep focus on memory.

No Memory

from openai import OpenAI

# Create OpenAI client
client = OpenAI(api_key="YOUR_OPENAI_API_KEY")

# Repeating context every single time
response_no_memory = client.chat.completions.create(
    model="gpt-4",
    messages=[
        {"role": "system", "content": "You are a Python expert. I use FastAPI, PostgreSQL, prefer clean code..."},
        {"role": "user", "content": "Remember, I work on microservices, use Docker, my teammate is Mike..."},
        {"role": "user", "content": "Help me with authentication"}
    ]
)

print("=== Without Memory ===")
print(response_no_memory.choices[0].message.content)

With Memory

Your AI remembers important facts across conversations. Once you’ve mentioned them, you don’t need to repeat them*.* Now, let's use Memori, a simple open-source Python library, to give your AI persistent memory across sessions.

from memori import Memori

# Enable Memori to automatically record all conversations
memori = Memori(conscious_ingest=True)
memori.enable()

# Context automatically injected from memory
response = completion(
    model="gpt-4",
    messages=[
        {"role": "user", "content": "Help me with authentication"}
    ]
)

print("=== With Memory ===")
print(response_no_memory.choices[0].message.content)

# ✨ Memori already knows:
# FastAPI, PostgreSQL, prefers clean code,
# works on microservices, uses Docker,
# teammate is Mike

What happens with this change, the model remembers your stack and preferences via Memori and jumps straight to the right solution. AI knows that you’re using FastAPI with PostgreSQL in a microservices setup and deploy via Docker, it recommends JWT auth with OAuth2 password flow.

You can run and try this example by following the 🔗Memori Personal Assistant demo. It’s a great starting point for adapting the with memory code above into your own AI assistant

Why AI Agents Need Memory Even More

Agents especially need memory because they break work into steps and often call tools or other agents:

Plan the task
Search the web
Call an API
Parse results
Write a draft
Review and fix
Maybe more…

Without memory, each step loses the previous step’s key facts, leading to repeated work and errors. Memory keeps those steps connected.

With memory, agents can:

Share state across steps (“we already fetched page 2, skip it”)
Learn preferences (“always use 24‑hour time”)
Recover after failure (re‑use cached results instead of re‑scraping)
Move faster (less repeated prompting and tool calls)

To see this in action with agents, check out this minimal example: 🔗 Memori + Agno integration example. It shows how to integrate persistent memory with Agno agents, so your agents can remember facts, preferences, and task results across runs, making multi-step workflows more consistent and efficient.

Real Examples: How AI Agents Use Memory Today

AI agents with memory are already being used in the real world — from smart customer support to research assistants and personal AI companions. Companies like Intercom and Drift are now using AI bots with memory to remember past tickets, know your account tier and track unresolved issues. Or Rewind.ai is building a personal AI that remembers everything you’ve seen, said, or heard — by recording your screen and transcribing conversations.

Want to see how memory can power real AI apps and agents? Check out Memori’s Use Case Gallery — including examples for:

Smart shopping experience for e-commerce.
Customer support bots
AI research assistants
Personalized chatbots

Summary

AI without memory is like starting from scratch every time — you must repeat the same context in each conversation, which wastes tokens, increases costs, and results in inconsistent answers. With memory, important details are automatically remembered, reducing token usage, lowering costs, and ensuring consistent, personalized experiences.

For AI agents, memory is even more critical. Without it, agents can’t track progress, often repeat steps, and lose sight of important goals. With memory, agents coordinate better, learn from past mistakes, and steadily improve over time.

What the AI Coding Experience Senior Software Engineers want

Bobur Umurzokov — Wed, 23 Jul 2025 09:37:00 +0000

AI coding assistants or editors, such as Cursor, Windsurf, Lovable, and GitHub Copilot, are transforming how developers write code. You can now turn an idea into a working app in minutes just by typing a few prompts. That’s exciting but also risky. Many new developers can now build features without really understanding how the code works. Can you trust what the AI writes? Will you or your team understand it later? In some cases, the AI is making big decisions about how the software architecture is built, not the developer.

Usually, Senior engineers do not jump straight into coding without considering domain knowledge, architecture or code reusability. They know when a piece of code fits and when it doesn’t. To be useful for real projects, AI tools need to give developers more structure, more control, and more ways to test and trust what gets built.

In this article, I will explore existing problems with AI-assisted coding (or some people call it vibe coding) and what the AI editor experience should look like for senior software engineers.

The first coding agent that plans, tests, and delivers reliable code like a senior engineer. Try out Verdent!

The Problem with Most AI Coding Tools Today

Windsurf, Cursor, and others have shown us that language models can write code. Most of them today aim to save time and automate routine tasks. AI can automate up to 80% of the work, but achieving 99% or higher accuracy still depends on human input. Because in the end, the most valuable part of your codebase isn’t the code. It’s the thinking behind it. Lets review some key AI coding problems.

1. The AI misunderstands your intent

The AI never fully understood what you wanted to build. You type a prompt like “create an endpoint that returns active users.” The AI confidently writes some code. But what does “active” mean in this context? Last login? Session time? Subscription status?

The AI gives you a half-right solution without understanding the full intent. If you try to provide highly detailed prompts, it is too costly with a token-based pricing model and effort-intensive for the user. Or the AI gets into loops, forgets the prompt halfway. Now you spend more time debugging code you didn’t write.

2. The AI doesn't explain its choices

Where did this API call come from? What’s the structure of this function? Why did it choose this library? These questions go unanswered because most AI tools provide output without rationale. As a result, senior developers are left auditing unfamiliar code with no insight into the assumptions or trade-offs behind it, which makes modifying the output risky. When nobody owns or understands the reasoning behind the code, the code loses its long-term maintainability.

3. No Task Structure, No Planning

Coding is not just typing. It’s decomposing a problem, making architectural decisions, and thinking through edge cases. Most vibe coding tools I tried generate code in a single block, without breaking the work down into logical steps or providing visibility into what’s been completed and what’s left.

There’s no task progress dashboard or overview of completed versus pending actions. You blindly click "Next” without knowing how much is done or left. It encourages a passive relationship with the AI, where the developer becomes a reviewer instead of a collaborator.

4. Testing Comes Too Late (Or Not At All)

AI tools rarely test what they write. If they do, it’s often surface-level. That means more bugs, more manual effort, and more risk. For senior developers shipping production code, these problems make AI feel more like a junior intern than a reliable teammate.

What Senior Developers Really Need from AI

AI tools shouldn’t just type fast. They should support the way experienced developers build and maintain software, with structure, feedback loops, and domain awareness.

1. Plan: Align Before You Code

Senior developers usually don’t jump straight into code—they clarify scope, break work into pieces, and align on what’s being built. AI tools should do the same by asking the right questions, clarifying the scope, and creating a task plan with subtasks. This Plan phase helps solve one of the biggest pain points in AI coding: misalignment.

2. Code and Verify: Don’t Just Generate but also Test, Fix, Repeat.

It’s not enough for code to compile. Every time the AI generates code, it should also verify that it works through unit tests and functional testing for different workflows.

This process should be automatic and repeatable, like a Code–Verify Loop (as it's depicted in the picture below*)*:

Generate a unit of code from a task
Verify it with tests
Debug and rewrite if it fails, and until the code passes all tests
Summarize the outcome and reasoning

3. Don’t Just Write Code — Own It

Senior developers build software that evolves with the business. That requires aligning code with business intent, domain terms, and organizational standards. To help Senior engineers, AI-generated content should come with context:

What was generated, and how does it connect to the goal
Why was this method or library chosen
What changed compared to the existing implementation
What trade-offs were made—performance vs clarity, speed vs flexibility, etc.

This level of clarity is essential, especially if you want to maintain the code for a longer period. Inline comments, code diffs, and simple changelogs should be part of the output.

4. Secure, sandboxed environments

For enterprise and professional developers, trust in tooling doesn’t just come from output quality, but it comes from how safely that output is generated.

Yet many AI tools today default to cloud-based processing, often uploading a large part of the code to external servers. For teams handling sensitive data, proprietary code, or regulated environments, this is a dealbreaker.

Code should run and test in a secure sandbox.
Avoid uploading source code to external servers
Testing should work in isolated environments, enabling experimentation without risk

The Future of AI Coding Is Collaborative

What senior engineers need is not just a typing assistant. They need a reliable, explainable, and autonomous teammate—an agent that plans before coding, tests every step, explains decisions made and adapts to the context of the project. This is how real development works. We’re not far from this future. But getting there means rethinking the entire AI coding experience and starting to build AI agents that earn their place on the team. I tried out Verdent and really liked how it plans every single task.

I'd love to hear your thoughts:

What do you expect from an AI assistant in your coding workflow?
Have you ever used AI-generated code that worked but didn’t make sense?
How do you balance speed and understanding when using AI tools in real projects?
What’s one feature you wish current AI coding tools had—but don’t?
Do you think AI tools should take part in architectural decisions? Why or why not?

Automatic PR creation on GitHub for database schema change

Bobur Umurzokov — Tue, 22 Jul 2025 06:46:08 +0000

Learn how to update database schemas using prompts with GitHub Copilot and create GitHub pull requests with matching Python model classes.

Updating a database schema as part of your development process often feels more complicated than it should be. If you’ve ever worked with tools like SQLAlchemy, Alembic, or EF Core, you probably know the drill: you first update your model classes in code, then generate a migration file, and finally apply those changes to your database. It's not a terrible process—but it's slow, easy to mess up with the correct migration order, and repetitive. You constantly have to switch contexts: from writing model code, to terminal commands, to reviewing raw SQL.

Wouldn’t it be easier if you could just describe what you want in English and let your tools handle the rest?

Let’s say we’re working on a simple travel agency database model. We already have a user table, and now we want to add an address column to store where each user lives. Instead of manually changing the SQL or model file, imagine simply typing:

“Add an address field to the user table as a string”

And immediately, the model gets updated (e.g., User class in Python, Java, C#, or JavaScript, depending on the language you use), the SQL schema is regenerated, and a pull request is opened in your GitHub repo—complete with changes and documentation.

This is exactly what we’ll walk through using GitHub Copilot chat and GibsonAI, which automates schema changes, model generation, and PR creation.

You can try to see the generated sample PR on this public repo:

Here’s a short demo that shows the workflow in VS Code:

How the Database Schema to PR Agent Works

The solution uses GibsonAI MCP Server for database operations and GitHub CLI for repository management in GitHub Copilot chat.

Here’s what happens step by step:

Describe your schema change

Example: "Add an address column to the user table as a string"
GibsonAI applies the schema change

It updates the database schema using the correct SQL syntax.
GitHub Copilot generates the Python model

Copilot clones the repository, opens a new branch and commits changed files behind the scenes. This includes Pydantic or SQLAlchemy files based on your stack, and respond from GibsonAI schema update to keep your code in sync with database changes.
GitHub Copilot opens a GitHub Pull Request

You get a PR with the updated model, schema changes, and docs.

Let's see an example of how you can make database schema changes and automatically generate corresponding Python model classes with a GitHub PR.

Step 1: Set Up Your Environment

You’ll need the following tools installed before you begin:

Visual Studio Code with GitHub Copilot enabled
UV package manager installed
GitHub CLI is installed to connect and manage your GitHub repositories from GitHub Copilot
A GibsonAI account (free) to use the database MCP server

You can also use other editors like Cursor, Windsurf, and connect to the MCP server.

Step 2: Install and Log In via CLI

Open your terminal and run:

uvx --from gibson-cli@latest gibson auth login

This logs you into the GibsonAI CLI so you can access all the features directly from your terminal and integrate it into your workflow.

Step 3: Enable the MCP Server in VS Code

To use the schema assistant inside VS Code, create a .vscode/ folder in your project and inside it, a file named mcp.json. This file tells VS Code which MCP server to run.

Paste the following configuration:

{
  "inputs": [],
  "servers": {
    "gibson": {
      "type": "stdio",
      "command": "uvx",
      "args": ["--from", "gibson-cli@latest", "gibson", "mcp", "run"]
    }
  }
}

This setup launches the server locally and connects it with Copilot Chat. If you're using other tools like Cursor or Claude Desktop, you can configure them similarly.

Step 4: Describe the Schema Change

Now, inside Copilot Chat, just say:

“Add an address column to the user table as a string”

Behind the scenes, this does four things:

Applies the schema change to a real (serverless) database using GibsonAI
Generates the updated Python model using Pydantic/SQLAlchemy
Prepares documentation for the changes
Opens a GitHub Pull Request in your connected repo

You can see an example of this in action:

🔗 Pull Request Preview

What Makes This Unique?

Compared to other AI coding assistants, this introduces a full-stack AI workflow that bridges coding, database management, and CI/CD:

Smart Migration Ordering: Automatically resolves dependencies and applies changes in the right sequence (e.g., creating tables before adding constraints).
Schema Validation: Test changes on an isolated development database before merging, preventing unexpected production issues.
Schema Diff & ERD Diagrams: Automatically generates schema diffs and ERDs in PRs, making schema change reviews faster and more visual.
Schema-Only Database Environments: Quickly spins up lightweight database environments with just schema (no production data), perfect for testing with anonymized/mock data.

Final Thoughts

This setup is cutting my dev time by around 20% when handling database schema changes. The approach doesn’t just speed up development but also reduces errors in migrations, saves time switching between tools, and brings schema evolution closer to how we already think and communicate as developers. The biggest win? Each feature branch gets its own isolated database environment.

Next time you want to update your database, try typing a prompt and feel free to leave your comments on Discord if you find this AI-assistant workflow useful.

Create schema-only database environments using AI Agents

Bobur Umurzokov — Wed, 16 Jul 2025 09:33:20 +0000

Learn how to create schema-only database environments to work with sensitive data and make zero-risk schema changes.

Why do you need multiple databases for development?

Working on a live production database during development is risky. Even the smallest mistake like dropping a column or applying an incorrect migration can lead to downtime, corrupted data, or data loss. That’s why modern teams isolate their environments: you might have a separate dev, staging, and prod database to protect production while still iterating fast.

By working in an isolated environment, you get:

A safe space to develop new features
No risk of affecting real user data
The freedom to experiment with schema changes
The ability to test integrations without breaking anything critical

Benefits of syncing only the schema

But in most cases, when you are creating a new database environment, you just want to sync the schema but not the data because of:

Compliance: You avoid sharing real customer data across environments.
Safety: Developers can’t accidentally query or mutate production data.
Speed: Schema deployments are lightweight and fast—no data copy or replication overhead.
Control: You can generate and populate a test environment with randomized or anonymized data.

This approach is ideal for GDPR-compliant workflows, regulated industries, and teams that care about velocity without compromising on security.

See the short demo of how to create schema-only database environment using GibsonAI.

What is GibsonAI?

GibsonAI is your AI-powered “database engineer” that lets you design, build, deploy, and scale production-ready serverless databases using natural-language prompts.

You can create a database schema for your new project idea using the GibsonAI App by chatting with AI. Under the hood, GibsonAI spun up a new real MySQL/Postgres database. You can create multiple database environments and update the existing schema in AI chat.

How GibsonAI Schema First Approach Works

When you define first time your database schema in the GibsonAI project, that schema becomes the source of truth for ongoing development. It is called Current Schema, and it is a safe environment where you can update or run experiments by chatting with AI. Once you are confident, you can then provision that schema to any number of databases, like prod, staging, or feat-a.

This way, each database receives the same structure, but not the same data, allowing you to test, build, or ship new features using safe, synthetic, or anonymized datasets. GibsonAI makes working with multiple database environments safe. You can see difference between the current state of the schema and deployed one in the same dashboard.

How to Create and Work with a Schema-only Environment in GibsonAI

You can create a schema-only database environment in the GibsonAI App. Imagine you're a developer building a new feature for a travel agency app. You're adding a new trip_preferences table into the existing database, and you want to test this schema without touching the production database and its data.

Here's how to do it with GibsonAI:

1. Select Your Project

Open the GibsonAI App and pick the project you're actively working on.

2. Go to Databases and Create a New Database

Head over to the Databases tab. Click Create Database, and name it something like feat-a. This becomes your feature database environment.

Newly created database has not any database schema initially. You will get empty database. But the Current schema keeps current state of the schema you are working on.

3. Update the Current Schema

Use the Schema Editor or chat with GibsonAI to add new tables, columns, or relationships—like trip_preferences.

Your schema updates live inside your project, not in the database itself. This ensures changes stay tracked and reproducible.

4. Deploy Schema to `feat-a`

Click Deploy to Database and choose your newly created feat-a database. GibsonAI will provision the latest schema structure only into the environment. You can now use AI chat to generate sample SQL insert queries to populate with data.

5. Deploy to Production When Ready

Once you're confident, deploy the same schema to the production database. Since GibsonAI doesn’t automatically sync changes between environments. You control where and when to apply the schema. This gives you the ability to test fearlessly—and ship confidently.

Summary

Schema-only database environments in GibsonAI give you a production-like structure without exposing production data. Whether you're fixing a bug, testing a new feature, or validating complex changes, you can work in isolation and still deploy with confidence.

By separating structure from data, GibsonAI empowers your team to:

Move fast without breaking production
Work safely in parallel
Stay compliant and secure

How to convert Images, PDF, Excel sheets, or JSON to a relational database with AI

Bobur Umurzokov — Tue, 01 Jul 2025 11:09:56 +0000

Creating a database usually means defining a database schema, setting up a database server, and writing SQL commands/queries. But what if you could skip all that?

Recently, I needed to recreate a new database from an old ER diagram in PNG format. Instead of writing everything manually in SQL, I tried something faster — using GitHub Copilot inside VS Code, along with GibsonAI to validate and deploy it. It worked surprisingly well. So, AI is not only hyping topic but it helps in certain tasks. Let me show you how to achieve this.

Here’s a short demo showing the process:

This video shows how you can go from a simple diagram or screenshot to a working, deployed database using just prompts and AI tools.

Why Databases Still Slow Us Down

Many developers want to launch new apps, build MVPs, or add features to an existing product. But they hit friction when it comes to databases.

It doesn’t matter which language or framework you’re using — eventually, you’ll need a working data backend. And that’s where time gets lost:

Setting up the database and designing a schema
Adjusting the schema as your app changes
Manually building APIs and ORMs
No clean way to spin up test environments with real data
Worrying about migrations and breaking changes

A New Workflow Using AI Tools

In 2025, AI Agents can create and modify databases on their own. Now let's see how AI tools solve the following developer challenges, and we can build apps faster:

Challenge	Solution with AI
"I don’t want to spend hours setting up DB & APIs"	One prompt → working backend & API
"My data model keeps changing as I test ideas"	Schema evolution handled automatically and generate mapping data models
"I want to connect my app quickly to my data"	Apps can use live APIs with no extra infra.
"I need a testable environment with live data"	Hosted database with built-in seed and test data options
"I don’t want to manage migrations or versioning"	AI handles that under the hood

AI still is NOT replacing us or software developers, but it is removing friction. You still make the decisions about your schema and relationships. You still write the logic. But you don’t waste time repeating boilerplate steps.

Next, I will show you how I converted an existing ER diagram image to a really working database. I believe you can use the same approach with other data formats.

Convert an ER Diagram Image into a Working Database Using GibsonAI, GitHub Copilot in VS Code

Step 1: Get an ER Diagram

If you already have an ER diagram as a .png, you're good to go.

If not, you can use tools like drawdb.app to find templates for common use cases (like eCommerce, HR systems, or SaaS apps). You can quickly edit the schema, then export it as a PNG, JSON, or raw SQL. For example, let's use this music streaming app database diagram template in the demo.

That way, you don’t even need to design the schema from scratch — just adapt an existing one.

Step 2: Enable MCP Server in VS Code

What You Need

VS Code (with GitHub Copilot enabled)
UV is installed.
GibsonAI -Sign up for a free account

This tool turns your prompt into a complete schema, deploys serverless database and gives you a live REST API for managing data.

Step 3: Set Up GibsonAI CLI and Log In

Before using the GibsonAI MCP server, install GibsonAI’s CLI and log in:

uvx --from gibson-cli@latest gibson auth login

This logs you into your GibsonAI account so you can start using all CLI features.

Step 4: Enable MCP Server in VS Code

To use the GibsonAI MCP server inside your VS Code project, you’ll need to add a configuration script. Create a file called mcp.json inside an empty .vscode/folder. This file defines which GibsonAI MCP server to use for this project.

Copy and paste the following content into the .vscode/mcp.json file:

{
  "inputs": [],
  "servers": {
    "gibson": {
      "type": "stdio",
      "command": "uvx",
      "args": ["--from", "gibson-cli@latest", "gibson", "mcp", "run"]
    }
  }
}

You can also use GibsonAI MCP server with such as Cursor, Claude Desktop, Cline, and Windsurf. See the the instructions for other tools.

Step 5: Describe the diagram in a GitHub Copilot chat prompt

Open your ER diagram (or PNG file) in VS Code in the same VS Code project. Open GitHub Copilot Chat in VS Code, switch to Agent mode, and select the LLM model, such as GPT-4.1 or GPT-4o. You should see the available tools from GibsonAI.

Write a prompt like:

Create a new GibsonAI database from this ER diagram

GitHub Copilot reads the comment and starts calling the relevant GibsonAI MCP server tools.

Step 6: Inspect Your Database Schema in the GibsonAI Dashboard

After the prompt runs successfully, go and inspect your new schema in the GibsonAI dashboard. You’ll see everything laid out — tables, columns, relationships — just like in your diagram, with additional improvement, but now fully working and hosted.

From there, you can continue evolving your schema:

Prompt more to customize the schema using natural language. Or switch to writing real SQL queries if you prefer — Studio let you write and run queries directly in your browser. You’ll also see a live ERD diagram update with every change you make.

Wrap-up

In this workflow, I went from an ER diagram image to a live serverless MySQL database — all in just a few minutes.

What surprised me is that the AI tool didn’t just create the schema — it also generated fully working CRUD APIs for each model. These APIs include things like request validation and response schemas, so you can start using them immediately.

This is really helpful if you want to interact with your database directly from your app, without having to build and manage all the data models yourself.

Create a Database Schema and REST APIs with a Single Prompt Using GitHub Copilot in VS Code

Bobur Umurzokov — Wed, 11 Jun 2025 09:05:14 +0000

Learn how to use GitHub Copilot with one AI prompt to create a fully designed database schema, deploy a serverless MySQL database, and live CRUD APIs — in under 60 seconds.

The Age of Prompt-Driven Development

A significant shift is underway in the way we develop software. AI agents and prompt-based tools are shaping modern development. As a developer, you don’t want to miss this shift. Knowing how to use these tools puts you ahead. Instead of writing endless boilerplate, you can now describe what you want, and AI will generate code, create your database, connect APIs, and even deploy your app. New tools like Cursor, Windsurf, Lovable, and Bolt are rising fast. You can create stunning apps and websites by chatting with AI.

Even with all these fancy tools, full-stack apps still need a solid backend, and that means data. Every application needs to work with data. Whether you’re building a blog, a booking platform, or an AI Agent, you’ll need to store and retrieve information. That usually means using a real database like PostgreSQL, MySQL, or MongoDB (unless you’re treating Excel or Google Sheets like a backend, which… we’ve all done once).

So schema design, database setup, and API generation can’t be skipped. I decided to experiment with automating the process of designing a database schema, running a database, and managing data using just prompts using GitHub Copilot in VS Code.

Every App Needs a Database — It’s Time to Simplify It

Working with databases is often repetitive work and slows developers down. I think the issues we always face are the following during the setup of a database from scratch:

You start with a manual schema setup

You have to create tables, think through relationships, indexes, data types, and naming. You map tables to objects using ORM libraries and build APIs to access that data. It’s easy to miss things or overcomplicate at an early stage.

Schema changes are painful

Your app evolves. You rename a column, split a table, or add a new relation. Now you need to write migrations. Update your ORM. Avoid downtime. And hope nothing breaks in staging or production.

Every change triggers more boilerplate

Once the schema changes, you usually:

Update model files
Fix serializers or DTOs
Rewrite REST API endpoints or GraphQL resolvers
Modify test data and fixtures

That’s a lot of work for just one change.

Team coordination becomes tricky

In team projects, syncing schema changes between developers often leads to merge conflicts, broken migrations, or inconsistent environments.

But now? With the rise of AI code generation tools like GitHub Copilot, you can extend Copilot Chat with the Model Context Protocol (MCP) from external providers, and you can create a fully working database schema with a single prompt — right inside VS Code.

And it’ll save you hours every week. Let me show you how you can achieve this.

Let’s Build: A Travel Agency App Schema

What You Need

VS Code (with GitHub Copilot enabled)
UV is installed.
GibsonAI -Sign up for a free account

This tool turns your prompt into a complete schema, deploys serverless database and gives you a live REST API for managing data.

Step 1: Set Up GibsonAI CLI and Log In

Before using the GibsonAI MCP server, install GibsonAI’s CLI and log in:

uvx --from gibson-cli@latest gibson auth login

This logs you into your GibsonAI account so you can start using all CLI features.

Step 2: Enable MCP Server in VS Code

To use the GibsonAI MCP server inside your VS Code project, you’ll need to add a configuration script. Create a file in your project or inside an empty folder called mcp.json in the .vscode/folder. This file defines which GibsonAI MCP server to use for this project.

Copy and paste the following content into the .vscode/mcp.json file:

{
  "inputs": [],
  "servers": {
    "gibson": {
      "type": "stdio",
      "command": "uvx",
      "args": ["--from", "gibson-cli@latest", "gibson", "mcp", "run"]
    }
  }
}

Once this file is added, GibsonAI tools inside VS Code will connect to the MCP server.

Step 3: Describe Your Travel App Schema in a Prompt

Open GitHub Copilot Chat in VS Code, switch to Agent mode, and select the LLM model, such as GPT-4.1 or GPT-4o. You should see the available tools from GibsonA

Then enter a prompt like this:

“Create a database for a travel agency. It should include tables for destinations, bookings, users, and reviews. Each user can make bookings and write reviews. Each destination has a name, description, price, and rating.”

GibsonAI reads your prompt, creates a new database project, and magically generates:

A complete relational schema
Visual Entity-Relationship Diagram (ERD)
Proper foreign key constraints
UUIDs, timestamps, and standard fields
A clean MySQL or Postgres structure

Step 4: Deploy Your Schema and Enable CRUD APIs

Go to the GibsonAI app, log in, and open your newly created project. There, you can see and review the schema. Now you can click “Deploy” to launch your schema:

Alternatively, you can use Copilot chat to deploy the database. GibsonAI hosts the serverless MySQL database. Now you can get the database connection string and connect to your existing app. Or access live CRUD APIs and use them in your app:

You now have a working backend without writing a single SQL query. You can plug these APIs directly into your frontend or backend — no need to write REST controllers for typical CRUD operations. GibsonAI also lets me share my database project schema with others.

Feel free to clone the travel agency database I created for the demo: https://app.gibsonai.com/clone/rRZ4wD9HDCdHO

Step 5: Let Copilot Help You Build Around the API

Now that your schema and API are live, use GitHub Copilot to build UI components using React or any other frontend frameworks. GitHub Copilot + GibsonAI MCP = the fastest way to go from prompt to full-featured app.

Final Thoughts

The future of development is not about using more AI-generated code. It’s about writing fewer, smarter prompts — and letting AI handle the slow, repetitive, or painful tasks so you can fully focus on the innovation. You can already boost your development workflow with GitHub Copilot Agent Mode. It will provide you with a powerful set of tools that enable agents to run SQL queries, create tables, design schemas, import CSV files, and more.

Give it a try. The next time you start a project, open VS Code, write a prompt, and let the database build itself.