What Agentic Actually Means Architecturally

Before getting into failure modes, it’s important to be clear on a few things because marketing folks are doing what marketing folks do and have turned the “agentic” term into something that means nothing and something that means everything simultaneously.

Thanks for reading! Subscribe for free to receive new posts and support my work.

A deterministic pipeline is a fixed code path: Input → Stage 1 → Stage 2 → Stage 3 → Output. Same input, same execution path, every time. You can unit test every stage, you can trace from input to output, you can reason about behavior. When it breaks you know exactly which stage failed because each one has a defined input and output contract. It’s boring, it not sexy, but it works.

An agentic system is a loop: Input → LLM reasons about what to do → selects and calls a tools → observes the result → LLM reasons again → selects another tool → repeat until the LLM decides it’s done. The LLM is the orchestrator AND the decision-maker AND the executor. Each invocation might take a different path through the tool graph and thus the behavior is emergent, not designed.

The issue with emergent behavior: you can’t unit test it. You can’t write an assertion that says “given this input, the agent will call tools in this order.” You can only sample it statistically and hope the distribution of outcomes is acceptable. That’s fine for a research prototype and it’s also fine for your vibe coded TODO list, or personal fitness app. It’s not fine for a system processing clinical lab data in a HIPAA-regulated environment.

So the question to be answered is this: what parts of your system need to be deterministic vs agentic? This is the single most important design decision in applied AI right now and concurrently a key skill to develop.

The Three Failure Modes (With Specifics)

In my experience so far, agentic systems break in production in three specific & diagnosable ways.

Failure Mode 1: Decision Drift

In an agentic loop, the LLM makes a series of decisions: which tool to call, what parameters to pass, how to interpret the result, whether to retry, when to terminate. Each of these is a probabilistic inference. Token generation is stochastic and temperature, sampling, even the order of tokens in the context window can shift the decision.

Run the same clinical lab data through a full agentic extraction loop ten times. You won’t get the same execution path ten times! The agent might read page 3 before page 1 on run 4, it might choose a different OCR provider on run 7, it might declare extraction “complete” earlier on run 9 because the phrasing in its chain-of-thought happened to trigger an end-of-task heuristic.

When we evaluated a full agentic architecture against the deterministic pipeline, accuracy dropped from 100% to roughly 70% with the same inputs! The final extraction results were usually consistent, but “usually” is not a word that survives a compliance audit. When you need to answer to a regulator the answer has to be yes, not “statistically, most of the time.”

Failure Mode 2: Cost Multiplication at Scale

Every iteration of an agentic loop is an LLM inference call. Each call consumes input tokens (the full context window + tool results) and generates output tokens (reasoning + tool selection). The token count grows with each iteration because the context window grows.

A deterministic pipeline processes clinical lab data in a single pass through a fixed sequence: render pages at 300 DPI, send to cloud OCR, pattern-match against LOINC codes, parse values and reference ranges, score abnormalities, compute trends. Total cost: $0.02 per document, almost entirely OCR API fees. Zero LLM calls.

The full agentic alternative we evaluated required 5-15 LLM calls per document as the agent needs to: analyze the document structure, decide on an extraction strategy, execute extraction calls, validate results, handle any edge cases it encounters, and determine when it’s done. Each call includes the growing conversation context. Per-document cost: $0.07-0.17.

At enterprise scale (tens of thousands of documents) the agentic approach multiplies costs by 3.5-8.5x with no improvement in accuracy. The POC doesn’t catch this because POCs process dozens of documents and the per-unit economics are invisible until you multiply them by real volume.

Failure Mode 3: The Debugging Black Hole

This is the failure mode that burns the most engineering hours and is the hardest to explain to folks who haven’t lived it.

The deterministic pipeline has discrete stages with observable boundaries. OCR stage: input is page images, output is text blocks with per-line confidence scores. Pattern matching stage: input is raw text, output is structured lab values matched against LOINC codes. Scoring stage: input is extracted values, output is abnormality flags and clinical priority scores. When something is wrong, you check the output at each boundary. The failure is always localizable: OCR misread the value, or the pattern didn’t match a format variation, or the reference range was wrong. You fix the stage + you add a test, and you are done.

