AI agents perform better with local SQL than fake filesystems

At a glance

What this is: Arize compares a Postgres-backed filesystem abstraction with a SQL skill for AI agents and finds that the SQL workflow wins on overall accuracy and operational simplicity.

Why it matters: IAM and AI platform teams should care because agent tool design shapes how data is retrieved, reused, and governed, which in turn affects observability, control, and the blast radius of agent behaviour.

Context

AI agents often perform better when they can work from local materialised data rather than repeatedly querying a backend through a simulated interface. In this case, the core governance question is not whether an agent can imitate filesystem behaviour, but whether the abstraction helps or hides the actual control point for data access and reuse.

That matters for agentic AI identity and access design because each tool call is also an access decision. If the agent must round-trip to the database on every read, teams inherit more dependency on the abstraction layer, more complexity in monitoring, and less clarity over what the agent actually handled locally versus remotely.

Key questions

Q: When does a filesystem-like abstraction fail for AI agents?

A: It fails when the task needs repeated reads, intermediate staging, or multi-pass reasoning over the same data. In those cases, the abstraction adds round-trips and hides the agent’s real execution path, while a local working copy lets the agent reuse results with ordinary tools and fewer hidden dependencies.

Q: Why does materialising data locally improve agent tool use?

A: Because it reduces backend dependency after the initial fetch and gives the agent a writable, re-readable workspace for analysis. That is especially important when the workflow needs branching logic, second-pass filtering, or file-oriented tools that are awkward to recreate inside a read-only abstraction.

Q: What do teams get wrong about database-to-filesystem patterns for agents?

A: They confuse a familiar interface with a better execution model. A filesystem-shaped wrapper may help the model navigate, but it still imposes translation, caching, and consistency costs. The deeper mistake is assuming the surface metaphor removes the need to govern the underlying access path.

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

A: Use SQL skills when the agent needs accurate retrieval followed by local analysis, because they preserve the database’s strengths without recreating shell semantics inside the database. Use a filesystem-like abstraction only if the task is truly read-only and simple enough that locality and composition are not the bottleneck.

Technical breakdown

Why locality changes agent performance

Locality means the agent holds a local copy of the data it needs and can process it with ordinary shell tools. That avoids repeated backend reads, reduces latency, and makes multi-step analysis easier because intermediate results can be reused without another database call. In contrast, a filesystem-like wrapper turns every ls, cat, or grep into a translated read against the database, which looks familiar to the model but still behaves like remote access. The abstraction preserves syntax, not execution locality. Once the task becomes iterative or branch-heavy, locality becomes the deciding property, not whether the surface resembles a filesystem.

Practical implication: Prefer materialising the working set locally when the task requires repeated analysis over the same data.

What fake filesystem abstractions hide in agent workflows

A fake filesystem can make an agent more fluent on the surface, but it also hides the fact that every read still depends on a translation layer. That layer has to preserve command semantics, caching behaviour, and read consistency while also approximating shell expectations. The result is not just an engineering wrapper, but a second system that must be kept correct as schemas, paths, and query behaviour evolve. The article shows that once you start adding enough fidelity to make the abstraction genuinely useful, you are rebuilding a specialised execution layer rather than simplifying the problem.

Practical implication: Treat abstraction fidelity as a maintenance cost, not a free usability gain.

Why SQL plus Bash is the more composable agent pattern

SQL is strong at locating and filtering data at scale, while Bash and local files are strong at chaining transformations. Combining them lets the agent use each tool where it is strongest: the database for retrieval, the local environment for composition. That split matters because many shell patterns, including re-reading intermediate output and combining multiple derived sets, are awkward or impossible behind a read-only abstraction. The article’s point is architectural: the most reliable agent harness is often the one that keeps the retrieval boundary clear and then hands off to native tools for the rest.

Practical implication: Design agent skills so retrieval and composition happen in the right place, not through one blended interface.

NHI Mgmt Group analysis

