Polykomos for AI Agents

Give your agents memory, state, and structured data — in plain English.

You're reading: AI Agents Traditional / DevOps

What is natural language querying?

Most databases expect you to write SQL. Polykomos doesn't. You send a plain English sentence describing what you want — "create a table for user preferences" or "show me all orders from the last week" — and the API translates it into SQL, executes it, and returns structured JSON results.

This matters because AI agents don't think in SQL. They think in intent. An agent that needs to remember a user's last five messages shouldn't have to construct a SELECT statement — it should just ask for what it needs.

$ curl -X POST https://polykomos.com/api/v1/query_executions \ -H "Authorization: Bearer pk_live_..." \ -H "Content-Type: application/json" \ -d '{ "database_uuid": "db_abc123", "query": "show me the 5 most recent conversations" }' { "data": { "columns": ["id", "user_name", "message", "created_at"], "rows": [ [42, "alice", "Can you check my order status?", "2026-02-19T10:32:00Z"], [41, "bob", "I need to reset my password", "2026-02-19T09:15:00Z"], ... ], "row_count": 5 } }

No schema memorization. No query building. Your agent describes what it needs, and Polykomos handles the rest.

Why agents need databases

Without persistent storage, every agent conversation starts from zero. The agent forgets what it learned, loses context about users, and can't coordinate with other agents. A database changes that:

  • Memory — Store conversation history, user preferences, and learned facts that persist across sessions.
  • State — Track what the agent is doing, what it has already tried, and where it left off.
  • User data — Keep profiles, settings, and interaction history so the agent can personalize responses.
  • Coordination — Multiple agents can read and write to the same database, sharing context without custom message passing.
  • Audit trail — Every action the agent takes can be logged and queried later for debugging or compliance.

You could wire all of this up yourself — set up PostgreSQL, write migrations, build an ORM layer, handle connection pooling. Or you could give your agent an API key and let it talk to a database in English.

How it works

Three steps from zero to a working agent database:

1
Create a database. One API call provisions a fresh database instance. You get back a UUID and a connection string.
2
Send natural language queries. Your agent sends English sentences to the /query endpoint. Polykomos translates them to SQL, runs them, and returns JSON. Tables are created on the fly when needed.
3
Get structured results. Every response includes column names, typed rows, and row counts. Your agent parses JSON — not SQL result sets.

That's it. No migrations, no ORM configuration, no connection pooling setup. The database adapts to what the agent asks for.

OpenClaw: agent memory

OpenClaw is an open-source AI agent framework that connects through Telegram, Discord, Slack, and other channels. If you're building on something like OpenClaw, Polykomos can serve as the agent's long-term memory — storing conversation history, user preferences, and learned facts across sessions.

Imagine a user asks the agent something it discussed three weeks ago. The agent queries its memory database in plain English:

# The agent asks for context from previous conversations { "query": "find all messages from user alice about project deadlines in the last month" } # Polykomos returns structured results { "data": { "columns": ["id", "user_name", "message", "topic", "created_at"], "rows": [ [156, "alice", "The Q2 deadline moved to March 15", "deadlines", "2026-02-03T14:20:00Z"], [142, "alice", "We need the MVP by end of February", "deadlines", "2026-01-28T09:45:00Z"] ], "row_count": 2 } }

The agent didn't need to know the table schema or write SQL. It described what it wanted, got back JSON, and used those results to form a contextual reply.

How it could work
Schema created by the agent itself
The agent's first message to the database could be "create a table to store conversation messages with user name, message text, topic, and timestamp". The table gets created automatically. No migration files, no deploy step.

Multi-agent shared database

When multiple agents work on the same problem, they need a shared source of truth. Instead of building custom message-passing between agents, point them all at the same Polykomos database.

Example
Research pipeline: scraper + analyst + reporter
A scraper agent collects pricing data from competitor websites and stores it: "insert a new price record for Product X at $49.99 from competitor.com". An analyst agent runs on a schedule and queries trends: "show me the average price change per product over the last 30 days". A reporter agent pulls the analysis to generate weekly summaries: "get all products where price dropped more than 10% this week". All three agents share the same database UUID — no APIs between them, no event bus, no glue code.

Each agent uses its own API key (for audit logging), but they all read and write to the same tables. Polykomos handles concurrency — you don't have to.

Customer support agent

A support agent that can't remember previous tickets is just a fancy FAQ. With a Polykomos database, your agent maintains full context:

Use case
Ticket tracking with natural language
When a user reports an issue, the agent stores it: "create a new support ticket for user bob about login failures, priority high". When they follow up, the agent checks history: "show me all open tickets for user bob". When the issue is resolved: "mark ticket 847 as resolved with note: password reset completed". The agent never writes SQL. It describes what it needs in the same language it uses to talk to users.

Over time, the database builds up a knowledge base of common issues, resolution patterns, and per-user history that the agent can draw from to improve its responses.

Data collection agents

Agents that collect data over time — scraping prices, monitoring APIs, tracking social metrics — need somewhere reliable to put it. Polykomos gives them a database without any setup overhead.

Example
Market research data pipeline
A data collection agent runs hourly, scraping product listings from e-commerce sites. Each run, it sends: "insert a price record for SKU-1234 at $29.99 from store amazon, captured now". Later, an analysis query: "show the price history for SKU-1234 over the last 90 days, ordered by date". The agent builds its own dataset without anyone writing a single line of SQL or managing a database server.

This pattern works for any kind of periodic data collection: weather stations, stock prices, social media metrics, IoT sensor readings, API health checks.

Getting started

Four steps to give your agent a working database:

1
Sign up for a Polykomos account. Free tier includes one database.
2
Create a database from the dashboard or via the API.
3
Generate an API key from the API Keys page.
4
Send your first query. Give your agent the API key and database UUID, and let it talk to the database.
# Your agent's first query — create a table and insert data in one step $ curl -X POST https://polykomos.com/api/v1/query_executions \ -H "Authorization: Bearer pk_live_..." \ -H "Content-Type: application/json" \ -d '{ "database_uuid": "db_abc123", "query": "create a table for user preferences and add a row for user alice who prefers dark mode and metric units" }'

Blueprints for agents

Blueprints are pre-built database schemas you can apply in one click. Instead of letting your agent create tables from scratch, start with a tested schema designed for common agent patterns:

  • Agent Memory — Conversations, facts, user profiles, and learned preferences. Designed for chatbots and personal assistants.
  • Task Tracking — Projects, tasks, assignments, and status history. Built for agents that manage workflows.
  • Data Collection — Time-series records, sources, and collection metadata. Ideal for scraping and monitoring agents.
  • Multi-Agent Coordination — Shared state, agent logs, task queues, and handoff records. For systems where multiple agents collaborate.

Browse available blueprints in the blueprint catalog, or apply them via the Blueprints API.