Now imagine debugging an agentic extraction that returned wrong results: open a multi-turn conversation log and find that the agent read page 1, then decided to call the table extraction tool with specific parameters, then interpreted the results, then decided to read page 3 for additional context, then attempted to validate a creatinine value, then second-guessed itself and re-extracted. Somewhere in that chain of reasoning, it misinterpreted “creatinine kinase” as “creatinine.” Why? Because the token probabilities, given the accumulated context at that point in the conversation, made that the most likely completion. There’s no root cause in the traditional sense. There’s no bug to fix, this is by design, this is how LLMs work!! There’s a probability distribution that happened to produce the wrong output on this run.

In a regulated environment, this isn’t just an engineering inconvenience. An audit trail requires a traceable chain of custody from input to output. “The model reasoned differently on this run” is not a valid audit finding. You need deterministic traceability: this value was extracted by this pattern from this text at this position with this confidence score. Agentic loops break that chain by design.

The Root Cause: Perception vs. Judgment vs. Orchestration

All three failure modes trace back to one architectural fact: the agentic framework puts the LLM in charge of three fundamentally different jobs that have fundamentally different reliability requirements.

Perception is where unstructured input becomes structured data. I.E. reading a document, classifying a document type, extracting entities, matching patterns, etc. This is inherently fuzzy because the inputs are unstructured and variable and in this problem domain LLMs are world-class & exactly what they were designed for.

Judgment is where structured data becomes decisions: Is this value abnormal? What’s the clinical priority? Should this be flagged for urgent review? The inputs are now structured in the way of numbers, classifications, confidence scores, and the logic should be deterministic. Same inputs, same decision, every time.

Orchestration is the control flow connecting everything: Which stage runs next? What happens on failure? When do you retry vs escalate? This must be deterministic code, not LLM inference as control flow is not a perception task.

Most agentic frameworks mash all three together in a single LLM loop. The agent perceives AND judges AND orchestrates. Every “AND” in that sentence is a place where non-determinism creeps from the perception layer (where it’s acceptable) into the judgment and orchestration layers (where it’s not).

What the Best AI Engineers Have Been Doing for 3+ Years

The pattern that actually works in production is what the applied ML community has been calling “fuzzy classifiers with deterministic wrappers.” This isn’t new and as I’ve learned, good AI engineers have been building this way since before the current LLM wave but the broader market is just now catching up w/ the agentic hype cycle.

The core idea: constrain the LLM to very specific, objective classification tasks. Don’t ask “is this code good?” or “should this patient be reviewed?” These are holistic judgment calls, and the LLM will give you a different answer depending on how you frame the question. I’ve literally asked the same model to review the same authentication middleware 15 minutes apart with two different framings and gotten completely opposite conclusions. Ask it to find security issues, it returns five concerns. Ask it if the code is ready to ship it fluffs my ego about the elegant error handling. Again this is not a bug, this is how probabilistic text generation works.

Instead, constrain the classification: “Does this report contain creatinine above 1.5 mg/dL? Return yes/no + confidence 0-1.” “Does this function handle all error paths? Return yes/no + list of unhandled exceptions.” “Does this document match source pattern A or B? Return classification + confidence.” These are perception tasks and they need to be narrow & objective with structured output. LLMs are reliable at this because we’ve removed the ambiguity that makes holistic judgment unreliable.

THEN implement the value chain of what’s good/bad OUTSIDE the LLM loop, in deterministic code. This is where the skill of context engineering (an entire discipline of its own!) comes in not just crafting prompts, but designing the boundary between what the model classifies and what the code decides.

What This Looks Like in a Real System

Let me walk through the architecture of the healthcare system we shipped to show how this separation works in practice.

Perception Layer: Cloud OCR + LOINC Pattern Matching

The system processes clinical lab data from the largest lab companies in the US. The perception pipeline has three stages:

Stage 1: Digitization. PDF pages rendered at 300 DPI, sent to cloud OCR (AWS Textract, Google Document AI, or Azure Document Intelligence, with runtime provider switching). Returns text blocks with per-line confidence scores plus table structures. This is the fuzzy part as the Cloud OCR is probabilistic & confidence varies by image quality, layout, font, format, etc.

Stage 2: LOINC code matching. LOINC (Logical Observation Identifiers Names and Codes) is a universal standard for clinical observations. When the report includes codes like (4548-4), extraction is a deterministic regex lookup: find the parenthesized code, parse the adjacent numeric value, match to a canonical lab definition; no ambiguity. When LOINC codes aren’t present, the system falls back to name-based matching with a curated variation table and fuzzy substring logic and explicitly flags those results as needing verification. The system knows when its perception layer is less reliable and says so.

