A persistent, auditable memory layer for AI agents
Built, queried, and reorganised by the agents themselves.
The missing layer
AI agents are good at reading files, writing queries, and explaining results. What they lack is somewhere trustworthy to put what they learn. A transactional database demands a schema up front; a spreadsheet has no audit trail; a context window forgets everything when the session ends.
Azquo is that missing layer: a persistent, auditable store an agent can build, query, and reorganise on its own — and that remembers every decision the agent made.
If you have tried to put AI on your data, you have probably hit one of these walls
The model never gets richer. Every new question is a fresh ChatGPT-on-CSV. The agent learned something useful last week — that “Q3 revenue” excludes intercompany — and the next agent has no way to know. Conversations do not compound into capability.
The schema fights you. A new dimension shows up and you are back in the data team’s queue for a migration. The business question that triggered it is already cold by the time the column exists.
RAG hallucinates the lineage. Vector retrieval surfaces “the right paragraph” but cannot tell you whether the number in it is the canonical figure, an old draft, or something someone pasted into a slide.
Hierarchies do not survive the join. SQL flattens rollups. Document stores ignore them. Graph DBs handle relationships but cannot aggregate numbers. Every answer that touches structure has a workaround behind it.
You cannot cite a single cell. Most stores can tell you which row was written when — not which cell, by which transformation, from which source file. The audit conversation eats the project.
How the field actually scores
Most data stores were designed before AI agents existed as the primary consumer. Here is how the common options score against what an AI-on-your-data project actually needs:
| Schema-free extension | First-class hierarchies | Per-cell provenance | External-data anchoring | AI-native query API | Warehouse-scale OLAP | |
|---|---|---|---|---|---|---|
| Relational SQL (Postgres, MySQL) | ✗ | ◐ | ◐ | ✗ | ✗ | ✓ |
| Document store (Mongo) | ✓ | ✗ | ✗ | ✗ | ✗ | ◐ |
| Data warehouse (Snowflake, BigQuery) | ✗ | ✗ | ◐ | ◐ | ✗ | ✓ |
| Graph DB (Neo4j) | ◐ | ✓ | ✗ | ✗ | ✗ | ◐ |
| Vector DB (Pinecone, pgvector) | ✓ | ✗ | ✗ | ✗ | ◐ | ✗ |
| LLM-on-CSV (ChatGPT, Claude direct) | ✓ | ✗ | ✗ | ✗ | n/a | ✗ |
| Azquo | ✓ | ✓ | ✓ | ✓ | ✓ | ◐ |
✓ native ◐ partial ✗ not really
What an agent can do through the Azquo MCP
The Azquo MCP server gives any MCP-capable AI agent direct tools to: create databases; import raw files; design and refine import templates; query with AQL; browse and extend hierarchies; build and run reports; and audit any individual figure back through every transformation to its source.
Proven, not promised — a worked demonstration
Concretely: hand an agent a folder of monthly sales exports (different shapes, different column names), some PDFs of board minutes, a spreadsheet listing regions and divisions. Tell it: build a model we can answer budgeting questions against.
In an Azquo store the agent does not ask you to design a schema first. It loads each file as it finds it. It proposes a hierarchy — Division → Region → Office — and commits it without disturbing what is already there. It anchors the PDF-extracted commentary to the months it describes. Every cell carries its source. Every grouping is reversible — a new hierarchy is a new lens, not a migration.
Two weeks later someone asks “split Q3 by product line, not just region.” The next agent does not restart. Product-line did not exist when the first agent ran — and that is fine. It adds it, anchors product lines into the existing hierarchy, and answers. Nothing existing breaks. The audit trail from week one still resolves cleanly.
This is not a hypothesis. In a recent demonstration, Claude built a complete insurance loss-cost database from a 168-page ISO Commercial Auto filing covering 73 territories — unaided. It designed the import templates, structured the hierarchies, and produced the reports, with every step recorded in the database itself. Every value in the rating chain — not just the total — traces back to the file, the user, and the date. Click any cell.
Institutional memory for agents
Every quirk uncovered, every convention agreed, every interpretive decision an agent makes is stored as part of the database — anchored to your business and available to the next agent that connects. Agents stop starting from zero.
Two-way with your spreadsheets
The same store speaks Excel directly. Analysts pull live data in, write changes back, and share with colleagues. The AI layer and the spreadsheet layer see one source of truth, and every change — from either side — is on the record. If your primary interest is the spreadsheet side of that story, Home → has it in the finance vocabulary.
Why the architecture matters
Azquo stores names in hierarchies, not rows in tables. There is no schema to design before data arrives; any data can be loaded at any time, and new groupings can be added later without touching existing data or breaking existing reports. That flexibility is precisely what agent-driven work needs: structure grows as understanding grows.
Try it
The MCP runs on our infrastructure at mcp.azquo.com. Evaluation access is granted on request and includes a pre-configured Claude Code snippet, your own Azquo account, and a credential pair tied to your user — so every agent action is attributed back to you in the audit trail.
If you are building agent systems and want a memory-and-audit layer underneath, we would like to talk.
Finance-owned. IT-approvable. Runs alongside your existing systems — nothing to rip out.