Skip to content
Tony Wood
Home

Why Am I Still Designing Databases For Systems That Think?

Tony Wood |

If your team is building agentic workers and your first question is “What’s the schema?”, you are probably over-engineering the wrong problem.

Here is the tension many leadership teams sit in.

• You want robust systems, governance and audit trails.
• Your architects reach for relational databases, schemas and migrations.
• Your agents, powered by large language models, actually think in documents, stories and context.

Those two worlds do not line up as neatly as they used to.

The good news is that a simpler model is emerging from some very credible places: treat documents as the primary “source of truth” and let agents work over them, instead of forcing everything into rows and columns.

The Quiet Shift: From Schemas To Documents

One of the clearest examples comes from Obsidian, a knowledge-management tool that has grown a substantial professional user base.

They made a design choice that echoes what many of us are now rediscovering for agentic systems:

"In Obsidian, your notes are files on your computer, stored in a folder called a vault. Each note is a Markdown file, which is a plain text file with some lightweight markup. We deliberately chose not to use a database: your notes are just files you can see, move, copy, sync, back up, or open with any other tool."

That is a product team saying: “We could have used a database, but files and folders match how humans think.”

In a second passage, they go further:

"We decided early on that Obsidian should embrace the way people already think about their notes: as a bunch of files in folders. Files are simple, inspectable, and tool‑agnostic. A database would have given us more control, but it would also have hidden your knowledge behind an engine you don’t own or understand."

This is exactly the pattern that matters for leaders exploring agentic workflows.

• Humans think in files, folders and documents.
• Agents read and reason over text, JSON and semi structured content.
• Databases introduce extra indirection that is often unnecessary for decision making.

The question is not “Can we normalise this data?”
The question is “Can an intelligent agent, or a person, understand what is going on here without learning our schema?”

Why Documents Fit Agentic Workers

Agentic workers are not classic transaction-processing systems.

They:

• read policies, emails, notes and logs
• reason across multiple sources
• keep track of history and narrative
• propose or execute actions based on context

That context does not live naturally in a single table.

Documents, on the other hand, are built to carry context.

Martin Fowler makes the point clearly when he writes about requirements:

"When you are documenting requirements, you are not just enumerating features; you are telling the story of the system. A good requirements document provides context, motivation, and narrative that explain why things are the way they are, not just what they are."

That “story of the system” is exactly what agentic workers need to read.

For leadership teams, the implication is practical.

• If you want agents to act like colleagues, give them information the way you would give it to a colleague.
• That means documents with narrative, not just dashboards and status fields.

JSON, Markdown And The Enterprise Comfort Zone

There is a legitimate concern here.

You might be thinking:

• “Documents sound messy.”
• “How do we keep structure, reporting and compliance?”

Modern document-centric practice actually gives you more options than it might appear.

Microsoft’s own cloud documentation describes document databases this way:

"A document database is a type of nonrelational database that is designed to store and query data as JSON‑like documents. Instead of breaking information into rows and columns, document databases keep related data together in a single, flexible record that more closely resembles how developers work with objects in their code."

Two points are worth noticing for leaders.

• JSON documents keep related data together with its context.
• This style is already mainstream in serious enterprise systems.

In the same piece, they highlight when this fits best:

"Document databases excel when your application works with rich, evolving entities that don’t fit neatly into a fixed schema. Storing each entity as a JSON document lets you capture its complete context in one place, and lets your code and your data evolve together without expensive migrations."

Agentic workers are the definition of “rich, evolving entities that don’t fit neatly into a fixed schema.”

A supplier is not just:

• SupplierID
• Status
• CreditScore

It is also:

• incident reports
• email threads
• meeting notes
• risk assessments
• policy exceptions

That information already exists as documents in most organisations. The move is to recognise them as first class, not as an afterthought to a database.

Why Conversations Beat Dashboards For Agentic Work

Most leadership dashboards were built for a different era.

They assume:

