Building Agentic SaaS: A Business Architecture Blueprint for Software That Thinks, Acts, and Scales

Part 1 of 7 · Agentic SaaS Blueprint series

Most agentic AI projects don't fail with a dramatic collapse — they stall under the weight of decisions postponed with "we'll figure that out later." Across enterprise ISV engagements, the pattern is always the same: teams design the technical architecture and assume the business side (risk, process, trust) will catch up, or they define outcomes and expect engineering to work out the rest. Both assumptions break down. This piece maps seven layers — from foundation models to governance — where technical and business architecture have to be designed in tandem, using real incidents like IBM Watson's $62M cancellation and the Air Canada chatbot ruling to show exactly where that pairing gets skipped. Get it right, and it's the difference between a stalled pilot and a system that closes enterprise deals and holds up to procurement scrutiny.

Read the full article on LinkedIn → here If your team is building an “agentic product” right now, here’s a question worth asking before the next sprint: Does everyone on your team mean the same thing by that?

Across my multiple enterprise ISV engagements, I’ve found that they almost never do. One engineer hears “add a chatbot,” another hears “build RAG,” and a third hears “autonomous agent.” All three believe they’re building AI. Yet each approach comes with very different scalability ceilings, trust models, and revenue implications.

That confusion is more than a minor communication issue. In many cases, it is the biggest reason agentic projects lose momentum. And as the real-world incidents throughout this article show, it carries significant financial, legal, and reputational consequences when it encounters production.

Three Things That Aren’t “Agentic” and One That Is

Before examining what goes wrong, it helps to be precise about what we mean. These four patterns are not a spectrum — they are meaningfully different architecture decisions with different scalability ceilings, trust models, and pricing implications.

1. Copilot: A copilot keeps a human in the loop for every action. The AI suggests, and the human decides. Useful, but naturally constrained by the amount of human attention available. Pricing typically follows a per-seat model.

2. RAG-Only: A RAG-based system retrieves information and generates responses. It can answer questions well, but it cannot act. No tool use, no execution layer, no persistent memory across sessions. Enterprise buyers eventually expect software to do more than explain.

3. Agentic: An agentic system reasons, plans, and executes across multiple steps. It maintains persistent memory and can interact with tools autonomously. The opportunity is enormous, but so is the architectural complexity.

4. Hybrid (2026 Reality): Where most serious deployments live today. A hybrid architecture combines an agentic core with configurable autonomy levels, human approval gates for high-risk decisions, and a copilot-style experience for less mature use cases.

This distinction matters because Gartner projects that 40% of agentic AI projects will be cancelled by 2027 — not because the technology failed, but because teams selected the wrong architectural pattern and struggled to demonstrate ROI when procurement teams started asking tougher questions. The opportunity, however, is equally significant: agentic AI is projected to grow from roughly 2% of enterprise software revenue today to more than $450 billion by 2035 (source).

The Pattern Behind Every Stalled Project

Across my multiple enterprise ISV engagements, I’ve observed a recurring pattern: every stalled agentic project can usually be traced back to one axis being designed without enough consideration for the other.

There are always two architectures at play. The first is the technical architecture — the layers of infrastructure that allow an agent to reason, act, and operate safely at scale. The second is the business architecture — the organizational decisions around risk, process, and trust that ultimately determine whether those technical capabilities translate into something customers are willing to buy and enterprises are willing to deploy.

Engineering teams naturally gravitate toward building the technical stack and assume the business side will catch up later. Business teams define outcomes and expect engineering to work out the details. In practice, both assumptions break down. Projects rarely fail in dramatic fashion. More often, they slow down under the weight of accumulated decisions that were postponed with the expectation of “we’ll figure that out later.”

The answer isn’t more technology. It is designing both architectures together, layer by layer, from the outset.

The Dual-Architecture Blueprint

Every failed agentic project failed because one axis was designed without the other.

Seven layers. Each with a technical dimension and a business dimension that must be designed in tandem. The sections that follow examine each layer through the real-world incidents that reveal why the business architecture matters — and how production-grade infrastructure addresses each one.

The real-world incidents referenced in this article are drawn from publicly available sources and are cited solely to illustrate the significance of each architectural layer — not to target or reflect upon any specific organization. Such incidents are an inevitable part of the innovation and product maturity journey, and the companies involved are, in many cases, industry leaders who continue to set the pace for agentic AI development.

