Topic starter
19/08/2026 4:00 pm
TL;DR: A filesystem-like abstraction was competitive on simple reads, but the SQL workflow won on overall accuracy, composability, and maintenance burden because it let the agent materialize data locally and use real shell tools, according to Arize. The lesson is that locality, not interface familiarity, is the governing design choice for agent harnesses.
Editorial analysis by NHI Mgmt Group, based on content published by Arize: “PostgresFS vs. SQL skills: should AI agents fake a filesystem?”.
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.
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.
Q: What do teams get wrong about database-to-filesystem patterns for agents?
A: They confuse a familiar interface with a better execution model.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:37 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agents perform better with local SQL than fake filesystems