An agentic data layer connects business questions to authorized, current records and carries evidence into any resulting action. Build it around explicit data contracts, source ownership, query controls and verified writes. A bigger model cannot repair an ambiguous customer identifier or an expired permission.
What changed: the research now has a different scope
The current version of the paper cited in the original article is RUBICON: Agentic AI for Messy Enterprise Data, revised on 3 September 2026. The April version used a different title. The revision argues for constrained source queries and table-based integration, rather than handing an unconstrained model the entire enterprise query workflow.
The authors report 100% end-to-end accuracy on their RUBICON-Bench and substantial efficiency improvements on SemBench. Those are results on the authors’ stated benchmarks, not proof that an enterprise agent will achieve perfect accuracy on your data. The useful takeaway is the architectural hypothesis: inspectable query structure and controlled integration deserve a place in your evaluation alongside free-form tool orchestration.
This guide applies that idea to practical operations. The contract, roadmap and acceptance tests below are editorial implementation recommendations. They are not results from the paper or a claim that one architecture wins every workload.
The agent data contract: define meaning before access
“Give the agent access to the CRM” is an incomplete requirement. Access to what customer population, for which purpose, with which freshness guarantee, under whose authority? Put the answers in a contract small enough that an engineer, a process owner and a reviewer can all understand it.
| Contract field | Concrete requirement | Failure it prevents |
|---|---|---|
| Business meaning | Define outstanding balance, currency, legal entity and whether disputed items count. | The agent joins incompatible financial measures. |
| Identity | Use a canonical customer ID and an explicit mapping for external system IDs. | A correct answer about the wrong customer. |
| Permission | Resolve tenant, user and purpose before fetching records; enforce the same boundaries on writes. | Retrieval becomes a route around existing access controls. |
| Freshness | Record source timestamp, ingestion timestamp and acceptable staleness for each field. | Yesterday’s payment triggers today’s collection message. |
| Provenance | Carry record IDs, query parameters, policy revision and evidence references. | A plausible answer cannot be investigated. |
| Action conditions | Specify permitted state transitions and required approval evidence. | Useful information is mistaken for permission to act. |
Start with the smallest complete business entity. For an invoice workflow, this could be an invoice ID, debtor ID, current balance, due date, dispute state, payment status and approved communication channel. Do not ingest the entire finance estate before proving that these fields reconcile.
Choose an owner for each definition. Two systems can both be correct and still disagree: one reports posted payments, the other pending bank transactions. The model should disclose that difference or defer a decision; it should not invent a reconciliation rule.
A reference architecture from question to verified action
- Authenticate the request. Bind user and tenant identity to the workflow before the model receives sensitive context. Keep the authorization decision outside text generation.
- Choose the source route. Use document retrieval for policy text, a constrained query for financial totals and a live API for order state. The route follows the question’s evidence needs, not whichever connector happens to be available.
- Normalize evidence. Return typed fields with units, identifiers and timestamps. A payment amount without currency is incomplete. A delivery ETA without a time zone invites a different class of mistake.
- Generate the proposal. Let the model explain or suggest a next step with references. Separate the evidence bundle from its prose interpretation so another component can inspect the underlying records.
- Apply action policy. Check limits, approval, destination and current record state. A retrieved document that says “ignore approval” is untrusted content, not a control-plane instruction.
- Execute and read back. Send an idempotent command, then confirm the resulting system state. A successful HTTP response is useful evidence, but a posted payment or message ID is the business completion criterion.
Current OpenAI retrieval documentation supports filtering by file attributes before semantic search. That can help narrow a knowledge search by relevant metadata. It does not, on its own, prove your authorization design is correct: the server must derive the allowed filter from trusted identity and test cross-tenant cases.
The OWASP guidance on vector and embedding weaknesses makes permission-aware access and dataset partitioning explicit concerns. Treat a vector index as part of the security boundary rather than a convenient copy of information that has already been “made safe.”
Worked example: an overdue invoice that was just paid
Illustrative scenario: a collections agent receives an event saying invoice INV-204 is overdue. A nightly export still shows an unpaid balance, but a live payment system reports a pending settlement. The customer also has an open dispute covering one line item.
A fragile workflow joins the export to a generated email and sends a demand for the full balance. A controlled workflow reads the latest payment and dispute records, calculates the remaining undisputed amount with deterministic code, and decides whether this account is eligible for contact. It can then draft a message for approval or pause while payment status is uncertain.
Store the event ID, source revisions and resulting decision together. If the same overdue event arrives again, reuse the workflow’s existing result or re-evaluate intentionally against a new state; do not send a second message simply because delivery was retried. Before releasing a draft, recheck the state if the evidence has expired.
The decisive test is not whether the email sounds professional. It is whether the agent avoids contacting the wrong debtor, demanding a settled amount or bypassing the dispute process. Those errors have measurable operational consequences even when the model’s language is excellent.
The value of an agentic data layer is that the business can explain what the agent knew, what it was allowed to do and what actually happened.
A phased plan that earns the right to expand
Phase one: one workflow and its sources. Map the process, define the business outcome, name data owners and build a reconciliation sample. Include missing values, conflicting IDs, late events and revoked access. A tidy happy-path dataset is not enough.
Phase two: read-only evidence assembly. Compare the agent’s answer with records a knowledgeable employee would use. Score source coverage, field correctness, permission isolation and freshness separately. A fluent explanation with the wrong invoice amount must fail.
Phase three: proposed actions in shadow mode. Record what the agent would do without allowing it to affect customers. Have reviewers classify errors by consequence and root cause. A wrong policy revision requires a data lifecycle fix; an unsupported calculation requires deterministic computation; a malformed tool argument needs a different correction.
Phase four: bounded execution. Enable only approved actions with retry protection, clear limits and a staffed exception queue. Expand autonomy after the workflow passes its agreed acceptance tests, not after a predetermined calendar date.
Choose service targets from the business decision. An analytics answer might tolerate an overnight snapshot. A refund or availability check may need current transactional state. Avoid a universal freshness promise that wastes infrastructure on low-risk data while leaving critical records stale.
Acceptance checklist
- Can an unauthorized user obtain another tenant’s evidence through any query route?
- Can the same event create two writes or two customer messages?
- Can the system identify which source is authoritative when records conflict?
- Does a deleted document disappear from search results and downstream caches as intended?
- Can an operator reconstruct the evidence and approval behind a completed action?
- Does a failed connector cause a safe pause or a confident fabricated answer?
Use the agent control-plane guide for runtime authority and the observability guide for evidence and incident investigation. The data layer supplies trusted inputs; those layers govern and explain the resulting behavior.
Questions about agentic data layers
Is an agentic data layer the same as a vector database?
No. A vector database can support document retrieval, but an agentic data layer also needs identity, permissions, structured data access, freshness, provenance and action conditions.
Does RUBICON prove that unconstrained agents never work?
No. The paper reports results on specific benchmarks. Use its constrained-query approach as a candidate architecture and evaluate it against your own workload and alternatives.
Should we move every enterprise dataset first?
No. Start with one workflow, reconcile the fields it needs and add sources only when a clear business or reliability requirement justifies them.
What should stop an agent from taking action?
Missing authorization, conflicting evidence, expired data, an unapproved state transition or an unavailable verification path should trigger a pause or human review.
Primary references checked for this edition
- RUBICON paper, version 3, September 2026 — the research scope and reported benchmark results.
- OpenAI retrieval guide — attribute filtering and retrieval capabilities.
- OWASP vector and embedding weaknesses — access partitioning and retrieval security.
Provider documentation and the paper were checked on 11 October 2026. Implementation patterns here are recommendations, not independently measured customer outcomes.
Research Path