Why Multidimensional Tables Make a Good Business Data Foundation for AI Agents

If an AI system only summarizes documents, answers questions, or rewrites text, the exact shape of the underlying data is not especially important. PDFs, web pages, chat logs, and loosely structured notes can all be retrieved and placed into context.

The problem changes as soon as the request starts to sound like real work:

“Find the high-priority tasks that are already late and still unassigned, move them into a plan that finishes by next Monday, and suggest owners.”

At that point, fluent generation is not the main difficulty. The system first has to answer a much more concrete set of questions. What is a task? Where is priority stored? How is “late” determined? Is an assignee free text or a member relation? Which records can the current user see? Which records can they modify? Has the business state changed between the recommendation and the write?

That is one of the conclusions I have become more convinced of while building QTable: an agent that participates in real work needs more than natural language. It needs a business world model that can be queried, constrained, and executed against.

The interesting thing about a multidimensional table is not that it is “a better spreadsheet.” It sits between free-form text and a conventional database. People can still understand and edit it directly, while software gets explicit structure.

An agent needs an executable world model, not just more context

Large language models are very good at inferring meaning from text. A business system, however, cannot make every mutation depend on “the model probably interpreted this correctly this time.”

An agent that can actually execute work needs at least five things to be explicit:

• What the objects are. Project, Task, Member, and Customer should be stable entities, not just nouns inside prose.
• What their properties mean. Status, priority, dates, owners, and amounts need types and known semantics.
• How objects relate. A task belongs to a project, a customer has contracts, a member owns work.
• Who may see and change what. Permission must participate in reads and writes, not just hide UI controls.
• What changed. The system needs enough state to validate, trace, and sometimes reject stale writes.

If all of that lives only in prose, the agent has to infer it again on every run. If it exists only in a raw relational database designed for engineers, ordinary users lose the ability to shape the model themselves.

That middle ground is where multidimensional tables become useful.

Data shape	For people	For an agent	Main tradeoff
Documents / chat	Very natural	Rich semantics, weak boundaries	Objects, relations, and constraints must often be inferred again
Multidimensional table	Directly editable and configurable	Explicit structure with business meaning	Schema, permission, and mutation rules still need careful design
Raw database	Precise and strongly constrained	Excellent for programmatic queries	Hard for ordinary users to model and maintain directly

So I do not think every business domain should become a table. A narrower claim is more useful: when an agent needs to coordinate, plan, assign, track, and change business objects, a multidimensional table is a practical work model.

The useful part of a row is the schema behind it

On screen, a multidimensional table still looks like rows and columns. For an agent, the important question is not “what is in row 17?” but “why can row 17 be understood reliably?”

In QTable’s current backend, app/models/smart_table.py separates the core model into TableField, TableRecord, TableView, TableFilter, TableSort, TableGroup, and related structures.

A record can hold business values in JSON, but the field definitions are not implicit. TableField carries the field name, type, and option/property configuration. A TableRecord has a stable id and a monotonic version used for optimistic concurrency.

Those details are mundane database design, but they matter a great deal to an agent.

Suppose the user says, “pull the high-priority work forward.” With only a block of task prose, the model first has to guess where priority is expressed, how dates are represented, and which phrase means status. With a structured work model, the system is no longer dealing with ambiguous prose. It has explicit business objects and typed semantics:

The model is no longer inventing the semantics of the system from scratch. It is reasoning inside semantics the product already knows.

Relations and formulas turn a list into a business model

Fields alone are not enough. Real work rarely fits inside one isolated table.

Tasks belong to projects. Projects live inside a workspace. Tasks may depend on other tasks. Owners are team members. Orders point to customers; customers point to contracts and payments. If an agent wants to answer “why is this launch late?” or “who can take this task?” it has to follow those connections.

QTable’s backend already separates this responsibility into domain services such as relation_engine.py and formula_engine.py. That does not mean the current relation and formula systems are the final design. It does show the intended architectural boundary: relations and computation belong to the business model, not to one particular screen.

Once relations are explicit, an agent can move from Task to Project, from Project to members or schedule, and then carry the result back to the original work item without reconstructing those links from prose each time.

That is a very different approach from concatenating dozens of records into a prompt and hoping the model reconstructs the domain consistently.

A view should be a projection, not a second copy of reality

Another property of multidimensional tables fits agents unusually well: one set of facts can support many ways of working.