Locality is the real control variable in agent tool design. The article shows that interface familiarity can improve usability without solving the underlying execution problem. Once a model must revisit the source system for every read, latency and correctness start depending on the wrapper rather than the work. Practitioners should treat locality as an architectural control point, not a convenience feature.

Filesystem-shaped abstractions create governance ambiguity for agent access. A model that appears to be working in a local file tree may still be issuing repeated backend queries, which makes it harder to reason about what data was touched, when, and through which path. That weakens auditability for agentic systems and complicates policy enforcement across tool boundaries. Practitioners should map the actual data path, not just the prompt surface.

Agent identity needs to follow capability, not interface metaphor. If an agent can query a database, materialise results, and then use shell tools, the access model should reflect those distinct steps. The named concept here is locality collapse: when a remote abstraction hides repeated reads that should be visible as discrete access events. Practitioners should govern the retrieval boundary explicitly rather than assuming a filesystem metaphor has made the workflow safer.

Maintenance burden becomes the hidden cost of mimicking familiar tooling. The article argues that every extra layer added to preserve shell-like behaviour brings its own correctness and lifecycle burden. That matters in agentic AI because operational teams will own the abstraction long after the proof of concept is done. Practitioners should choose the smallest control surface that still preserves the agent’s real work model.

From our research library:

• 62% of organisations are at least experimenting with AI agents, but only 23% have scaled one into a single business function, according to McKinsey's 2025 State of AI survey.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Locality collapse: when repeated backend reads are disguised as local file access, teams lose sight of the real control boundary and overestimate how simple the agent workflow is. For agentic AI programmes, the practical lesson is to govern data retrieval as a distinct event, not an invisible side effect of the interface.

Agent harness design is drifting toward a clearer split between retrieval and composition, and that is the more governable pattern. Use native query access for discovery, then move to local analysis where auditability, reuse, and tool richness are easier to control.

For practitioners

• Materialise analysis data locally Use a database query to pull only the needed slice, then let the agent finish the task against a local file set instead of re-reading the source system on every step.
• Separate retrieval from composition Keep SQL for search, filtering, and aggregation, then hand off to native shell tools for joins, comparisons, and repeated passes over the same data.
• Measure locality pressure in evals Test agent harnesses on questions that require repeated reads, intermediate staging, and multi-pass synthesis, because that is where fake filesystem designs usually break down.
• Account for wrapper maintenance Treat any filesystem-like abstraction over a database as an additional system to version, validate, and maintain as schemas and query patterns change.

Key takeaways

• AI agents do not need a filesystem metaphor to work well with database data, and the article shows that the metaphor can hide the real access pattern.
• The SQL-plus-local-shell pattern is stronger because it preserves composability after the first retrieval, which matters more than interface familiarity.
• For practitioners, the design choice is less about making tools look familiar and more about preserving a clear, governable boundary between data access and analysis.

Key terms

• Locality: Locality is the degree to which an agent can continue working on data after it has been materialised near the execution environment. In practice, it determines whether analysis happens on a reusable local copy or through repeated remote reads, which has direct implications for latency, composability, and auditability.
• Filesystem abstraction: A filesystem abstraction is a layer that makes another system look like files and folders so familiar commands can be used. In agent workflows, it can simplify interaction, but it also hides the real backend operations, permissions, and performance costs behind a more comfortable interface.
• Materialised Working Set: A materialised working set is the subset of data an agent has already pulled into a local environment for repeated use. It reduces dependency on the source system during analysis and makes multi-step reasoning, re-reading, and composition with local tools much more reliable.
• Composability: Composability is the design principle that allows systems to be assembled and reassembled from modular parts. In identity architecture, it supports adaptation by letting organizations combine services, swap components, and build new workflows without redesigning everything. It depends on interoperable building blocks, but it is not the same as interoperability.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners who need to govern machine access, tool delegation, and identity lifecycle decisions across modern security programmes.