Data Platforms for Enterprise AI Agents

1. How would you design a data platform for an enterprise AI agent?

Answer: Use layers for source integration, data preparation, retrieval, agent orchestration, and governance.

1. Connect sources: integrate warehouses/lakehouses, business APIs, document repositories, ticketing systems, and operational databases through approved connectors.
2. Ingest and prepare: validate schemas, normalize records, preserve source IDs and timestamps, and apply classification and retention rules. For documents, extract text, create meaningful chunks, and retain document versions and metadata.
3. Publish retrieval-ready data: expose governed SQL views or semantic models for analytics; use lexical and vector indexes for document retrieval.
4. Build controlled tools: provide narrow interfaces such as query_sales_metrics, search_policy_documents, and create_support_ticket. Validate arguments and enforce permissions inside every tool.
5. Orchestrate safely: let the model choose among approved tools, while deterministic code controls identity, query limits, approvals, retries, and state transitions.
6. Observe and govern: log tool calls, source references, policy decisions, latency, costs, and failures. Redact sensitive values.

Enterprise sources
  -> ingestion, validation, classification
  -> warehouse / document repository
  -> SQL views + lexical index + vector index
  -> authorized retrieval and action tools
  -> agent orchestration
  -> grounded response with source references

Design principle: the source system remains authoritative. Search indexes and vector stores are derived systems that need lineage, refresh, and deletion handling.

2. How should an agent retrieve information from a data warehouse and a document repository?

Answer: Use different retrieval strategies for structured and unstructured data, combining them only when the question needs both.

• Warehouse: expose approved views or semantic models. Generate constrained query plans, validate SQL, use read-only credentials, and return only required columns and aggregates.
• Documents: extract text and metadata, chunk by meaningful sections, and index with keyword and/or vector search. Preserve document ID, section, version, classification, and update timestamp.
• Route queries: SQL for exact metrics and aggregations; lexical search for exact names, IDs, and phrases; vector search for semantic questions. Use hybrid retrieval when both meaning and exact terminology matter.
• Ground results: return source IDs, timestamps, query filters, and relevance signals. Cite document passages and specify metric periods.
• Resolve conflicts: apply source-of-truth rules or disclose disagreement rather than silently selecting a value.

Example: For “Why did regional revenue decline, and what did the sales team say?”, query governed warehouse metrics by region and period, then retrieve authorized meeting notes for the same context. Keep measured facts separate from narrative interpretation.

Avoid this failure mode

Never let the model invent SQL results or citations. Execute the query, return actual rows, and require evidence references for claims based on retrieved content.

3. How would you keep an agent's knowledge current when source data changes?

Answer: Treat indexes as materialized views of source data. Define freshness objectives and use change events where possible, plus periodic reconciliation to catch missed updates.

1. Detect changes: use CDC, repository webhooks, source APIs, modification timestamps, or scheduled scans. Capture creates, updates, deletes, and permission changes.
2. Propagate incrementally: update affected records/chunks. Recompute embeddings when content or the embedding model version changes.
3. Version records: store source ID, checksum/version, source modification time, ingestion time, and index version.
4. Handle deletes/revocations: remove or tombstone content and propagate ACL changes promptly.
5. Reconcile: compare source inventories with indexed records and retry failures through a repair workflow.
6. Monitor: track source-to-index lag, failures, missing records, and stale-result rates.

A vector index may be eventually consistent, but high-risk facts—such as current account status or entitlements—should be fetched from the authoritative source at query time rather than relying only on embeddings.

4. How would you implement access control when an agent queries enterprise data?

Answer: Enforce authorization at the data/tool boundary for every request. Authentication identifies the user; authorization evaluates what that user may access for this action and resource. The model must not decide permissions.

• Propagate identity: authenticate the user and pass verifiable identity or delegated credentials to retrieval tools.
• Apply source permissions: use warehouse row/column security, document ACLs, tenant boundaries, and approved service identities.
• Filter before model context: apply permission filters during retrieval or validate each record before passing it to the model. Filtering only the final answer is too late.
• Least privilege: give each tool only the permissions needed. Prefer read-only credentials for analytics and separate write-capable tools.
• Protect consequential actions: evaluate policy and require human approval where appropriate for refunds, access changes, or critical updates.
• Audit decisions: record principal, resource, policy outcome, tool, and timestamp without unnecessarily logging sensitive payloads.

Authenticate principal
 -> authorize tool and data scope
 -> retrieve only permitted records
 -> validate/redact output
 -> pass permitted context to model
 -> audit access and provenance

Tip: hiding a tool from the model or adding “do not reveal confidential data” to a prompt is not access control. Enforce permissions in trusted code and the underlying data systems.

5. How would you make agent tool execution reliable when operations are retried?

Answer: Assume a call can time out after the downstream system completed the operation. Make tools idempotent where possible, track operation state, and distinguish transient errors from permanent failures.

• Idempotency key: assign a stable operation ID; the receiving service should deduplicate repeats or return the original result.
• Durable state machine: track REQUESTED, IN_PROGRESS, SUCCEEDED, FAILED, and REQUIRES_REVIEW.
• Bounded retries: use exponential backoff with jitter for transient errors, respect rate limits, and cap attempts and total time.
• Reconcile timeouts: check operation status before issuing the action again.
• Separate reads and writes: reads are often safe to retry; writes need idempotency, deduplication, or compensating actions.
• Approval and tracing: require confirmation for consequential operations and propagate a correlation ID across services.