Stage 3: Value parsing. Extract numeric values, units, reference ranges. Handle edge cases deterministically: values with < or > prefixes (below/above detection threshold), units in various formats (mg/dL, mIU/L, nmol/L), reference ranges expressed as upper-only, lower-only, or full ranges. All of this is parsing logic, not inference.

The entire perception layer outputs structured data: lab name, numeric value, unit, reference range, confidence score, extraction method used. That structured output is the contract between the fuzzy layer and the deterministic layer.

Judgment Layer: Deterministic Clinical Decision Logic

Everything downstream of that structured output is deterministic code. No LLM calls, probability distributions or prompt sensitivity.

Abnormality detection: Compare extracted value against reference range. Creatinine 1.8 with range 0.7-1.3? Abnormal.... this is a numeric comparison & it doesn’t need a model.

Trend analysis: Track values over multiple collection dates. Compute absolute and percentage change. If the change is less than 5%, the trend is “stable.” For tests where lower is better (HbA1c, LDL, creatinine, triglycerides), a negative change means “improving.” For tests where higher is better (HDL, eGFR, hemoglobin), a positive change means “improving.” Fluctuation detection counts direction reversals across measurements and two or more reversals flags the pattern. All of this is in a deterministic function with hardcoded clinical rules. Published medical guidelines not learned weights from an LLM.

Clinical priority scoring: This is the highest-stakes decision in the system. Each test gets a score from 1 to 10: worsening + abnormal = 10 (urgent attention). Worsening only = 7 (monitor closely). Abnormal + stable = 5 (continue monitoring). Fluctuating = 4 (check medication adherence). Improving + still abnormal = 3 (continue therapy). Improving + normal = 1 (good progress).

When a clinician asks “why was this flagged?” the answer is fully traceable: “Creatinine extracted at 1.8 mg/dL via LOINC code 2160-0, reference range 0.7-1.3, flagged abnormal. Three measurements over 90 days showing 12% upward trend. Priority score 10: worsening and abnormal.” Every element is deterministic & auditable with zero model reasoning to reconstruct.

Orchestration Layer: Deterministic Control Flow

Provider selection: check if the configured cloud provider is available, if not fall back to the next configured provider. This is an if-statement, not an LLM decision. Confidence routing: if OCR confidence is below threshold, flag for human review. If LOINC code extraction succeeds, use it; if not, fall back to name-based extraction and mark as needing verification. Retry logic: if cloud OCR fails, retry with exponential backoff then fall back to local regex-only extraction.

All of this is control flow and NONE of it benefits from LLM reasoning. An agentic system would have the LLM “decide” which provider to use, “decide” whether to retry, “decide” if results are good enough. Each of those decisions introduces non-determinism into a layer where determinism is the entire point.

The Quantitative Proof

But don’t take my word for it. We didn’t just build the deterministic architecture and assume it was better, we designed and evaluated four progressively sophisticated agentic alternatives and compared them head to head.

Level 0: Deterministic fallback chain (no AI). Predefined retry strategies i.e. try AWS, then Azure, then GCP, then enhanced OCR settings, then pure regex. Fully deterministic, fully testable... this is the baseline and it works. The reason I include it is to make a point: this is what you’re comparing against when you start adding LLM decision-making into the loop. Everything after this introduces non-determinism, and the question is whether that non-determinism earns its cost.

Level 1: LLM-assisted strategy selection. Use Claude to analyze each document and recommend which OCR provider and extraction approach to use. The problem: we’re paying for an LLM inference call to make a decision that a single conditional handles reliably. The LLM added $0.003-0.01 per document in API costs, 1-3 seconds of latency, and non-deterministic strategy selection, with zero improvement in extraction quality.

Level 2: Full agentic loop. The LLM controls the entire extraction through tool use. Reading pages, choosing OCR providers, applying extraction patterns, validating results, deciding when it’s done resulting in 5-15 LLM calls per document. Processing time: 85-120 seconds vs 72.7 second baseline. Cost per document: $0.07-0.17 vs $0.02. Determinism: ~70% vs 100%. Additional code: 400+ lines of tool definitions, conversation management, and error handling for mid-conversation failures. Accuracy improvement: exactly zero.

Level 3: Hybrid. Deterministic primary + agentic fallback. Architecturally the most reasonable BUT maintaining an entire agentic subsystem for a fallback path that never triggers is pure lunacy!! 450 additional lines of code, two complete systems to maintain, full test coverage required for both paths.... for zero benefit. Nah.

