Agents reason.
They shouldn't process data.
Enterprise systems have thousands of users, entitlements, and audit records. Loading all of that into an AI model's context window is expensive, slow, fragile, and a security risk. Advanced Tool Use keeps data server-side and gives agents compact references and purpose-built operations instead.
95% fewer tokens. Sub-second responses. No context limits. No code sandbox. Every operation governed by the same control plane that governs everything else.
The data-in-context problem
When an agent needs to answer "which Engineering users have disabled accounts?", most platforms load every user record into the model. That approach breaks in four predictable ways.
Cost explosion
3,247 users × 33 tokens each = 107K input tokens per query. At scale, that's $11,680/year for a single connector. Multiply by ten connected systems.
Context overflow
System prompt, tool definitions, and conversation history already consume 20K+ tokens. Two large queries and the context window overflows. The agent crashes or hallucinates.
Speed degradation
Sending and processing 107K tokens takes 15–40 seconds. Users switch back to manual tools before the agent finishes thinking.
Security violation
All 3,247 user records — names, emails, job titles — transit through the LLM provider on every API call. Data minimization principles violated by design.
The shift: data stays server-side
Instead of sending data to the model, ATU keeps it server-side and gives the agent a compact URI reference plus a small preview. When the agent needs to filter, aggregate, or export, it calls purpose-built tools that operate on the server. The model only sees summaries and counts.
107,000 tokens · $0.32/query · 15-40s
200 tokens · $0.002/query · sub-second
Resource Links: the key primitive
When a tool returns a large result set, it doesn't serialize the data into the agent's context. It stores the data server-side in the ArtifactStore (Redis, 24-hour TTL) and returns a compact URI reference — a Resource Link — along with a small preview the agent can reason about.
The agent sees the summary. The data stays on the server. Subsequent operations — filter, aggregate, export — operate on the stored artifact by URI, creating new artifacts as they go. Each step costs ~200 tokens regardless of dataset size.
Technical deep-dive Resource Link URI scheme and envelope
URI Scheme
All Resource Links use the canonical empowernow-artifact:// URI: empowernow-artifact://{tenant_id}/{artifact_id}. The artifact_id is a ULID (128-bit, time-sorted, unguessable). The URI is opaque to the agent — it references server-side state, not a network endpoint.
Envelope Shape
When a tool returns a Resource Link, the response contains: uri (the artifact reference), mime_type (application/json), size_bytes, row_count, expires_at (24h TTL), and preview (a human-readable summary the agent can use for reasoning). The executor detects this shape and passes it through without attempting to inline the data.
Authorization Binding
Every artifact is bound to a 4-tuple: (tenant_id, run_id, subject_arn, agent_arn). This is stored in Redis alongside the artifact data with the same TTL. Cross-user access is denied at the store level — not by convention, by enforcement. If a different agent or subject attempts to read the artifact, the store returns 403.
Tool Chaining
Agents compose operations by passing URIs between tools. A filter creates a new artifact from the previous one. An aggregate reads the filtered artifact and returns inline stats. An export reads any artifact and produces a downloadable file. Each step operates on the previous step's output. Original artifacts are preserved — filters always create new artifacts, never mutate.
Four resource compute tools
Instead of giving the agent a code sandbox and hoping it writes correct Python, ATU provides four purpose-built tools that cover 90% of enterprise data operations. They use a restricted predicate DSL with seven enumerated operators — no arbitrary code execution, no injection risk, no sandbox escapes.
Returns the first N rows of an artifact so the agent can understand the data shape before deciding what operations to perform.
Applies a predicate (field + operator + value) and stores matching rows as a new artifact. The seven operators: equals, not_equals, contains, starts_with, in, gt, lt.
Groups rows by a field and applies a metric (count, sum, avg). Returns results inline — small enough for the agent to reason about directly.
Converts any artifact to a downloadable file (CSV, JSON). Returns an ArtifactHandle with a download button the user can click — data never enters the model.
Technical deep-dive Why not a code sandbox?
The Industry's Default Answer
Most platforms solve the data processing problem by giving the LLM a Python sandbox and letting it write code. We evaluated this approach and chose a different path — here's why:
Security
Code sandboxes carry known CVE classes — sandbox escapes, network exfiltration, filesystem access. Resource compute tools use seven enumerated operators in a restricted DSL. There is no code to inject. The attack surface is zero.
Reliability
LLMs write incorrect Python approximately 15% of the time. Resource compute tools are declarative predicates with deterministic execution. The agent specifies field, operator, and value. The server executes it exactly.
Infrastructure
Code sandboxes require new infrastructure — gVisor or Firecracker workers, network isolation, storage isolation. Resource compute tools reuse the existing Orchestration Service + Redis stack. Zero new containers.
Audit
Auditing generated code requires logging the code, the execution trace, and the output. Resource compute tools produce structured log events: field, operator, value, input artifact, output artifact, row counts. Trivially auditable.
Coverage
Filter, aggregate, and export cover 90% of enterprise data operations. The remaining 10% that requires truly custom computation is planned for Phase 2 with a hardened nsjail/seccomp sandbox — but only if customer demand proves the need.
Progressive Tool Discovery
EmpowerNow exposes hundreds of MCP tools across dozens of connected systems. Sending the full catalog to every agent would consume the context window before any real work begins. Progressive Tool Discovery (PTD) solves this with a three-tier approach — each tier narrows the set, and every tier enforces authorization.
22 pre-defined virtual MCP servers. Each agent sees only the servers assigned to its role. Hundreds of tools become a handful of relevant categories.
Within a virtual server, agents use tools/list?view= or semantic search to find relevant tools. Only permitted tools are returned — authorization is applied before results leave the server.
Full tool schemas (parameters, x-fields, AI context) are loaded only when the agent selects a specific tool to call. Context consumption stays minimal until the moment of use.
Technical deep-dive PTD internals: virtual servers, semantic search, and token telemetry
Virtual Servers
22 virtual servers defined in mcp_virtual_servers.yaml (699 lines). Assignment strategies include filter-based (by connector, category, system) and explicit assignment. Agents are assigned to servers via role mapping — a helpdesk agent sees helpdesk tools, not SAP provisioning tools. Servers materialize lazily: the catalog is computed on first request and cached.
Semantic Search
Tier 2 includes POST /api/v1/tools/search backed by a Neo4j FULLTEXT index. The query is hardened: token count capped at 20, query timeout at 5 seconds. Results return as (tool_id, score) pairs — no descriptions or schemas. Authorization filtering happens after search, before response: the ToolDiscoveryAuthFilter resolves each tool_id to its OperationRef and runs a PDP batch_evaluate. Only permitted tools survive.
Token Telemetry
PTD measures savings at three points: baseline (full catalog token count), tier-2 result (filtered catalog), and execution (actual LLM usage). Events publish to a Kafka analytics topic. Observed savings: 95%+ context reduction before the agent makes its first tool call.
Self-describing tools: CDA x-fields
Standard MCP tool schemas tell the agent what parameters a tool accepts. CDA x-fields tell the agent how to use them intelligently. Every tool parameter can carry four extension fields that make the agent smarter without adding complexity to the agent itself.
Provides valid values or suggestions so the agent doesn't have to guess. Reduces hallucinated parameters to near-zero.
Specifies transformation rules (lowercase, trim, format) applied before execution. The agent submits natural input; the tool handles normalization.
Marks parameters that carry elevated risk (irreversible actions, wide-blast-radius). Triggers additional confirmation or escalation gates.
Marks parameters containing sensitive data. Values are redacted from logs, proof receipts, and any surface the agent or auditor might see post-execution.
These fields are part of the CDA Engine — the same system that makes every tool a typed command object carrying its own schema, authorization requirements, and fulfillment path. x-fields extend that intelligence into the agent's planning phase, not just execution.
Compliance drift detection
No other platform offers real-time entitlement drift detection as an agent capability. ATU's entitlements.compare tool queries the Membership graph (Neo4j) to reconcile what's actually provisioned in an external system against what's been approved internally — and flags the gap.
Orphaned access
Users exist in the external system (e.g., Entra ID groups, SAP IAS SCIM groups) with no corresponding approved access directive. Access that shouldn't be there.
Missing provisioning
Approved access directives exist internally but haven't been provisioned in the external system. Access that should be there, but isn't.
An agent can ask "check SAP IAS for entitlement drift" and receive a structured breakdown of orphans and missing items in seconds — replacing a manual reconciliation that takes IAM teams 3–5 days per quarter. Large results are returned as Resource Links; the agent can filter, aggregate, and export them using the same four tools. See Fulfillment →
Governed artifacts
In most agent platforms, data outputs are ephemeral strings in the conversation. In EmpowerNow, every dataset and export is a first-class governed artifact with identity, lifecycle, authorization, and audit trail.
ULID-based identifier + empowernow-artifact:// URI. Globally unique, time-sorted, unguessable.
Redis-backed storage with 24-hour TTL. SHA-256 checksum on write. Immutable after creation — filters create new artifacts, never mutate.
Bound to the delegation context: tenant, run, subject, agent. Cross-user access denied at the store. Not by convention — by enforcement.
Every operation on every artifact — preview, filter, aggregate, export — is logged with the operation, the subject, the input artifact, and the output artifact.
This matters in regulated industries where data segregation is mandatory. When an auditor asks "who accessed this data and what did they do with it?" the answer is in the proof chain — not in a conversation log.
Works across every connected system
ATU resource tools operate on data from any connector in EmpowerNow's runtime. The same filter, aggregate, and export tools work whether the source data comes from Entra ID, SAP, Salesforce, or any of the 73 connected systems.
The governed execution plane
The real architectural shift isn't "better tool calling." It's the separation of reasoning from data handling, execution from trust enforcement. ATU is the data layer of that plane — and it connects to every other layer.
The model decides what to do. CDA tools carry the intelligence so the agent stays simple.
CDA Engine →Data stays server-side. Resource Links replace context stuffing. ATU tools operate on artifacts.
You are hereAuthZEN PDP governs every tool call. MCP Gateway enforces discovery scope. Proof chain records everything.
AuthZEN →ATU resource tools are MCP tools. Schema pinning, credential isolation, and receipts apply to every call.
Connector & Tool Factory →See ATU on your data
We run 30-minute live demos against your actual systems — your Entra ID, your SAP IAS, your AD. Not a slideshow. Not a sandbox. Filter 10,000 users by department in 200 tokens and see the token savings yourself.