Overview
Production Readiness
0.6
Novelty Score
0.5
Cost Impact Score
0.6
Citation Count
0
Why It Matters For Business
Treating resources as files and actions as code reduces integration work, makes agent behavior auditable, and lets teams reuse existing DevOps practices to manage agent artifacts.
Summary TLDR
This short position paper argues that a decades-old Unix idea—treat diverse resources as files—reappears as a practical design principle for autonomous AI agents. The authors trace the idea from Unix to DevOps ("everything as code") and to modern agents that use file-like memory, code as the action language, and file-based context retrieval. For practitioners the paper recommends: expose resources via a file-like namespace, let agents generate code (with sandboxing) instead of bespoke tool integrations, and use DevOps tooling for versioning and auditing. The paper is conceptual and cites industry examples (Anthropic, Cursor) and frameworks (AIGNE).
Problem Statement
Modern agents must talk to many different systems—APIs, databases, vector stores, cloud consoles, UIs—each with different interfaces. That interface proliferation makes agents hard to build, maintain, and audit. The paper argues that collapsing these interfaces into a uniform, file-like abstraction plus code execution reduces complexity and improves composability and traceability.
Main Contribution
Historical analysis connecting Unix's 'everything is a file' to DevOps and current agent design.
Argument and evidence that file-like namespaces and code-as-action simplify agent architectures.
Practical guidance for builders: use file-backed memory, let agents write code, and reuse DevOps tools for auditing.
Key Findings
Practitioners are converging on filesystem and code abstractions for agent context and actions.
Code as an action language reduces the need for many custom tool integrations.
File-backed memory supports multi-agent workflows and persistent context.
DevOps practices transfer directly: versioning, CI/CD, and diffs improve agent auditability.
The file abstraction has practical limits: non-text formats and very large corpora need extra tooling.
Who Should Care
What To Try In 7 Days
Expose one external resource (API or DB) through a small file-backed adapter and let an agent read/write it.
Store conversation history and agent plans as versioned files in git to enable auditing.
Prototype one capability by having the agent generate code (SQL or Python) and run it inside a sandboxed runner.
Agent Features
Memory
- file-backed conversation history
- shared file namespace for memory
- searchable files for context retrieval
Planning
- plans persisted to files
- spawn subagents that write/read shared files
Tool Use
- code generation instead of bespoke tool APIs
- CLI over filesystem
- code interpreter
- web fetch
Frameworks
- AIGNE
- Anthropic multi-agent system
- LangChain
- LlamaIndex practices
Is Agentic
true
Architectures
- file-system abstraction
- code-as-action
- lead agent + subagents orchestration
Collaboration
- shared memory for agent coordination
- parallel subagent search with file returns
Reproducibility
Open Source Status
- unknown
Risks & Boundaries
Limitations
- Non-text formats need parsing before use with file reads.
- Very large document collections require indexing beyond simple file search.
- Code-execution paths require sandboxing to avoid unsafe actions.
- File abstraction sacrifices some specialization and may not fit every protocol.
When Not To Use
- Low-latency device control where spool-and-read is too slow.
- Highly specialized binary protocols that don't map to textual files.
- Massive corpora without an indexing/retrieval layer.
Failure Modes
- Agent writes unsafe or insecure code that is then executed.
- Stale or inconsistent files cause agents to act on outdated context.
- Insufficient parsing leads to wrong interpretation of binary or structured files.
- Over-reliance on file semantics hides necessary specialized APIs.
Core Entities
Models
- Claude Code
- Cursor