Every agentic option made the system worse on every metric. Not marginal but significantly worse. The full agentic loop was up to 65% slower, up to 8.5x more expensive, and 30% less deterministic with absolutely zero accuracy improvement.

The agentic approaches didn’t fail because the models were bad rather they failed because the problem didn’t need an agent. Fixed lab sources + detectable formats + LOINC codes + known reference ranges.... that’s a stability problem and agents solve variability problems. Applying the variability solution to a stability problem adds cost and risk with no upside.

Why Teams Keep Getting This Wrong

If the failure modes are this predictable and the quantitative evidence is this clear, why do teams keep building agentic systems that break in production?

First, agentic sells better. “We built an AI agent that autonomously processes your clinical documents” gets funded. “We built a deterministic pipeline with AI-powered OCR at the perception layer” does not. The exec dashboard for an agentic system looks like the future sci-fi movie while the deterministic pipeline looks like a boring flowchart. This is a real problem because it means capital flows toward architectures that demo well and not architectures that survive production! You see this all over the place on the interwebs right now. You only have to look a far as the millions of OpenClaw posts.

Second, vibe coding has conditioned a generation of developers to throw everything at the LLM. When your primary tool is an LLM+agentic harness (claude code) the reflex is to prompt for a holistic answer rather than decompose the problem into what the model should classify and what deterministic code should decide. That decomposition requires deep domain knowledge as you have to understand your problem space well enough to enumerate specific, objective criteria. You can’t outsource that understanding to the model. This is context engineering, not prompt engineering, and it’s a fundamentally different skill.

Third, because it requires admitting that the LLM is not as smart as it seems. When you separate perception from judgment, you’re acknowledging that the model’s “understanding” is pattern matching, not comprehension. The model almost certainly knows that a creatinine of 4.0 is clinically dangerous as that’s basic medical knowledge well-represented in training data, but will it flag it the same way every time? Will the surrounding context, the phrasing of the prompt, the other values in the report shift whether it calls it ‘critical’ vs ‘elevated’ vs ‘worth monitoring’? A deterministic comparison against a reference range + other variables gets it right every time, with zero variance. And when a regulator asks how the decision was made you point to one line of logic instead of a probability distribution.

The people still trying to prompt-engineer an LLM into making holistic judgment calls like “is this code good,” “should this patient be reviewed urgently,” “is this extraction complete” are building systems that work in demos and break in production. The LLM will wax poetic about how great the code is if you ask it that way. Constrain it to “does this function handle all error paths, return yes/no + list of unhandled exceptions” and now you have something you can build actual control flow around.

When Agentic Earns Its Place

I want to be clear that there are real problems where fully agentic architectures earn their complexity. I’ll write about that in the future based on the experiences of another solution we developed.

If the system needed to support hundreds of unpredictable formats instead of a group of semi-standardized sources, the LOINC pattern matching would break. The name variation table would be unmanageable, the input variability would exceed what deterministic rules can handle and that’s when an agentic approach at the perception layer starts earning its trade-offs: the flexibility to reason about unfamiliar document structures, adapt extraction strategies to novel formats, and handle edge cases that no reasonable set of rules would cover.

If the scope expanded to radiology narratives, pathology reports, or handwritten clinical notes, the entire perception layer would need to change as deterministic pattern matching doesn’t work on unstructured narrative text. The variability is too high, the context too important, the semantic interpretation too nuanced. A model-heavy perception layer makes sense here.

But even in those scenarios, the judgment layer stays deterministic. The clinical priority scoring & abnormality detection, trend analysis and the entire orchestration stays in code. We can make the classifiers more flexible to handle higher variability at the perception layer but we haven’t given the model the car keys to the decision layer.

The framework is simple: agentic solves variability problems while deterministic solves stability problems. Most production systems I’m seeing are stability problems wearing a variability costume because someone saw a compelling agentic demo and assumed that’s the right architecture for everything.

The Practitioner’s Audit

If you’re running an agentic AI project approaching production, or troubleshooting one that’s already struggling, here’s what I’d evaluate:

1. Map every LLM call to a layer. Is the model doing perception (classifying, extracting, pattern-matching structured output)? Or is it doing judgment (deciding, routing, scoring, escalating)? If it’s doing judgment, that’s where your production failures will come from. Move those decisions into deterministic code.

