Solve · Agent builders
How do I run reports over what my AI agent remembered?
If your agent stores what it learns and you now need *reports* over that memory — counts, top-N, averages per group — point an MCP-aware agent at nlqdb and ask in English. It runs the `GROUP BY` in Postgres and returns rows plus the SQL. A vector store recalls one fact; a database answers 'top 10 this month.'
An agent that already logs what it learns hits a wall the moment the question turns analytical: 'top 10 topics this month by count', 'average deal size per stage', 'tasks completed per day this week'. Vector / graph memory (Mem0, Zep, LangMem, a Letta archival tier) returns the top-k similar rows — it has no query planner — so the rollup becomes the LLM doing arithmetic over search hits. Retrieval is the wrong tool for aggregation.
Drop this in your HTML
The query an agent runs to summarise its own memory — `GROUP BY` category + count + order — is exactly what retrieval can't do and a real database can.
count of facts the agent logged per category this month, highest first <nlq-data goal="count of facts the agent logged per category this month, highest first"></nlq-data>What nlqdb actually does for this
- The agent's memory is typed rows in real Postgres, so `GROUP BY`, top-N, and per-period rollups run as actual SQL — not arithmetic over a list of search hits.
- Ask the report in English via MCP `nlqdb_query`; the answer returns as rows plus the compiled SQL under a trace toggle, so you audit the grain before trusting it.
- Plans are content-addressed on `(goal-fingerprint, schema-hash)` (`GLOBAL-006`) — a repeated weekly rollup hits the cache and returns in single-digit ms.
- Same database the agent writes to and reports over — no ETL into a separate analytics store, no second connection string to keep in sync.
What nlqdb doesn't do here
- No native vector / similarity search — the analytical half assumes the agent already chose what to store as rows; unstructured recall over chat-text is Mem0 or pgvector's job.
- No prebuilt charting — nlqdb returns the aggregated table + a one-sentence summary; rendering it as a chart is the consumer's choice.
Questions buyers ask
- How is this different from giving my agent persistent memory?
- Persistent memory is the write side — the agent storing facts so it can recall them later (see /solve/give-ai-agent-persistent-memory). This page is the read side: running analytical reports — counts, top-N, averages per group — over what it stored. nlqdb is the same Postgres for both, so there's no second store to sync.
- Why can't my vector memory just answer "top 10 topics this month"?
- A vector store returns the top-k most similar rows; it has no query planner. An aggregation then becomes the LLM doing arithmetic over a list of search hits — a hallucination generator, not a `GROUP BY`. nlqdb runs the aggregation in Postgres and shows you the SQL it ran.
- What does the report query actually look like?
- You write the goal in English — 'count of facts the agent logged per category this month, highest first' — and nlqdb compiles it to SQL over the memory table, runs it, and returns the ranked rows. The compiled SQL shows under the trace toggle (`SK-WEB-005`) so you can verify the grain.
- Do I need a separate analytics database for this?
- No. The agent writes its memory rows to nlqdb's Postgres and reports over the same database — no ETL pipeline, no second connection string. Phase 2's workload analyser proposes a ClickHouse migration automatically if scan volume ever crosses the threshold, without an app-side rewrite.
Where this pain shows up in public
Enduring discussion hubs where you can verify the theme without taking our word for it. We don't quote individual posts; we cite search-result and subreddit URLs that stay live as new threads land.
Try nlqdb in 30 seconds
No sign-in. The anonymous database lasts 72 hours; adopt it with one click if you keep it.
Start with a goal →