Agentic AI Examples in the Enterprise: Five Production Architectures

The Problem

Procurement teams in mid-to-large enterprises spend a substantial share of their week on routine purchase-order management: matching requisitions to approved suppliers, checking contract terms, chasing missing documentation, and reconciling invoices against POs. Most of this work is rules-governed but noisy — suppliers deliver documents in different formats, contract clauses vary by region, and edge cases require judgment. Traditional RPA handles the happy path and breaks on everything else.

The Agent Architecture

A supervisor agent orchestrates three specialist sub-agents: a supplier-validation agent that cross-references requested vendors against the approved-supplier list and flags new entries for buyer review; a contract-compliance agent that retrieves the relevant master agreement from a vector index of contracts and checks whether the requested terms fall within approved bands; and an invoice-reconciliation agent that matches line items between the invoice, the purchase order, and the goods receipt.

Tools registered to the supervisor include scoped connectors to the ERP (SAP, Oracle, or NetSuite), the contract vector store, the supplier master database, and an email tool for requesting missing information from suppliers. Every write action — creating a PO, releasing a payment hold, updating the supplier master — is routed through a human approval queue. The supervisor owns the workflow state in a Temporal workflow so that a multi-hour PO processing task survives restarts and can be inspected step by step.

What We Learned

The hardest engineering problem was not the LLM reasoning. It was the contract retrieval layer. Master agreements are long, heavily formatted, and full of defined terms that reference other clauses. Naive chunking destroys the contextual relationships; plain vector search returns semantically similar but contractually irrelevant passages. The fix was a hierarchical retrieval pipeline — clause-level chunks with document-level metadata, retrieved together and re-ranked by a cross-encoder. Once retrieval worked, reasoning quality jumped dramatically. Teams that skip this step end up blaming the model for what is actually a data-engineering failure.

The Problem

B2B customer-success teams are drowning in signal: product telemetry, support tickets, CSM notes, renewal data, NPS responses, community mentions, and sales activity all carry information about account health. The manual analysis happens in quarterly business reviews, by which point it is late. What is needed is a continuous synthesis that flags at-risk accounts, identifies expansion opportunities, and drafts talking points for the CSM's next call.

The Agent Architecture

A scheduled agent runs per-account on a nightly cadence. It queries the product telemetry warehouse (Snowflake or BigQuery via a read-only analytics role), pulls recent tickets from the helpdesk, reads the latest CSM notes from the CRM, and fetches usage patterns from the billing system. The perception layer structures all of this into a consistent account snapshot before the reasoning layer runs.

The agent then classifies the account's trajectory — improving, stable, degrading, or at-risk — and drafts a CSM briefing note with specific observations, suggested actions, and evidence citations. The draft is delivered into the CSM's workspace (Slack, Gong, or directly in the CRM) before the account's scheduled call. Nothing is auto-sent to the customer; every customer-facing action remains a human decision informed by the agent's synthesis.

What We Learned

Evidence citation is non-negotiable. CSMs will not trust an agent's at-risk classification without being able to click through to the specific tickets, telemetry anomalies, or CSM notes that drove the conclusion. Every claim in the briefing note must link to its source, and the retrieval log must be inspectable. Once CSMs trust the citations, they use the agent. Without citations, the briefings are treated as noise regardless of how accurate they are.

The Problem

Regulated industries — financial services, healthcare, pharma — maintain compliance knowledge bases running into tens of thousands of policy documents, regulations, and internal procedures. When an operational question arises ("Can we proceed with this customer onboarding given their jurisdiction and risk score?"), the analyst has to find the relevant policy, interpret it against the facts, and document the decision. The search is slow, the interpretation is error-prone, and the documentation is often incomplete.

The Agent Architecture

A compliance agent answers operational questions by retrieving the relevant policy excerpts, reasoning over them against the facts of the case, producing a compliance determination with confidence, and emitting a complete audit-ready record of the policies consulted and the reasoning applied. The retrieval layer is hybrid — BM25 plus dense vector plus a re-ranker — because policy language is both semantically rich and heavy with specific terminology that exact-match retrieval captures better than embeddings alone.

The reasoning layer runs with temperature zero and is prompted to refuse confidently when the retrieved policies are insufficient. An explicit confidence threshold routes low-confidence determinations to a human reviewer queue rather than producing a speculative answer. Every agent run emits a structured log — query, retrieved policies, reasoning chain, determination, confidence — that is persisted in an immutable audit store.

What We Learned

Refusal is a feature. Early iterations of this agent over-answered: when policies were missing or ambiguous it produced plausible-sounding determinations that could not be defended in audit. Fixing this required explicit training in the prompt on what the agent should say when evidence is inadequate, and a confidence-based routing layer that treats "defer to human" as a first-class output. Enterprise compliance agents that cannot say "I don't know" are liabilities, not assets.

The Problem

Business users want answers from the data warehouse without learning SQL or waiting for the analytics team. Natural-language-to-SQL tools have existed for years; most failed in production because they generated SQL that was syntactically valid but semantically wrong — it joined the right tables incorrectly, aggregated by the wrong grain, or referenced deprecated metrics. The problem is not SQL generation; it is schema understanding and metric governance.

The Agent Architecture

The generative BI agent sits on top of a semantic layer (dbt metrics, Cube, or LookML) that defines canonical metrics, dimensions, and allowed join paths. When a user asks a question, the agent translates the natural-language request into a semantic-layer query — not raw SQL — which guarantees the result uses the governed metric definitions. The semantic layer compiles the query into SQL and runs it against the warehouse.

The agent's perception layer includes the metric catalogue, recent queries asked by this user, and the schema documentation. The reasoning layer disambiguates the request ("revenue" could mean GAAP revenue, billings, or ARR), asks clarifying questions when needed, and generates the semantic query with explanations of which metrics and filters it chose. Results are returned as structured tables and auto-generated charts with source-metric citations.

What We Learned

Without a semantic layer, generative BI is a liability. With a semantic layer, it is a force multiplier. The engineering investment is in the metric catalogue and the semantic-layer modelling, not in the LLM. Enterprises that try to point an agent directly at a data warehouse without governance end up with a system that produces different answers to the same question on different days — which is worse than no system at all. For deep treatment see our generative BI data warehouse architecture post.

The Problem

SaaS products compete on workflow efficiency. For many categories — legal tech, HR tech, project management, customer operations — the natural next frontier is an agent that executes the user's intent rather than surfacing a form for them to fill. A legal-tech product, for example, can go from 'here is a contract template' to 'describe the deal and we will draft the contract, flag risky clauses, and generate the redline against the counterparty's draft.'

The Agent Architecture

Agentic features inside a SaaS product sit on the product's existing data model rather than on enterprise integrations. The agent's tools are the product's own API endpoints, scoped to the current user's tenant and permissions. Short-term state lives in the session; long-term state (user preferences, recurring templates, learned patterns) lives in the product database alongside the user's other data.

The architectural shift is that the agent becomes a primary user of the product's API — which means the API has to be modelled as if agents, not only humans, are on the other side. That affects error messages (machine-readable with remediation hints), rate limits (per-agent-session rather than per-tenant), idempotency (write endpoints must safely handle retries), and observability (every agent action logged with the session and intent that produced it). Products that retrofit an agent onto an API designed only for humans consistently hit reliability walls that do not appear until load.

What We Learned

AI-native SaaS is an architecture decision, not a feature. Products that treat the agent as a first-class user from the start scale. Products that bolt an agent onto an existing surface ship demos that demo well and break at scale. For a deeper treatment see our AI-first SaaS engineering patterns post.