2. Check your orchestration. Is the LLM deciding which tool to call next, or is control flow in code? Every LLM-controlled orchestration decision is a place where decision drift accumulates. If a conditional or a state machine can make the same routing decision, use that.

3. Test for determinism! Run the same input 10+ times. Do you get the same execution path? The same intermediate states? The same output? If not, identify which layer is introducing variance and whether that variance is in perception (acceptable) or judgment/orchestration (not acceptable).

4. Run the cost math at production volume. Multiply your per-document LLM token consumption by realistic monthly volume and compare against a deterministic alternative where the LLM is constrained to specific classification calls. If the agentic approach is 3x+ more expensive with no accuracy improvement, you have your answer.

5. Ask the debugging question. When the system produces a wrong result, can you localize the failure to a specific stage with a defined input/output contract? Or do you need to read through conversation logs? If the latter, your debugging costs in production will dominate your engineering time.

6. Classify your problem. Is the core challenge high input variability (many unknown sources, unpredictable formats, novel document types)? Or is it a bounded input space with known structure and stable rules? If the latter, the deterministic approach wins. Every. Single. Time.

The Architecture That Ships

“Agents everywhere” is 100% not the answer but neither is “no agents anywhere.” The architecture that actually ships to production and survives at scale is a hybrid: deterministic pipelines for the stable guardrails, agents (or more precisely, LLM-powered fuzzy classifiers) for the genuinely high-variation perception work, and deterministic wrappers around every model output that touches a decision.

Fuzzy classification at the perception layer + deterministic wrappers at the decision layer. Control flow in code not in the LLM loop. Confidence scores that route to human escalation when the model is uncertain coupled with an audit trail that traces from input to output without requiring anyone to reconstruct a model’s “reasoning.”

The hard part isn’t building this its it’s having the domain expertise to decompose your problem correctly, to know which parts are perception tasks where the model’s flexibility adds value, and which parts are judgment tasks where determinism is non-negotiable. That decomposition requires you to understand your domain deeply enough to enumerate specific, objective criteria. You can’t outsource that to the model and you can’t prompt-engineer your way around it. You have to actually do the hard work of defining what good looks like.

And IME, that’s exactly where many enterprise AI projects are breaking down. Not at the model layer or data layer.... but at the architecture layer. At the boundary between what should be fuzzy and what should be deterministic which is critically the decision about where the LLM loop ends and control flow begins.

Get that boundary right and everything else follows. Get it wrong and no amount of model capability fixes it.

You can’t outsource your thinking to AI.

(^^^^^^^^^^^^^^^^^I will be saying this over and over, get used to it.)

This post is all about what actually got built and more importantly the lessons learned and some key insights gained when building enterprise software with AI coding tools.

First let me start off by saying, very emphatically, based on my experience you are not “vibe coding” real enterprise software. Both from the perspective of building something that needs to run in production environments in highly regulated industries AND the deep domain knowledge required to even know what to build and how to build it. I purposely picked this industry/project as the place to start because 1- its the most relevant to my own interest (enterprise sw); and 2- I’m interested in solving the hardest problems, not the easiest ones. There is nothing more rigorous than selling and shipping into enterprise healthcare where there are lives on the line. Building something like this requires deep understanding of things like the clinician workflow, the dominant lab sources, LOINC coding, lab-specific reference ranges, multi-date panel correlation, what a HIPAA auditor actually looks at ... down to “trivial” things like TSH lab values needing two decimal places because thats clinically meaningful. My perspective around what is going to happen to the enterprise software/SaaS industry is highly informed by this project, but I’ll save that for another day.

So what actually was built? I want to be specific about this because the details are what separate this from a vibe-coded demo. In a nutshell the system automates the extraction of lab values from relevant lab sources (Quest, LabCorp, etc) in the exact manner these clinicians need saving over 10h/week/clinician.

No Vibe Coding Here. Everything on this page (the meat of the product) requires domain knowledge of what to build and how:

Diabetes vs Thyroid Presets. Reference ranges. LOINC codes. MD Summary format (preference for a particular group). This also has the ability to push right into the EHR, or the clinician can hit the “Copy” button which allows them to paste it directly in themselves as they get comfortable with the workflow. This is the human-in-the loop component and its critical to understand the best way to integrate large changes into a workflow from a human perspective. I know everyone is going crazy for fully automated magic, but knowing when to do that versus when to have a human-in-the-loop is critical. None of this came from telling Claude Code to build me this app. It came from being in the room with clinicians, understanding the nuances of their specialty, learning their workflow, and then translating that into precise requirements for Claude to build.... the fun stuff! For example, why is it important to display creatinine alongside glucose values? Because diabetes damages kidneys and creatinine measures kidney function.

