AI Agents Need Databases Too: How FoundryDB Serves the Agent Era

Something fundamental shifted in how databases get created. In 2024, most database provisioning was triggered by a human clicking a button in a dashboard or running a CLI command. By early 2026, Neon reported that 80% of new databases on their platform were created by AI agents, not humans. The database is becoming infrastructure that agents provision, configure, and tear down as part of their workflows.

This changes what a managed database platform needs to provide. Agents do not use dashboards. They do not read documentation the way engineers do. They need fast, programmatic interfaces with predictable behavior. They need databases that spin up in seconds, clean themselves up when no longer needed, and integrate natively with agent frameworks.

We built FoundryDB's agent infrastructure to meet these requirements.

What Agents Need from a Database Platform

AI agents have different requirements than human operators. Understanding these differences shaped our design decisions.

Fast provisioning. An agent building a RAG pipeline needs a PostgreSQL instance with pgvector now, not in 10 minutes. When database creation is part of an agent's planning and execution loop, provisioning latency directly impacts the agent's task completion time. FoundryDB provisions from pre-built templates, with most services ready to accept connections within 2-3 minutes.

Ephemeral databases. Many agent workflows create databases for a specific task: index a document corpus, run an analysis, generate a report. When the task is done, the database should be cleaned up automatically. FoundryDB supports TTL (time-to-live) on services, so agents can create a database that auto-deletes after a specified duration.

Programmatic management. Agents interact through APIs and tool calls, not dashboards. Every FoundryDB operation is available through our REST API, CLI, TypeScript SDK, Python SDK, and MCP (Model Context Protocol) server. Agents can create, configure, query, scale, and delete databases without human intervention.

Presets for common patterns. Agents should not need to figure out which PostgreSQL extensions to enable for vector search or what Kafka topic configuration works best for event sourcing. FoundryDB provides 16 presets that pre-configure services for specific use cases. An agent says "I need a database for vector search" and gets a PostgreSQL instance with pgvector enabled, HNSW indexes configured, and appropriate resource allocation.

Metadata and labeling. When agents create dozens of databases, operators need to understand what each one is for. FoundryDB supports service labels and metadata that agents can set at creation time: agent_framework: langchain, agent_purpose: rag-pipeline, agent_run_id: abc-123.

The MCP Server

The Model Context Protocol (MCP) is becoming the standard way for LLMs and agents to interact with external tools. FoundryDB ships an MCP server that exposes database management as tool calls that any MCP-compatible agent can use.

Here is what it looks like when an agent uses the MCP server to create a database:

Agent: "Create a PostgreSQL database with pgvector for storing
        document embeddings. Use the Helsinki zone and tier-3 plan."

MCP Tool Call: foundrydb.create_service({
  name: "doc-embeddings-a3f2",
  engine: "postgresql",
  version: "17",
  plan: "tier-3",
  zone: "eu-helsinki",
  storage_gb: 50,
  preset: "pgvector",
  labels: {
    agent_framework: "claude",
    agent_purpose: "document-embeddings",
    created_by: "agent"
  },
  ttl: "24h"
})

Response: {
  id: "svc_x7k2m9p4",
  status: "provisioning",
  connection_uri: "postgresql://app_user:***@doc-embeddings-a3f2.foundrydb.com/defaultdb?sslmode=verify-full",
  estimated_ready: "2m"
}

The MCP server handles authentication, input validation, and returns structured responses that the agent can parse and act on. The agent does not need to know about REST endpoints or HTTP headers.

To configure the MCP server with Claude Desktop or any MCP-compatible client:

{
  "mcpServers": {
    "foundrydb": {
      "command": "npx",
      "args": ["@foundrydb/mcp-server"],
      "env": {
        "FOUNDRYDB_API_KEY": "your-api-key"
      }
    }
  }
}

SDK Integration

For agents built with Python or TypeScript, the FoundryDB SDKs provide typed, idiomatic interfaces for database management.

Python SDK

from foundrydb import FoundryDB

fdb = FoundryDB(api_key="your-api-key")

# Create a service with a preset
service = fdb.services.create(
    name="agent-rag-store",
    engine="postgresql",
    version="17",
    plan="tier-3",
    zone="eu-helsinki",
    storage_gb=50,
    preset="pgvector",
    labels={"agent_framework": "langchain", "agent_purpose": "rag"},
    ttl="12h",  # Auto-delete after 12 hours
)

# Wait for the service to be ready
service.wait_until_ready(timeout=300)

# Get connection details
conn_info = service.connection_info()
print(f"Connect: {conn_info.uri}")

# When the agent is done, delete immediately (or let TTL handle it)
service.delete()

TypeScript SDK

import { FoundryDB } from '@foundrydb/sdk';

const fdb = new FoundryDB({ apiKey: 'your-api-key' });