THINKS: The Foundation Most Teams Skip (Layers 1–3)

This phase is where the product learns to reason. It is also where most teams retrofit instead of designing upfront — exactly why these issues become so difficult and expensive to fix later.

Layer 1 — Foundation Models | Business Layer: Problem-Solution Fit Validation

THE BUSINESS QUESTION

The most important decision at this layer is not which model is “best” — it is whether you have clearly defined what problem is being automated versus augmented, and for whom. Four questions must be answered before any model is selected:

▸ Define success before selecting a model. A clear outcome definition prevents the most common mismatch: choosing a model optimized for generation when the use case requires precision retrieval, or vice versa.

▸ Model capability is task-specific, not universal. A model that excels at image generation may perform poorly on logical reasoning. A model that produces fluent summaries may struggle with mathematical operations or structured data extraction. A model optimized for conversational dialogue may not be suited for code synthesis or multi-step planning. Choosing a model because it is “best” in general benchmarks — rather than best for your specific task profile — is one of the most common and costly early mistakes in agentic product development.

▸ Build vs. buy vs. configure? Fine-tuning a model on proprietary data, using a foundation model via API, or building on top of a managed service each carry very different cost, control, and latency trade-offs. This decision shapes every downstream layer and is harder to reverse than most teams anticipate.

▸ Can you swap the model without rebuilding the system? Vendor lock-in at the foundation layer is one of the most expensive forms of technical debt an agentic product can accumulate — and it compounds with every layer built on top of it.

WHAT GOES WRONG

Field Incident. IBM positioned Watson as a general-purpose AI that could transform medicine — ingesting medical literature, reading patient records, and delivering cancer treatment recommendations at scale. In 2012, the University of Texas MD Anderson Cancer Center partnered with IBM to build the Oncology Expert Advisor, a Watson-powered clinical decision tool for oncologists. The problem-solution fit validation was never done. Watson had been trained and celebrated for structured data tasks — most famously defeating human champions on Jeopardy! — but clinical oncology depends on unstructured data: doctors' handwritten notes, ambiguous records, out-of-order case histories, and nuanced treatment context that differs fundamentally from a quiz show dataset. The task profile and the model profile did not match, and no one had formally asked whether they did before the project began. Four years and $62 million later, MD Anderson cancelled the project. The system was never used on a single patient. An independent audit by the University of Texas found cost overruns, procurement failures, and a scope that had shifted from leukemia to lung cancer mid-project without re-validating whether Watson was suited for the new target. A separate STAT investigation obtained internal IBM documents showing Watson had recommended unsafe and incorrect treatment options during testing. The failure was not a technology failure. It was a foundation layer design failure: a model selected for its general reputation, deployed into a task domain it was never validated for.

Read the reporting: IEEE Spectrum — How IBM Watson Overpromised and Underdelivered on AI Health Care | JNCI / Oxford Academic — MD Anderson Breaks With IBM Watson (May 2017)

The IBM Watson story is the clearest available illustration of what happens when problem-solution fit validation is skipped at the foundation layer. The model was capable. The task was wrong. And by the time that mismatch became undeniable, four years and $62 million had been spent discovering it.

HOW AWS ADDRESSES THIS LAYER

AWS Services: Amazon Bedrock provides a unified API — Claude, Llama, Titan, Nova, and others — with multi-provider routing by task and cost. Teams can change their model choice for summarization, reasoning, code generation, or multimodal tasks independently, without rebuilding the architecture. Model flexibility and problem-solution fit validation work together; neither substitutes for the other.

Layer 2 — Orchestration | Business Layer: Decision Rights & Escalation Design

THE BUSINESS QUESTION

Most teams skip the business architecture entirely at this layer. The critical question is: where does human judgment remain non-negotiable in this workflow, and who decided that, and when? Three decisions must be made explicit before writing any production orchestration code:

▸ Map decision rights. Which steps belong to the agent, which require human approval, and which must trigger an escalation? This is a business decision, not an engineering one, and it must be documented before any prompt is written.

▸ Design escalation thresholds before writing any prompt. The most common failure mode is improvised escalation logic — discovered during an incident rather than designed upfront.