• humans scan numbers
• humans click filters
• humans decide what matters

Agentic systems flip that on its head.

You want to ask questions in plain language and get synthesised answers, such as:

• “Does this supplier require a review?”
• “Which customers look at risk this quarter?”

The usability research community has been exploring this shift for years. Nielsen Norman Group summarise it neatly:

"Dashboards and dense screens are optimized for scanning numbers and manipulating controls, but they are not optimized for answering nuanced questions in context. Conversational interfaces can shine when users want to ask, in plain language, ‘What should I do next?’ or ‘Is there anything here that needs my attention?’"

That is exactly the behavioural pattern you want from agentic workers.

• Let the system tell you what needs attention.
• Stop forcing leaders to assemble the picture themselves from a wall of charts.

For that to work, the underlying information architecture must serve nuanced questions.

Documents, written in natural language with light structure, are ideal feedstock for agents that specialise in conversation and reasoning.

A Simple Architecture Pattern For Leaders

You do not need a wholesale platform rewrite to benefit from this.

A pragmatic pattern many teams are using looks like this.

1. Start with human friendly documents

• Store policies, supplier dossiers, incident logs and playbooks as Markdown or word-processing documents in a clear folder structure.
• For data that benefits from structure, use JSON files stored alongside the narrative.

2. Let an agent operate over those artifacts

OpenAI describes this pattern in their work on agentic systems:

"Agents work best when they can operate over the same artifacts that humans use: natural language documents, emails, wikis, logs, and JSON APIs. Instead of forcing all information into a single schema, we let agents read, write, and reason across heterogeneous sources, combining them into plans and actions." (https://openai.com/index/building-agentic-systems/)

At a leadership level, the key is to mandate that important context lives in places where both humans and agents can read it.

3. Only structure what you need, when you need it

Google’s Earth Engine team articulate a pattern that applies far beyond geospatial data:

"Many real‑world systems end up combining free‑form documents with more structured representations. Humans start with documents because they are easy to write, file, and read. Only later, when patterns emerge or analysis is needed, do we extract parts of those documents into more formal datasets." (https://landing.google.com/earthengine/tutorials/community/documents-to-datasets/)

In practice, that means:

• Start with documents and folders for new agentic workflows.
• Allow teams to work, iterate and learn with minimal upfront modelling.
• Once you see recurring questions or reports, selectively extract those fields into a dataset or dashboard.

This keeps your estate flexible while still supporting classic reporting where it makes sense.

What This Means For Your Roadmap

For leadership teams planning 2025–2026 roadmaps, there are some concrete implications.

1. Challenge “database first” reflexes

• Ask: “Can this start life as documents and JSON instead of a new schema?”
• Encourage teams to treat the file system and knowledge base as strategic assets, not side effects.

2. Invest in document quality and structure

• Clear naming conventions, folder hierarchies and versioning policies.
• Templates for key entities such as suppliers, customers or projects, written in plain language.

This is cheap compared to large data projects, and it has immediate payoffs for both people and agents.

3. Fund agentic pilots over real documents

• Choose one or two workflows where context matters more than transactions (for example supplier risk reviews, policy exception handling, or major incident postmortems).
• Point an agent at your existing documents, emails and logs.
• Measure whether leaders get faster, more confident answers to questions that previously needed meetings and slide decks.

4. Keep governance and ownership clear

• Decide who “owns” the document structure for each domain.
• Treat those owners as responsible for both human comprehension and agent readability.

This is where traditional information governance and AI strategy meet.

If You Remember One Thing

The big shift is mental, not technical.

Stop asking:
• “What is the perfect schema for this system?”

Start asking:
• “If this was just me and my laptop, how would I store this so that a smart colleague could understand it later?”

In most agentic contexts, that answer looks like: folders, Markdown, JSON and clear, narrative documents.

From there, you can let your agents do what they do best: read, reason, relate and recommend.

Links:

Quotes:

Share this post

Keep reading