Grid, Kanban, Gantt, Calendar, and Gallery can look like entirely different products, but they should operate on the same records. QTable’s current TableView stores view type and configuration, while filtering, sorting, and grouping are modeled separately rather than producing another copy of the business records.

This becomes much more important once AI can modify the system.

When a person drags a Kanban card from “In progress” to “Done,” the meaningful operation is a change to the record’s status field. When someone moves a bar in Gantt, the meaningful operation is a change to date fields. An agent should update those same business objects rather than maintain an AI-specific shadow state.

That is how Web, API, automation, dashboards, and AI can all talk about the same world.

Structure is not enough; permission has to live inside the model

“AI can understand the data” is only the first step. The harder question is: how much of that data may it understand, and how much may it change?

If a table contains 10,000 records but the current user is entitled to see only 600, the agent’s context should be limited to those 600 as well. Giving the model everything and asking it to remember not to reveal certain rows is not a security boundary.

QTable’s current model includes TableRowPermissionPolicy and WorkspaceItemPermission, and the service layer includes row_permissions.py. The portal documentation also treats the server as the final authority for permission and write rules.

That is why I find “business data foundation” a more useful phrase than “structured data source.” A foundation for agents needs Schema, Relation, Permission, Validation, Version, and Audit to meet at the same execution boundary.

Follow one concrete request through the system

Return to the request from the beginning:

“Find the high-priority tasks that are already late and still unassigned, move them into a plan that finishes by next Monday, and suggest owners.”

If the system is going to execute that request rather than merely produce advice, the path is roughly:

1. Resolve the current Workspace, Table, View, and user.
2. Read the table schema and identify status, priority, owner, and due-date semantics.
3. Query matching records inside the current user’s permission boundary.
4. Follow relations to projects, members, and dependencies where needed.
5. Use business rules and current workload to produce candidate changes.
6. Express those changes as a structured Action Plan.
7. Before writing, re-check permission, record version, and current state.

The first five steps explain why the data model matters. The last two lead directly into the next article in this series: how AI writes can be made safe enough for a real business system.

QTable already has a query layer such as record_query.py and an ai_action_plan.py service for AI Action Plans. The important point is not the file names. It is that querying, domain rules, and AI execution are not being designed as three unrelated systems.

A multidimensional table is not a universal database

There is an easy overcorrection here. If structure helps agents, should everything be forced into a table?

I do not think so.

Long-form documents, source code, images and video, large event streams, high-frequency time series, and graph-heavy domains all have storage and retrieval systems better suited to them. Breaking all of that into cells would make the experience worse for both people and models.

A multidimensional table is better thought of as a business coordination layer: which objects are in play, what state they are in, how they relate, who owns them, when they are due, and what rules govern change.

The source material can remain in document systems, object storage, code repositories, or specialized databases. The table can keep the structure, references, and business state that matter to the work. An agent retrieves the detailed source only when it needs it and only within the user’s access boundary.

That distinction matters because QTable is trying to become a work system, not a replacement for every category of data infrastructure.

The questions I now use to judge whether a system is agent-friendly

Instead of asking whether a product has an AI chat box, I find these questions more useful:

• Do business objects have stable IDs, or can they only be matched by name?
• Is schema explicit enough for software to read field types and meaning?
• Can relations be traversed reliably, or are they hidden in prose?
• Are views projections, or do they quietly create another copy of business state?
• Does permission participate in reads and writes, or is it only a frontend concern?
• Do writes have version checks, validation, change history, and an auditable boundary?

If most answers are no, even a very capable model will remain outside the system giving advice.

If these foundations are in place, the model itself becomes more replaceable. Providers can improve or change because the durable layer is the business contract underneath them.

The real value is the layer between language and execution

So why do I think multidimensional tables make a good business data foundation for AI agents?

Not because tables are inherently “AI-native,” and not because rows and columns have special properties. The useful part is that they combine several things that are hard to get at once: people can understand and edit them directly; machines can query and validate them consistently; business objects can be related; interfaces can project the same facts in different ways; and permission and mutation rules can live in one domain boundary.

For QTable, that layer turns natural language into increasingly concrete objects:

Intent → Schema → Record / Relation → Permission → Validated Action

That is where an agent starts to move from talking about work to participating in it.

The next article will go one level deeper into the write path and explain why QTable uses Preview → Confirm → Apply, and why Preview should be treated as a system boundary rather than a UI effect.