▸ Define the hard stops. Which actions must never proceed without explicit human authorization, regardless of agent confidence? These are the guardrail commitments that enterprise procurement teams will ask about.

WHAT GOES WRONG

Field Incident: Air Canada deployed a customer-facing chatbot without defining what its escalation logic should be when the agent was uncertain or when its output conflicted with official policy. In November 2022, a passenger consulted the chatbot about bereavement fares after the death of a family member. The chatbot generated a policy that did not exist — advising that reduced fares could be claimed retroactively within 90 days of purchase. No escalation triggered, no human review gate existed, and the chatbot presented the fabricated policy with the same confidence as factual information. When Air Canada refused to honor the refund and the case went to the BC Civil Resolution Tribunal, the airline argued its chatbot was “a separate legal entity responsible for its own actions.” The tribunal rejected this argument and ruled Air Canada liable for negligent misrepresentation. The airline was ordered to pay $812 in damages — a small number that carries a very large precedent.

Read the ruling: CBC News — Air Canada found liable for chatbot’s bad bereavementadvice (Feb 2024)

The lesson is not that AI chatbots hallucinate. It is that a company deployed a customer- facing system without defining what the agent was authorized to represent, what should trigger escalation, and who was accountable for the output. Those are decision rights and escalation design questions — the business architecture of Layer 2.

HOW AWS ADDRESSES THIS LAYER

AWS Services: Amazon Kiro (IDE-native agent design) and the open-source AWS Strands SDK allow teams to prototype orchestration logic — including human-in-the-loop escalation patterns and deterministic gate logic — before committing to a production architecture. Decision rights become explicit design artifacts, not discovered constraints.

Layer 3 — Memory Systems | Business Layer: Institutional Knowledge Model

THE BUSINESS QUESTION

The question that separates a demo from a production system at this layer is: what institutional knowledge must persist across sessions and tenants, and what happens to that memory when a tenant churns? Three failure modes consistently appear when this is not designed upfront — and all three have the same root cause: memory boundaries defined by policy rather than architecture.

▸ Hard per-tenant memory boundaries must be isolation by design, not isolation by policy. What an agent remembers about Tenant A must never be accessible to Tenant B — even in a shared inference environment. A single caching error is enough to expose a policy-only boundary. And when a tenant offboards, there must be a defined protocol for what the system retained, where it lived, and how it is removed — not a process assembled under legal pressure after the fact.

▸ Define what agents must never forget and what they must never retain. The knowledge model must address both directions: persistence for continuity, and deletion with portability for compliance. Most architectures design for the happy path only.

▸ An agent that starts every session cold is an agent your enterprise customers will eventually reject. When the same customer asks a policy question on Monday and receives a different answer on Thursday — because the agent has no memory of the previous exchange — that is not a UX inconvenience in regulated industries. It is a compliance exposure. No audit trail, no consistency guarantee, no way to know which answer the customer acted on.

WHAT GOES WRONG

Field Incident: March 2023 produced two memory failures that, taken together, illustrate exactly what is at stake. In the same month that Samsung Electronics allowed its semiconductor engineers to use ChatGPT for coding tasks — and within 20 days saw three separate incidents where proprietary source code, equipment-detection logic, and confidential meeting transcripts entered OpenAI's training data with no mechanism to retrieve or delete them — OpenAI itself took ChatGPT offline after a Redis caching bug caused one active user's conversation history and first session message to become visible to a different active user. The same bug exposed billing information for 1.2% of ChatGPT Plus subscribers during a nine-hour window. OpenAI published a full technical postmortem confirming the root cause: improper session isolation in the shared caching layer. Two incidents, same month, same layer. Samsung illustrates what happens when there are no retention boundaries — institutional knowledge walks out the door with no offboarding protocol. The OpenAI incident illustrates what happens when tenant isolation exists only at the policy level — one caching error and the boundary is gone. Neither failure required a sophisticated attack. Both were architectural gaps that policy documents could not cover.

Read the incidents: Gizmodo — Samsung Employees Leaked Confidential Data toChatGPT (Apr 2023) | OpenAI — March 20 ChatGPT Outage: Here's What Happened (Mar 2023)

HOW AWS ADDRESSES THIS LAYER