Example: If a purchase-request API times out, query status using the same operation ID before trying creation again; otherwise a retry may create a duplicate.

Key nuance

Retry logic alone does not guarantee exactly-once side effects. Use idempotency at the system performing the action, durable operation tracking, and reconciliation.

6. How would you audit the data sources behind an agent's response?

Answer: Capture response provenance: tools called, sources and versions returned, evidence supporting the answer, and applicable policy decisions. Make it traceable without indiscriminately storing sensitive prompts or raw records.

• Request ID, timestamp, principal, and trace/conversation ID.
• Tool name, validated arguments, status, latency, and retry count.
• Warehouse query ID or approved view/version, relevant filters, and time range.
• Document IDs, chunk/section IDs, content versions, and source modification timestamps.
• Authorization outcome and policy version.
• Citations attached to answer claims and evidence IDs used.
• Model and prompt/template versions, subject to privacy and retention rules.

Return structured provenance with each tool result and preserve it through orchestration. Use access-controlled audit storage, define retention, and redact credentials and sensitive content. A citation shows where evidence came from; it does not prove the conclusion is correct, so source-quality checks and answer evaluation are still needed.

7. When should an agent use SQL, a search index, or a vector database?

Answer: Choose based on the question and data structure. These methods solve different problems and can be combined.

Method	Best for	Example	Concern
SQL	Filters, joins, metrics, aggregations	Revenue by region last quarter?	Governed schemas and safe query limits
Lexical search	Exact words, IDs, names, phrases	Find policy OPS-104	Limited semantic matching
Vector DB	Semantic similarity across text	Guidance on disputed payments	Stale embeddings and relevance tuning
Hybrid	Meaning plus exact terms	Find documents about a policy ID and its intent	Ranking, fusion, latency

Rule of thumb: SQL for quantitative truth and structured relationships; lexical search for exact terms; vector search for semantic discovery; hybrid when both matter. Apply authorization filters to every path and cite actual rows or passages.

8. How would you prevent an agent from accessing unauthorized or outdated data?

Answer: Use defense in depth. Authorization, freshness validation, and source-of-truth rules belong in trusted retrieval/tool services, not only in model instructions.

• Authorize at retrieval time: use the authenticated principal, current ACLs, row/column policies, tenant boundaries, and classification rules.
• Propagate revocations: process ACL changes promptly; for sensitive sources, re-check permissions against the authoritative repository.
• Enforce freshness: store source-modified and ingestion timestamps, set maximum ages, and refresh or reject stale results.
• Use authoritative reads: fetch mutable facts such as balances, entitlements, and order status from the source of record.
• Design safe caches: include user/tenant scope and relevant permission version in cache keys; invalidate when permissions or data change.
• Resist prompt injection: treat retrieved documents as untrusted data, not instructions. Document text must never override tool policy or grant permissions.
• Fail closed: if identity, permissions, freshness, or policy cannot be verified, deny sensitive operations or use an explicitly approved fallback.

Example: A user might have access to a policy when it is indexed and later lose access. The system must not continue serving the cached chunk just because the vector index has not refreshed yet.

Quick Revision Table

Topic	Key takeaway
Platform design	Layer integration, governed retrieval, controlled tools, orchestration, and observability.
Warehouse + documents	SQL for metrics; search for passages; combine with provenance.
Freshness	Incremental changes, versioning, deletion handling, reconciliation, and SLAs.
Access control	Enforce identity and authorization at every data/tool boundary.
Reliable actions	Idempotency, durable state, bounded retries, and timeout reconciliation.
Auditability	Preserve traces, source versions, policy decisions, and evidence references.
Retrieval choice	SQL for structured truth, lexical for exact terms, vector for semantic matching.
Stale/unauthorized data	Current permissions, freshness checks, authoritative reads, cache invalidation, fail-closed rules.

Scenario-Based Follow-up Questions

Practise explaining your choices and failure handling aloud.

Scenario 1: A user asks for revenue data and confidential planning documents. What should the agent do?

Authenticate the user, query approved views within their permitted scope, and retrieve only documents allowed by current ACLs. Return authorized metrics and permitted passages with citations. Do not expose denied content or its existence beyond policy.

Scenario 2: A deleted policy still appears in vector search. What do you do?

Propagate deletion/tombstone events, invalidate caches, and check source status/permissions for sensitive content. Alert on reconciliation gaps, repair the index, and measure how long deleted content remained retrievable.

Scenario 3: An agent retries a timed-out refund. How do you prevent duplicates?

Use a stable idempotency key and durable operation record. Query the payment provider for operation status before retrying, and require approval for high-impact actions according to policy.

Scenario 4: An executive asks why revenue fell. How do you ground the answer?

Calculate the change with governed SQL metrics and explicit periods, then retrieve authorized reports or notes for context. Separate measured facts from hypotheses, cite sources, and disclose when evidence does not establish causation.

Chapter Summary

A trustworthy enterprise agent depends on its data access layer. Keep systems of record authoritative, choose retrieval methods suited to each data type, enforce permissions outside the model, make writes idempotent, preserve source provenance, and monitor freshness and access decisions.

Practice challenge: Design an agent that answers revenue questions from a warehouse and policy questions from documents, respects row-level and document permissions, and safely creates support tickets. Explain retrieval routing, freshness, audit records, retry behavior, and how prompt injection cannot change tool permissions.