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 — where every write is attributed, and every decision the agent records is there for the next agent that connects.
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 | Conventions kept with the data | 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) | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Azquo | ✓ | ✓ | ✓ | ◐ | ✓ | ◐ |
✓ native ◐ partial ✗ not really
Most of these stores can now be reached by an agent through an MCP server. The difference that matters is what the agent finds there: whether it can extend the model without a migration, and whether the conventions for working with the data are kept in the store itself, for the next agent to read.
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.
And because agents make mistakes, the same tools let them rehearse a risky change on a copy of the database first, see the history of any name and restore one that was deleted, and see every earlier value with who changed it and where the change came from.
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, with no Azquo specialist involved. 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.
Concretely, an agent that connects for the first time is told by the server to read one starting note, which points it to the rest of a skills base of several hundred notes on working with Azquo. Beside its own databases it finds a shared library of working examples — budgeting, management accounts, time and expenses, pivot analysis, property insurance premiums and a US auto quote — which it can copy and adapt rather than build from nothing. What it learns about your data, it writes back into your database for the agent that comes after it.
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, Azquo in Excel → 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 Azquo MCP server runs on our infrastructure at https://data.azquo.ai/mcp. Evaluation access is granted on request and gives you your own Azquo account. Every agent action is attributed back to you in the audit trail.
If you use the Claude app, there is nothing to install: add that address as a custom connector and sign in with your Azquo login. You can then ask Claude to keep and account for your organisation’s information, and it will do so in Azquo.
If you are building agent systems, point any MCP-capable runtime at the same address with an API key from the Azquo admin site.
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.