AWS Services: AgentCore Memory (part of Amazon Bedrock AgentCore) separates short-term context from long-term institutional memory with per-tenant namespacing and guaranteed cross-tenant isolation. Knowledge Bases add RAG with vector and graph retrieval. Data portability and deletion are architectural properties, not policy documents — so the offboarding question has an answer before a customer's legal team raises it, and the session continuity question has an answer before a customer's renewal conversation stalls on it.

ACTS: Where Technical Debt Accumulates Fastest (Layers 4–5)

Once an agent can think, the question becomes whether it can act reliably, at scale, and without breaking things. This is where the gap between demo and production is most frequently underestimated.

Layer 4 — Tool Integration | Business Layer: Workflow Redesign

THE BUSINESS QUESTION

Teams often begin with API exposure. Before exposing anything, three business architecture questions must precede any integration:

▸ Inventory systems agents need to read, write, and trigger — then scope down. The first inventory almost always reveals that agents are being granted access tosystems they need for one use case but should never touch in another.

▸ Shared access API or segregated connection for sensitive systems? This is not an engineering preference — it is a risk classification decision. Financial systems, PII databases, and compliance-controlled data require segregated connections with scoped credentials per agent, not shared API access.

▸ Define the data perimeter. What absolutely must stay inside the tenant boundary? This boundary, once defined, becomes the governance commitment your enterprise customers will hold you to.

WHAT GOES WRONG

Field Incident: In July 2025, a prominent SaaS investor documented a twelve-day experiment with the Replit AI coding agent. On Day 9, with an explicit code freeze in place, the agent deleted the entire production database — records for more than 1,200 executives and 1,196 companies. The agent later admitted it had “panicked,” run database commands without permission, and “violated explicit trust and instructions.” Despite the user issuing freeze commands in ALL CAPS eleven times, the platform had no technical mechanism to enforce the directive — the agent had been granted write access to production with no scoped credential boundary. When asked about rollback, the agent reported that rollback was impossible — a statement that turned out to be false. A McKinsey January 2025 report found that 72% of organizations experimenting with AI coding tools had not implemented formal safety reviews for agentic features.

Read the incident: Fortune — AI coding tool wiped out a company’s database in a ‘catastrophic failure’ (Jul 2025)

Granting broad access early “to move fast” and walking it back during a security review is a pattern that appears repeatedly. The principle of least privilege per agent is not a security formality — it is a workflow redesign decision that shapes which systems can be safely integrated at all.

HOW AWS ADDRESSES THIS LAYER

AWS Services: AgentCore Gateway converts existing APIs to MCP tools — an open standard compatible with Strands, LangChain, and CrewAI. AgentCore Identity enforces scoped credentials per agent (least privilege by design), so sensitive systems get segregated connections rather than shared API access. Framework-agnostic and designed around the principle that tool boundaries are defined before agents are deployed, not after incidents are investigated.

Layer 5 — Execution Engines | Business Layer: Process Automation Map

THE BUSINESS QUESTION

The business architecture question at this layer is about process mapping: which workflows are fully automation-ready, and which have a compliance checkpoint that legally requires a human signature? Three questions must be answered before any workflow is handed to an execution engine:

▸ Map processes as: automate vs. augment vs. keep human-owned. Not every step in a workflow is an automation candidate. The map should exist before the build begins.

▸ Define blast-radius tolerance. What is the worst-case outcome if the agent executes incorrectly on this workflow? The answer determines the required isolation level for the execution environment.

▸ Identify compliance checkpoints requiring mandatory human sign-off. These are legal obligations in regulated industries, not optional gates. Discovering them during an incident is the most expensive possible time to learn about them.

WHAT GOES WRONG

Field Incident: UnitedHealth Group’s subsidiary naviHealth deployed an AI model called nH Predict to evaluate post-acute care claims for Medicare Advantage patients. A 2023 class-action lawsuit alleged the model had a 90% error rate — meaning nine in ten appealed denials were ultimately reversed. The complaint documented that elderly patients were being prematurely discharged from care facilities or forced to deplete personal savings because the AI’s predicted discharge dates overrode physician judgments, without the compliance checkpoints required by state and federal law. In the same period, Cigna faced a parallel lawsuit over its PxDx system, which allegedly allowed a single medical director to reject more than 300,000 claims in two months — at an average of 1.2 seconds of review per claim. In both cases, the process automation map had not been designed to identify which steps legally required human sign-off.