Built-In HIPAA Auditing, all available real-time:

Multi-Cloud OCR with runtime switching between the relevant AWS, GCP and Azure services for lab processing. This was done on intentionally so the solution can be sold to customers regardless of which major cloud provider they have settled on, and as a secondary benefit provides a nice fall back incase one of the services has issues. Note: This particular customer is all in on AWS.

Authentication is done via AWS Cognito with RS256 JWT verification, automatic refresh on key rotation with appropriate timeouts and lockouts preconfigured. These are not nice-to-haves these are requirements in Healthcare.

The other point I want to make explicitly is Claude Code didn’t just write the application code, I also wrangled it to handle the entire lifecycle of standing up the production AWS infrastructure (this customer is all in on AWS). Claude Code generated the Terraform config for the entire stack, it wrote the Dockefile, the docker-compose orchestration, etc, etc. And the entire app can be managed by a few Claude Code skills, never having to ever touch AWS at all:

Everything is managed via Claude Code skills. These skills are infrastructure-as-conversation --> workflow-as-code. This is a different kind of DevOps: no YAML pipelines, no Jenkins, no bash scripts with cryptic flags to maintain, etc. This is using agents to do deploy. Made changes and want to test locally? Just type “/local”. Ready to deploy to prod? Just type “/deploy”. This is just one way of handling this, YMMV, but I thought it was pretty cool and efficient. There are of course pros/cons, but the main takeaway is we need to completely reimagine how software is built, deployed and managed from first principles. But just think about this: Claude Code wrote the app, stood up the production environment, configured HIPAA-compliant cloud services and automated the deployment. Just mind blowing stuff.

One other interesting thing to mention is that this was originally designed to use AWS Textract AND Amazon Comprehend Medical. After some testing, we ended up removing Comprehend Medical from the pipeline because we were able to find everything deterministically and do it faster & w/ less cost, for this particular use case. Comprehend Medical is truly an awesome service but for this use case with bounded inputs, standardized formats, etc the deterministic strategy won on every metric. There is an entire lesson here on making deterministic vs probabilistic design decisions & tradeoffs which I’ll save for another post. Its truly fascinating and I think one of the key stills that needs to be developed as we go forward. We evaluated 4 levels of agentic architecture and rejected all of them in favor of a deterministic pipeline.

Few key takeaways for me....

1- The human role didn’t shrink, it elevated. What to build. How to build it. Deep domain expertise. Understanding tradeoffs. This is a move towards architecture, domain modeling, judgement and taste.

2- Vibe coding produces nice demos. Domain expertise + AI produces real solutions.

3- The right way to think about this is that you are the brain and claude code is your hands.

4- Think very hard about where your sw is deterministic vs probabilistic (i.e. LLM usage).

5- Using Claude Code as my DevOps engineer was unexpected, and awesome.

6- You cannot outsource your thinking. You need to steer these tools. Think of it like you are molding clay.

Most “I build X with AI” posts are dashboards, chatbots, or alike. This is a HIPAA complaint app thats multi-cloud, deployed on AWS with audit logging, JWT auth, PHI redaction and EHR integration. Anyone who says you cannot use AI to build in regulated industries needs to just give it a try. It’s possible, but not by vibe coding. I’m truly blown away by what is possible with these tools. Remember this was all done in weeks not months. This is all enabled by proof over persuasion selling.

Happy building and selling!

First I want to talk about the discovery process. How do you even “sell AI” in the enterprise? An approach to take is to find a workflow to improve that has real business impact. One of the sharpest sales minds I’ve ever encountered, Michael Page, framed it the best: “Our job is not to sell. Our job is to solve problems. And if we solve a big enough customer problem, we get outsized rewards.” But this has to be humanized. How do we figure out what problem to solve? Without a doubt this requires industry domain expertise, but that is not enough. You must get deep IN that customer. Deeper than ever before. I found a very simple way to start this discovery process, in this context:

Thanks for reading! Subscribe for free to receive new posts and support my work.

1- Identify someone who is in the middle of these workflows

2- Ask them one simple question: “What do you hate most about your job?”

