Should agents use SQL skills or fake filesystems for data tasks?

When SQL skills are the safer default for agent data work

SQL skills are the better fit when the agent must retrieve data accurately, filter it precisely, and then do local analysis on a bounded result set. That keeps the database doing set-based work, preserves query semantics, and avoids simulating shell-like navigation inside a system that was designed for relational access and query planning.

That matters most when the task involves joins, aggregates, ordering, deduplication, or business rules that depend on exact row selection. In those cases, a filesystem-like abstraction often obscures the real data model and makes the agent work harder to get correct answers.

For agents that already have access to a database, this is also a control question about blast radius and observability. A focused SQL query is easier to review, log, constrain, and reason about than an improvised file traversal pattern that can expand into broad reads or brittle path assumptions.

Why fake filesystems usually age badly

A filesystem metaphor can be useful for quick browsing, but it becomes fragile when the agent needs relational operations, schema awareness, or repeatable results. Once the abstraction starts pretending tables are folders or rows are files, the agent loses the guarantees that SQL provides and the data task becomes dependent on naming conventions instead of structure.

That mismatch shows up in practice as hidden complexity. The agent may need to emulate filters, pagination, and composition in application logic, which is slower, harder to validate, and easier to break than pushing those operations down into SQL where they belong.

A filesystem-like interface is most defensible when the workload is genuinely read-only, the data is simple, and the main goal is locality of access rather than relational correctness. If the task is exploratory and the underlying source is already document-like, the abstraction can reduce friction. If not, it usually adds more confusion than it removes.

What good practice looks like in agent design

The strongest pattern is to separate retrieval from interpretation. Let the agent issue a narrow SQL query, inspect a manageable result set, and then perform higher-level reasoning outside the database instead of trying to recreate shell workflows inside the data layer.

Designers should also decide early whether the agent is meant to browse or to compute. If the job is computation over structured records, SQL should stay the primary interface. If the job is lightweight inspection of flat artifacts, a filesystem view may be acceptable, but only as a convenience layer, not as the core data model.

What to verify: Check whether the abstraction preserves exact filtering, joins, sorting, and row-level scoping without hidden translation rules. If it cannot, the agent is probably trading correctness for convenience.

Decision rule: Use SQL when correctness depends on the data model; use a filesystem-like abstraction only when the source is simple, read-only, and the agent is not expected to do relational reasoning.

Practitioner takeaway: The question is not which interface feels more natural to the agent, but which one keeps the data task faithful to the source system while limiting unnecessary complexity.

Related resources from NHI Mgmt Group

• How should organisations handle agents that can make decisions over long-running tasks?
• What fails when AI agents are governed only by guardrails and not by data-layer controls?
• Should organisations keep humans in the pentesting loop even when agents outperform them on some tasks?
• How should teams decide which SOC tasks to encode into Skills first?