🎛️ The agent that reads data should not move operations
Separate Retrieval, Proposal, and Execution
In the control room of a retail chain there is already an agent answering inventory gaps, checking delayed orders, and drafting explanations for stores. The atmosphere shifts when someone asks whether it should also reschedule a transfer between warehouses or touch the ERP, because the pilot looks helpful while it reads data, but its operating radius stops being harmless the moment it gets close to execution.
Designing agents over enterprise data looks more like enabling an operator in the cabin than opening another chat window, because the value depends on deciding what it can see, what it can execute, who can stop it, and how every step is written into the logbook.
The useful technical term here is an agent with tools over enterprise data, a system where the model does more than talk and instead queries sources, calls APIs, runs searches, or proposes actions over business systems. As a teaching aid for a non technical reader, it helps to picture a control center where each operator sees a specific set of monitors and only some can authorize dispatch, although that image is only a bridge and the correct term remains an agent with tools.
Anthropic published a guide in December 2024 based on real implementations and advised teams to start with the simplest possible solution, then add complexity only when outcomes improve, and Microsoft reached a similar conclusion in Architecture Center in 2026 by noting that a single agent with tools is often the reasonable starting point for enterprise cases and that multiagent patterns only justify themselves when specialization or security boundaries demand them. That convergence matters operationally because if the task fits retrieval, clear rules, and a reviewable output, there is still no reason to release an autonomous agent into live processes.
That is why the first serious architectural cut is the separation between reading and execution, so an agent that answers questions about receivables, inventory, or contracts should first go through approved views, semantic layers, or retrieval indexes that already respect business definitions and filters instead of speaking directly to transactional tables or write APIs. Microsoft also warns that every pattern carries its own failure modes, from tool loops to conflicts over shared state, so the architecture needs iteration limits, deterministic routes when the flow is predictable, and human escalation when the case leaves the script.
Identity and permissions come right after that, and least privilege matters more here than in a static dashboard, given that the agent often has more discovery power than an average user and can assemble fragments until it reveals something nobody intended to expose as a whole. Microsoft Architecture Center insists on security trimming in every agent, a rule that forces the answer to respect the scope of the user who asked and not the broad scope of the service performing the search, so the agent does not behave like a shift replacement that received access to every console even though it was only enabled to read one indicator.
NIST organizes this problem through four functions that are easy to remember, govern, map, measure, and manage, and the value of the framework is not turning it into a mechanical list because the playbook itself says it is not a universal checklist. Its real contribution is forcing every system to have an owner, a risk context, a measurement rule, and a containment response before it receives tools, which fits data agents especially well because the serious error rarely starts with a badly written sentence and usually appears when no one defined scope, evidence, and rollback.
Usable traceability enters at that point, so a data agent should leave a record of the original request, the plan it followed, the tools it invoked, the sources it touched, the policy it applied, and the result delivered to the user. Anthropic recommends stop conditions and environmental feedback at every step, while Microsoft calls for instrumenting operations and agent transfers end to end, which in less technical language means the cabin needs a logbook and a formal handover.
Evaluation demands a different discipline, because an agent that queries enterprise data cannot be validated only with a clean demo or exact string matching when its outputs can be useful, half correct, or dangerous even while sounding confident. AgentDojo, a benchmark from ETH Zurich and Invariant Labs published in 2024, assembled 97 realistic tasks and 629 security test cases where even leading models fail many tasks without any attack, and that finding reinforces Microsoft guidance to use rubrics for nondeterministic flows and to treat tool returned content as an active risk surface.
In a logistics operator the difference between improvisation and solid design shows up fast when an agent is asked to inspect inventory in Bogota, read delayed orders, and suggest replenishment between distribution centers. If the team gives it direct access to a production database with read and write privileges, plus a stock movement tool with no approval gate, the agent sits one step away from turning a doubtful inference into a real operational change.
Look at a simple contrast in a typical integration.
unsafe = Agent(tools=[
SqlTool(conn="erp_prod_rw"),
MoveStockTool(),
])
unsafe.run(
"review Bogota inventory and move 200 units from Cali if you see shortages"
)
safe = Agent(tools=[
ApprovedViewQuery(view="inventory_readonly"),
ReplenishmentProposalTool(),
ApprovalGate(role="operations_supervisor"),
])
plan = safe.run("review Bogota inventory and propose replenishment")
safe.tools["ApprovalGate"].request(plan)
The first agent confuses observation with authority because it reads and acts through the same channel, with no layer separating visibility from intervention, no approved views, and no explicit approval step for the sensitive maneuver. The second agent still automates useful work, but it does so over a read only view, produces a legible proposal, and reserves execution for a supervisor, which for a non technical reader resembles separating monitoring, recommendation, and authorization inside the same cabin.
Something similar already happened with the automation wave that came before these agents, and the Nordea Bank case documented by Aalto University and Hanken School of Economics in 2021 did not revolve around whether software robots typed faster but around how to govern development, maintenance, and infrastructure once automation touched transactions, reporting, and regulated queries. The lesson still holds because when a new capability enters critical processes, the human load shifts toward exceptions, permissions, support, and operational accountability, not toward the speed of the demo.
That is why data agents do not erase the teams who understand the business and instead shift their work toward decisions that used to remain distributed or implicit. The process owner must define which decision can accept a suggestion and which one requires approval, the data team needs to publish views and dictionaries the agent can read without inventing unsafe joins, security and compliance must define which tools may exist and what evidence must remain, and operations keeps the right to stop the shift when a repeated deviation appears.
There is an important nuance so that this advice does not become dogma, because an internal agent that summarizes public manuals or explains ticket status can live with a much lighter architecture than one that queries personal data, touches prices, moves inventory, or prepares a regulatory answer. In low risk scenarios, controlled reading, visible citations, and an iteration cap are often enough, while in sensitive scenarios it makes sense to add a maker reviewer loop where one agent proposes and another validates against explicit criteria, human approval on specific calls, separated environments, and attack testing before opening production access.
A sober way to begin fits on a single design sheet with an allowed case, authorized sources, exposed tools, role scope, forbidden action, iteration limit, approval rule, expected logbook, and security test before shift. If that sheet still has blanks, the agent is not ready to sit in the cabin yet and operations should not find out about the experiment through a wrong dispatch.
Summary
Un agente que consulta datos empresariales vale menos por lo que redacta que por el radio de acción que se le asigna. La evidencia de NIST, Anthropic, Microsoft, AgentDojo y el antecedente de Nordea apunta a la misma conclusión, separar lectura y ejecución, aplicar permisos mínimos, dejar rastro de cada herramienta y evaluar por escenarios reales importa más que la espectacularidad de la demo.