const service = await fdb.services.create({
  name: 'agent-session-cache',
  engine: 'valkey',
  version: '8.1',
  plan: 'tier-2',
  zone: 'eu-helsinki',
  storageGb: 20,
  labels: { agent_framework: 'crewai', agent_purpose: 'session-cache' },
  ttl: '6h',
});

await service.waitUntilReady();

const { host, port, password } = service.connectionInfo();
// Use the Valkey instance...

CLI for Scripting

For agents that shell out to CLI tools:

# Create and wait in one command
fdb services create \
  --name agent-workspace-$(uuidgen | head -c 8) \
  --engine postgresql \
  --version 17 \
  --plan tier-2 \
  --storage 50 \
  --zone eu-helsinki \
  --preset pgvector \
  --label agent_framework=autogen \
  --label agent_purpose=analysis \
  --ttl 4h \
  --wait \
  --output json

# List all agent-created services
fdb services list --label created_by=agent --output json

# Clean up all expired agent services (TTL handles this, but manual cleanup is available)
fdb services list --label created_by=agent --status stopped --output json \
  | jq -r '.[].id' \
  | xargs -I {} fdb services delete {}

Common Agent Architectures

Here are the most common multi-engine patterns we see agents deploying on FoundryDB.

RAG Pipeline (PostgreSQL + Valkey)

The most popular pattern. PostgreSQL with pgvector stores document embeddings. Valkey caches query results and stores conversation history. Kafka is optional for high-throughput document ingestion.

# Agent creates a complete RAG stack
vector_db = fdb.services.create(
    name="rag-vectors",
    engine="postgresql",
    preset="pgvector",
    plan="tier-4",
    storage_gb=100,
    zone="eu-helsinki",
    labels={"stack": "rag", "role": "vector-store"},
)

cache = fdb.services.create(
    name="rag-cache",
    engine="valkey",
    plan="tier-2",
    storage_gb=20,
    zone="eu-helsinki",
    labels={"stack": "rag", "role": "cache"},
)

Conversational AI (MongoDB + Valkey)

MongoDB stores conversation histories, user profiles, and tool call logs. Its flexible schema adapts to the evolving structure of agent interactions without migrations. Valkey handles session state and rate limiting.

Multi-Agent Coordination (Kafka + MongoDB + PostgreSQL)

When multiple agents collaborate (CrewAI, AutoGen, LangGraph), Kafka serves as the event bus for inter-agent communication. MongoDB stores agent state and task results. PostgreSQL handles structured data that agents query with SQL.

Ephemeral Analysis (PostgreSQL with TTL)

Data analysts use agents to create temporary databases, load datasets, run complex queries, and export results. The database auto-deletes after the analysis is complete.

# Temporary analysis database that self-destructs in 2 hours
analysis_db = fdb.services.create(
    name=f"analysis-{task_id}",
    engine="postgresql",
    plan="tier-3",
    storage_gb=50,
    zone="eu-helsinki",
    ttl="2h",
    labels={"agent_purpose": "data-analysis", "task_id": task_id},
)

Service Labels and Observability

When agents create databases autonomously, observability becomes critical. Who created this database? Why? Is it still needed? FoundryDB's label system provides the answers.

Every service supports arbitrary key-value labels. We recommend a standard set for agent-created services:

Label	Purpose	Example
created_by	Who created it	agent, human, ci-pipeline
agent_framework	Which framework	langchain, crewai, autogen, claude
agent_purpose	What it is for	rag, session-cache, analysis
agent_run_id	Specific run identifier	run_a3f2b7c1
stack	Multi-service grouping	rag-pipeline, ecommerce
environment	Deployment environment	development, staging, production

These labels are queryable through the API and visible in the dashboard. Operators can filter by created_by=agent to see all agent-provisioned databases, or by agent_framework=langchain to see databases created by a specific framework.

# Dashboard view: all agent-created services
fdb services list --label created_by=agent

# Cost tracking: total spend by agent framework
fdb billing usage --group-by label:agent_framework

# Cleanup: find agent databases older than 7 days
fdb services list --label created_by=agent --created-before 7d

Building for the Agent Era

The shift toward agent-driven database provisioning is accelerating. As agent frameworks mature and more workflows become autonomous, the database platform needs to be a first-class participant in the agent ecosystem, not an afterthought that requires human intervention.

FoundryDB's approach is to meet agents where they are: MCP for LLM-native tool use, SDKs for framework integration, presets for instant configuration, TTL for lifecycle management, and labels for observability. The database becomes another tool in the agent's toolkit, provisioned and managed as naturally as making an API call or reading a file.

Explore the AI agent infrastructure documentation to integrate FoundryDB with your agent workflows. The MCP server is available today, and the Python and TypeScript SDKs support all service management operations.