An AI agent is only powerful when it can access the right data.

A model can be excellent at reasoning, code generation or planning and remain almost useless when facing a real business process. It knows language, general concepts and patterns learned during training. It does not know the current stock level, the latest version of an internal procedure or the specific constraints of a customer.

The operational power of an agent comes from combining model capabilities with the data it can access at the moment of action. Without relevant data, it reasons in the abstract. With the right data, the right tools and a properly scoped access layer, it can understand a situation, verify assumptions and produce a useful action.

The model provides reasoning; data provides operational knowledge

Model weights contain general knowledge frozen at training time. A company operates with live information: versioned documents, tickets, orders, metrics, maintenance history, conversations, customer databases and production state. Most agentic value lies in bridging that gap.

An agent diagnosing a failure needs the actual machine configuration, recent events, component documentation and previous interventions. A software agent needs the relevant repository, project conventions, tests and current build state. The model cannot reliably infer these elements from general knowledge alone.

Increasing parameter count does not solve this problem. The structural question becomes: which data should be available, in what form, with what freshness and for how long?

Access does not mean dumping all data into context

A larger context window is not a data architecture. Loading entire folders indiscriminately increases noise, inference cost and the chance that the agent relies on secondary or outdated information. Reasoning quality often depends more on context precision than on context volume.

An effective agent builds context dynamically. It starts with a mission and a few identifiers, then uses search, metadata, structured queries or business tools to retrieve only what is needed. Context becomes the result of controlled exploration rather than a bulk copy of the information system.

RAG fits into this model, but it is only one part of it. Semantic search works for documents and unstructured knowledge. The exact state of an order, a recent metric or a contractual entitlement should instead come from an authoritative source queried through an API or a typed request.

The sandbox becomes a programmable data boundary

A sandbox gives the agent a space in which useful data can be composed without opening the entire infrastructure. It can mount a document corpus read-only, expose a RAG index, provide an API client with a dedicated identity and reserve temporary storage for artefacts produced during execution.

This perimeter is not merely restrictive. It defines what the agent is capable of knowing. A well-equipped sandbox is therefore a knowledge envelope as much as an execution envelope. It combines reference data, the state required for the mission and the tools able to query the relevant systems.

Two agents using the same model can consequently have very different operational skills. One knows the product catalogue and CRM required to prepare an offer. Another can access a Git repository, logs and a test environment. Specialisation comes not only from the prompt, but from the topology of exposed data and capabilities.

Separate reference data, workspace and systems of record

Reference data such as procedures, contracts and technical documentation can generally be consulted without being modified. It is suited to read-only mounts, versioned snapshots or private search indexes.

The agent also needs a workspace. It extracts files, produces code, converts documents and stores intermediate results there. This space can be ephemeral so that every mission begins from a reproducible state and artefacts from one execution do not contaminate the next.

Systems of record — ERP, CRM, production databases or ticket managers — require a different interface. The agent should not receive a general database connection when a business API can expose a more precise view. Available operations, visible rows and authorisation duration then become explicit properties of the integration.

The agent identity should carry the mission scope

Data access benefits from being attached to a short-lived execution identity. A credential broker can issue a token scoped to one customer, project or set of operations without placing the primary secret in model context. ABAC or RBAC policies, row-level security and tool façades apply that perimeter outside the prompt.

This architecture is more robust, but also more powerful. The agent can operate autonomously within clearly defined rights without requesting approval for every read. Human intervention focuses on privilege elevation, a scope change or an action whose impact exceeds the original mission.

Control is therefore not opposed to autonomy. It enables deeper access to genuinely useful data because that access is attributable, revocable and bounded in time.

Less data can produce a better agent

Limiting scope does more than reduce exposure. It also improves system quality. A clearly identified source set reduces version collisions, contradictions and irrelevant retrieval. More of the context window remains available for decision-relevant elements.

This precision directly affects latency and cost. Queries are smaller, embeddings more targeted and tool calls more predictable. It also simplifies evaluation: a response or action can be linked to the documents, database rows or API results that produced it.

For an agent, context relevance is an engineering resource. It can be measured through freshness, source authority, mission coverage and the proportion of retrieved data actually used in the decision.

Reading, writing and acting are three different levels

An agent can have broad read access while retaining a much narrower write path. It analyses several sources, works inside its sandbox and produces a candidate artefact. Promotion to a repository, CRM or production system then occurs through a dedicated API, rule or review.

This separation preserves fluid reasoning and experimentation. The agent is not interrupted while searching, comparing or testing. Control occurs where information becomes a mutation, external communication or irreversible decision.

Autonomy can evolve with the metrics. An operation initially subjected to review can become automatic once its success rate, traceability and reversal conditions are sufficiently established.

Traceability links every action to its knowledge

An agentic execution should make it possible to reconstruct not only the tools called, but also the data that informed the decision. Document identifiers, versions, queries, API responses and artefacts can be associated with the agent trace.

This data lineage turns observability into an improvement tool. An error may come from the model, incomplete retrieval, an outdated source or an ambiguous tool contract. Without that distinction, optimisation is reduced to prompt changes. With it, the team can improve the context pipeline, access policy or data interface.

An agent’s power depends on the quality of its access

The value of an agent is not determined only by the model or the number of available tools. It depends on obtaining the right information, at the right time, from an authoritative source, then acting within a perimeter consistent with its mission.

The sandbox materialises this contract. It does not isolate the agent away from data; it builds a selective interface between its reasoning and the information system. Too little access produces a theoretical agent. Indiscriminate access produces noise and an architecture that is difficult to govern. The objective is precise, dynamic and observable access.

Tom Cheniaux - rephrased using AI