How an AI Agent Actually Reads a File (It's Not the Model)
File access is the first real-world integration most Agents need, and getting it wrong—by trusting model output or skipping path validation—opens a direct security hole. Understanding the harness as the gatekeeper, not the model, is the foundation for safely adding write operations, shell commands, and network access later.
Large language models run on remote servers with no access to a local file system. A file-read operation in an AI Agent is a structured handoff: the model returns a Tool Call specifying which file it needs, and a local harness validates the path, reads the bytes, and injects the content back into the model's context window. The model never touches the disk.
This process involves five participants—user, model, harness, tool function, and file system—and splits every tool into two halves: a Schema that describes the function to the model, and an Executor that performs the real I/O. The harness enforces strict checks on tool type, tool name, and parameter validity before any code runs, and it normalizes paths to prevent directory traversal attacks.
A single read requires two model requests: one to get the Tool Call, and a second to supply the file content as a Tool Result matched by `tool_call_id`. This forms a minimal decision-action-feedback loop, but it is not yet a full Agent Loop because the implementation stops after one tool call instead of looping until the model stops asking for more tools.
Many developers assume the model 'reads' a file, but the model only ever sees text that the harness explicitly places into the messages array—this mental model shift is the difference between building a safe Agent and a dangerous one.
The `additionalProperties: false` constraint in the Tool Schema is an underappreciated signal: it tells the model not to invent parameters, which reduces hallucinated tool calls before they reach validation.
Limiting file reads to 8,000 bytes is a pragmatic token-management strategy, but it also creates a silent failure mode where the model answers from truncated data without knowing what was cut—production systems need explicit truncation markers and ideally ranged reads.
The article's deliberate choice to handle only `tool_calls?.[0]` and stop is a useful teaching constraint, but it also highlights how many 'Agent' demos are really single-step tool invocations dressed up with a chat interface.