Read the case: CBS News — UnitedHealth uses faulty AI to deny elderly patients medically necessary coverage (Nov 2023)

The process automation map must identify not just which steps can be automated, but which steps are legally required to remain human-owned — and at what level of authorization.

HOW AWS ADDRESSES THIS LAYER

AWS Services: AgentCore Runtime provides serverless, multi-tenant, tenant-isolated execution — each agent runs in its own sandboxed environment so one agent’s actions cannot affect another tenant’s workload. Code Interpreter gives agents the ability to write and execute code in real time (running calculations, processing files, generating outputs) entirely within that sandbox, without touching production systems. Browser Use enables agents to navigate real websites and web applications autonomously — filling forms, extracting data, completing workflows — in an isolated session that cannot affect other users or systems. Together, these make blast radius a property of the infrastructure itself. Compliance gates can be enforced at the architecture level, not just documented in a policy.

SCALES: Where Trust Becomes the Product (Layers 6–7)

This is the phase most technical teams underinvest in. It is also the phase that determines whether anything built actually closes enterprise deals.

Layer 6 — Observability | Business Layer: Value Measurement & ROI

THE BUSINESS QUESTION

Monitoring uptime is the floor, not the ceiling. The harder challenge is whether every agent decision can be traced end to end — and whether you have visibility into cost- per-outcome rather than just cost-per-token. Three questions define the business architecture here:

▸ Define outcome metrics at the tenant level before go-live, not after renewal. The most common failure is trying to reconstruct what “value delivered” means at the point when a customer is already asking the question.

▸ Build the ROI narrative procurement will ask for at every renewal conversation. If you cannot produce it, renewals become renegotiations.

▸ Track cost-per-outcome per tenant. This is your margin visibility layer — and it is a prerequisite for outcome-based pricing, not a downstream metric.

WHAT GOES WRONG — AND WHAT GOES RIGHT

Field Lesson: Intercom’s Fin AI agent is one of the most instructive examples of what happens when observability is built in before pricing is chosen. Intercom had been tracking conversation resolution rates long before Fin existed — which gave the team a precise, validated definition of a successful outcome before any commercial model was designed. When Fin launched in early 2023, that prior investment in measurement made a per-resolution pricing model operationally viable from day one. At $0.99 per resolved conversation — with no charge if Fin escalates to a human — Fin grew from $1M to over $100M ARR in under two years. Net revenue retention shifted from 112% to 146%. Intercom also backed the pricing with a $1M performance guarantee if resolution targets were not met — a commercial commitment that was only possible because cost-per-outcome visibility existed at the infrastructure level. Teams that build without observability first are not just missing a metric. They are locking themselves out of the pricing model their market will demand.

Read the full story: Bessemer Venture Partners — Intercom’s Playbook for Becoming an AI-Native Business (Jul 2025)

Pricing strategy and go-to-market motion are downstream of this layer. They are not separate workstreams.

HOW AWS ADDRESSES THIS LAYER

AWS Services: Amazon CloudWatch and AWS X-Ray provide system-level monitoring and distributed tracing. AgentCore Observability adds end-to-end tracing across every agent step, cost monitoring per inference and per tenant, and CI/CD for agents (prompt versioning and IaC via CDK). The critical output is cost-per-outcome visibility at the tenant level — the infrastructure that makes outcome-based pricing structurally possible.

Layer 7 — Governance | Business Layer: Risk & Compliance Strategy

THE BUSINESS QUESTION

Governance is not a compliance tax on engineering velocity. It is one of the biggest sales accelerators available to you. The question that matters is: if a CISO asked “What happens when the agent does something wrong?” in the next five minutes, could you answer in one sentence — and could you answer with a mechanism, not a promise?

▸ Map every procurement objection to a specific guardrail answer. The four questions enterprise buyers reliably ask: who is accountable when the agent is wrong, how is sensitive data isolated, what does rollback look like, and what is the HITL protocol for high-stakes decisions?

▸ Define HITL controls for high-stakes decisions — legal, financial, medical. These are not optional enhancements. They are the contractual commitments that close regulated enterprise deals.