In healthcare the the goal is always to optimize patient care. Yes, healthcare organizations need to make money, but it should not be thought of as a pure revenue optimization exercise. But what’s interesting is that in healthcare these two things are often times tightly coupled. If you find a way to make them more capital efficient, you will also improve the patient care.

So I started this process by interviewing clinicians at the prospect. After I gathered some data points, I grouped them into cohorts and then did some light modeling on patient care / revenue impact, and then sorted these by the top 3. Now I had the top 3 things to target sorted by which would make the most impact in the organization. I did this modeling with AI tools as well. If there is interest I can discuss what I learned about how sellers should be leveraging AI for their own internal sales processes.

In this case what was identified was some extremely tedious and manual work on new patient lab data which was taking upwards of 10/hr/week per clinician. If we can improve this process, it will allow for clinicians to spend more time with patients and see more patients while also improving their job satisfaction. I want you to internalize this: see more patients (higher revenue) and also give them better care. This is the tight coupling of patient care optimization and revenue.

From there we went right to a prototype. No slide ware, no drawn out proposals, no weeks of planning, no canned demos/accelerators, no hand-wavy POC (which is different than a prototype). Just a 48-96 hour build cycle with reusable scaffolds and tight guardrails, running the same week. This was the iPhone moment for me. I could not believe how quickly we could get to the working proof.

Hence the title of this post: the shift in AI from a sales perspective is moving from persuasion (slide ware, meetings, calls, meetings) to proof (working prototype running quickly). Because building anything was expensive (both capital and human) the sales process optimized around persuasion (slides) before proof (software). In this new world, the sales process needs to optimize for proof-first selling. You need to quickly deliver a working slice of the customer solution, and it needs to be built fast enough that it becomes the next sales meeting. Figma wire-frame is a conversation starter but a working prototype is a decision accelerator. It changes the customer conversation from “do we like the idea?” to “how do we make this real in production?”

From there it was a question of sitting down with the buyer stakeholders and rapidly iterating on the workflow specifics and clinical preferences and other technical details to get it production ready. I cannot share much here because this part is proprietary and confidential to this particular customer. The business metrics here made it a straight forward “sell” after the prototype: the solution will pay for itself in 6months, with a 20%+ revenue impact for this group.

This is prototype-to-production selling, enabled by AI tooling.

I want to keep this post mostly focused on the sales process so I’ll follow up on the solution details in the a follow up post, but here is a quick teaser: 100% built with Claude Code. Multi-Cloud support (AWS, GCP, Azure) with runtime provider switching. HIPAA-compliant audit logging with 7-year retention. Containerized and running in production on AWS. Integrated with the customer’s EHR (eCW in this case). It’s as real as it gets in enterprise healthcare. Built in weeks not months/years.

Key takeaways for me:

1- Sales economics will completely shift. Credibility used to come from brand + slides + references. Now credibility comes from speed-to-proof and iteration velocity + quality.

2- The buyer psychology shifts from slides which invite debate, to working software which invite decisions.

3- When the buyer can “touch/taste/feel the solution“ (hat tip to an ex-team member Brian Farrell for this great tagline & concept which he introduced to me years ago) the conversation quickly jumps from “Do we believe you?” to “What would it take to run this in production?“

4- As I stated in my previous post, AI is a compression algorithm. In this case, it compresses the sales cycle.

5- The key artifacts are not slides, they are a working slice of the customer solution built in days not months.

6- Most clinicians have an anti-AI perspective. You need to be prepared for this. The right framing is “what if you could just do the parts of the job you love.” Again, not metrics, but humanizing.

7- Even with the sales cycle acceleration, it doesn’t take away ANY of the sales twists and turns that occur when moving a deal through the sales stages. You still need a sales professional leading the effort, but their focus shifts considerably. You still still have to deal with politics. You will still get last minute surprises. None of that is changing anytime soon IMO. If there is interest, I can dive more into this as well.

This type of selling will require the entire org (marketing, sales, engineering) to completely re-think their approach. You cannot just “use an AI tool” to sell into 2026+. That is not enough. And you cannot just make this change in the sales org. This is the compression of marketing, sales, pre-sales, delivery, etc that I spoke of in my last post and they all have to think differently and move together in a way that is more tightly coupled than ever before.

If you are selling in this way, I would love to hear from you to compare notes & share. We are very early in all of this and I don’t have all the right answers. What I do know is that change is in the air and its super exciting to be thinking through these changes. An ex-colleague Robert Swinkin captured my feelings on this the best in a post he made on his new exciting journey: “As my remit has continued to grow into the billions, I found my mind drifting back to those breathless early years — at the coal face, where everything was a first, every trail blazed was virgin, and the business moved faster than any rule or process could contain it.“

Happy Selling!

1- I need hard things that demand more from me than I think I have. That pressure has always (100% of the time) brought out the bigger version of me to show up. If the goal is small, my effort stays small. I do my best work when the challenge is big enough to push me outside of my comfort zone. Without these things, I never reach the next gear.

Thanks for reading! Subscribe for free to receive new posts and support my work.

2- I’m at my best when I’m building into the future, not replaying a version of the past in an incremental fashion.

3- And I need to do these things with other folks who are also high-agency misfits.

I will always be extremely grateful to Darren Mowry and Paul Soligon for taking a chance on me way back in 2014 and Ed Porter (#3 above!) for mentoring me in the “ways of Ed” (if you have worked with Ed, you know what I mean!) Joining AWS as a seller in 2014 was the best example of #1/#2/#3 . At that time: 1) there was no playbook to “selling” cloud; 2) what customers were doing with AWS was not just a reframe of on-prem, it was fundamentally different and 3) it was my first foray into going from a Sales Engineering org to leading accounts as the AE. It was one of the hardest things I have done, and also one of the most satisfying. The YoY quota growth expectations were hard; getting promoted was hard; thinking through the lens of the customer from an industry lens was hard. The reality is I have had my “head in the cloud” for over a decade now. Cloud is no longer about building into the future, its just status quo.

“Building into the future” in 2026 means AI. I don’t think this is a very controversial take. But what does that mean exactly? My take: AI is a compression algorithm. It compresses the time between idea, solution, sale and impact. It compresses the boundaries between sales, pre-sales, delivery, product and marketing. I’ve been fortunate to have been trusted in roles that span most of those disciplines, and this incoming compression of traditional boundaries is extremely obvious to me. Note: Compression does not mean “disappear entirely”! It means a much tighter, faster and integrated operating model.

When I started using Claude Code, Codex and other tools in November it was akin to the first time I used an iPhone or hailed an Uber. It just felt like magic. I can’t describe it any other way. Many can relate to the ‘iPhone moment’ or ‘Uber moment’. This timing also coincided with the release of Opus 4.5 which was completely game changing from an LLM perspective. Just lucky timing on my part.

After a short break during Thanksgiving, I set out to answer the following question: “With AI tools, can a single person or a much smaller team do it all? Understand the customer problem, go deep into the industry specific workflow, prototype the solution, shape the narrative, test the market, and deliver something real into production?”

I’ve now experienced this first hand. The first product or solution I worked on is in the Healthcare space. What is extremely distracting right now in the AI space is that there are a lot of cool looking demos, “POCs” and things which I would consider “cool toys”, but have zero relevance in actual companies and have NO chance of scaling or making KPI impacts. Sticking with the theme of “doing hard things” I wanted to apply AI into one of the most highly regulated and critical industries in existence: Healthcare. Then I went to another highly regulated industry: Finance.

Both of these solutions are IN PRODUCTION, making real revenue impact TODAY. I am extremely grateful to my network who placed trust in me to get involved in these projects when all I had to trade on was my past performance and then me saying “trust me I’ll lead this and figure this out.” Thank you!

In future posts, I will be detailing and giving practical information on these two solutions, how they were built, and what business impact they are making. I firmly believe that knowledge should be free and customers should pay for outcomes, so I will be sharing as much as possible without violating any NDAs or competitive moats. I previously maintained a technology/business focused blog and presence on twitter (@vjswami) that I let lapse for various reasons. But I’m so energized about this new wave of technology disruption that I’m going to get back to writing and sharing again.

AI is changing the nature of work itself. And I’m here for it. If you have a blended background in engineering/technology & sales you have the highest leverage that you have EVER had. You need to be experimenting with AI tools NOW. Go build something real and try to sell it.... and see what happens. Cloud drastically reduced the cost of experimentation from an infrastructure perspective, and AI is doing the same for apps.

In addition to sharing the technology journey, I hope to also inspire people to find their purpose. I’ll also be talking about new roles that are emerging based on what I’m seeing. Feel free to reach out to me to discuss any of the above.

Let’s go build the future!

Subscribe now