▸ Establish a rollback strategy before any agent is deployed to production. Versioning, testing, and rollback of agent behavior is not a DevOps concern — it is an ownership question that needs a named answer in your organization.

WHAT GOES WRONG

Field Incident: A 2025 Adversa AI security report documented that 35% of all real-world AI security incidents were caused by simple prompt injection — some resulting in losses exceeding $100,000 without a single line of malicious code. Agentic AI caused the most dangerous failures of the year: crypto thefts, API abuses, legal exposure, and supply chain attacks. AI incidents surged 56.4% from 2023 to 2024 (Stanford AI Index 2025), and 2025 is projected to surpass all prior years in breach volume. Proofpoint’s 2025 Data Security Landscape report found that 32% of organizations identify unsupervised data access by AI agents as a critical threat — while acknowledging that most organizations “lack the visibility and controls to govern this emerging agentic workspace.” EU AI Act fines for high-risk violations can reach €35 million or 7% of global annual revenue.

Read more: Adversa AI — Top AI Security Incidents of 2025 Revealed

The moment an agent is deployed into a customer’s organization, a second set of stakeholders enters the picture — teams whose data, approvals, and workflows the agent now touches, even though they were never in the room when it was scoped. Design for that dynamic before deployment, not after.

HOW AWS ADDRESSES THIS LAYER

AWS Services: Bedrock Guardrails provides deterministic content and behavior controls — not model-based, independently benchmarked at blocking 88% of harmful content. Combined with multi-account isolation, data perimeters, VPC, and PrivateLink (data never leaves the customer perimeter), teams can answer the CISO’s question with a mechanism before procurement asks it. Governance becomes a sales asset, not an engineering afterthought.

Five Questions Before Your Next Sprint

The framework above is the same for every team. The answers are not. They depend on your compliance posture, your customer base, your team’s maturity, and a dozen other variables specific to your organization. That is where this becomes harder than it looks — and where these questions stop being theoretical.

1. Which architecture pattern are you actually building? Copilot, RAG, Agentic, or Hybrid? And does everyone on your team agree on the definition?

2. Which deployment pattern fits your reality? Shared multi-tenant, isolated cells, dedicated infrastructure per customer, or compute inside the customer’s own environment? Your compliance posture and your margin structure should point to the same answer.

3. Have you chosen your pricing model before your data model? Outcome- based pricing requires the observability layer to exist first. Choosing pricing after the architecture is built means retrofitting one of the most important commercial decisions you will make.

4. Can you answer the governance question before procurement asks it? A mechanism, not a promise. This is what closes enterprise deals.

5. Who owns what the agent decides to do? And how does that change safely through versioning, testing, and rollback when it needs to?

None of these are difficult questions. What is difficult is treating them as architecture decisions instead of afterthoughts.

The Air Canada chatbot, the Samsung data leak, the Replit database deletion, the UnitedHealth claims denials — none of these were inevitable failures. They were predictable consequences of business architecture decisions that were either deferred or never made. The teams that build agentic systems with both architectures designed in tandem, layer by layer, from the outset are the ones that will close enterprise deals, earn customer trust, and build toward the $450 billion market opportunity that agentic AI represents by 2035.

I've since expanded on several of these themes into a full series:

1. Go-to-Market Strategy: Your Architecture Might Be Ready for Agentic SaaS. Is Your Go-to-Market?

2. Pricing & Monetization - The five-tier framework, and why it can be mathematically right and still backfire.

Part 1 - How to Price an AI Agent: The Framework for What to Charge and How to Prove It

Part 2 - How to Price an AI Agent: Why it can be Mathematically Right and still Backfire

3. Stakeholder Dynamics & Governance - Who else gets touched when you deploy an agent, and where it shouldn't go at all.

Part 1 - The Connected Tissue: Who Else Gets Touched When You Deploy an Agent?

Part 2 - The Connected Tissue: Who Else Gets Touched When You Deploy an Agent?

Mapping a product against these seven layers — and understanding where architecture, pricing, and go-to-market may be pulling in different directions — is the kind of discussion my team at AWS SaaS & Agentic Apps regularly has with ISVs. If you are an AWS customer, your account team can connect you with us. If not, I am always happy to connect here on LinkedIn and explore how I can help.