AIAnalyticsWorkflow DesignCommercial Strategy

I tried automating and integrating AI
into almost all workstreams relevant to me.
Here’s what I found.

Six findings on where AI actually changes the work, and where human judgment becomes more valuable, not less.

Sameer · samspoke.com·June 2026·~18 min read

There is a particular anxiety running through analytics and commercial teams right now. We are operating inside a function that looks like it could be deeply transformed by AI, while still struggling to fully grasp how AI-integrated workflows will impact commercial analytics, especially as we continue to navigate regulatory and compliance constraints.

So I stopped waiting and ran an experiment using synthetic data that mimics real-world patterns. I built agentic workflows on top of it, stress-tested them against experienced analysts and junior staff, observed where AI broke down and where humans overestimated their own edge, and drew conclusions to help reduce the uncertainty around how the future of work in commercial analytics is likely to evolve.

Key finding

AI can answer the question. The problem is that without the right context, it answers the wrong question, because nobody taught it how your business actually defines its own data.

The argument

The integration most commercial teams have built is a dashboard with pre built views. The dashboard answers the questions you thought of when you built it. It cannot handle the question you ask at 11 PM when the client pushes back on a number.

What changes that is a connector agent with a business language translation layer underneath it: a maintained document that maps natural language business questions to precise query logic. Not just column definitions. The domain specific shorthand: how a market segment is defined in the source data versus how the commercial team refers to it in conversation. What a lapsed customer means in your CRM versus what marketing means when they say it.

When the agent carries that context, it stops producing outputs that are technically correct and commercially misleading. When it does not carry that context, it produces exactly those outputs, confidently and with no flag.

The structural shift is bigger than the time savings. When natural language access is available to any stakeholder, the analytical function is no longer the bottleneck. It becomes the function responsible for framing better questions, a different job with a different skill profile, and most teams are not deliberately building toward it.

In practice

Ask an AI "how are we doing in cardiology this quarter?" without context, and it may pull calendar Q3, filter on all cardiology specialty codes, and report total prescriptions. Your team means fiscal Q2, target prescribers only, the 140 accounts your reps actually call on, and net new patient starts. The output is technically correct for what was asked. Commercially, it answers a completely different question. That gap lives in the translation layer, not the AI model.

The analytical function is no longer the bottleneck between a business question and a number. It becomes the function responsible for asking better questions.

How it works

Before: analyst as bottleneck

BusinessQuestionAnalystbottleneckSQL / QueryData SourceOutput

After: business language mapped into data language

Brand TeamAnalystExecutiveBusiness LanguageTranslation Layermaps terms to data definitionsConnectorAgentDataSource

Analyst time allocation: before and after

Query construction55% → 12%
Hypothesis testing22% → 60%
Interpretation and comms23% → 28%

Indicative reallocation based on analyst interviews post deployment.

Technical detail

The translation layer is not a one time artifact; it requires ongoing curation as business definitions evolve. Natural language ambiguity (e.g. "recent" without a date anchor, "our market" without a geography definition) must be resolved here, not at query time. Treat it as a versioned document with domain SME ownership, reviewed quarterly. Degraded or stale entries are almost always the root cause when an agent produces outputs that are technically correct but commercially wrong.

Key finding

Getting an AI output is not the hard part. Knowing which of the ten embedded judgment calls in that output were made correctly, and being in the loop at each one rather than just reviewing the final result. That is the hard part.

The argument

The common mistake is treating multistep commercial workstreams as prompt engineering problems. They are process formalization problems that happen to be executed through an AI interface. Demand forecasting, territory sizing, pricing scenario modeling: these workstreams have a dozen judgment calls embedded in them, each calibrated over years of domain experience.

The architecture that works has three layers. A template: the fixed skeleton, covering calculation logic, data requirements, output format. A decision node map: every judgment call written down explicitly, each with a framework for making it and the standard it is held against. And mandatory human checkpoints at each node, not a single sign off at the end.

A 2023 JMIS study found that reviewing complete AI outputs end to end was associated with higher dissatisfaction than either manual work or structured incremental collaboration. Correcting a finished analysis built on a wrong assumption is expensive and demoralizing. Approving or adjusting at a checkpoint takes thirty seconds.

The second order benefit: decision frameworks are not workflow specific. The logic for handling thin comparator market data appears in forecasting, territory sizing, and pricing scenario work. Once formalized, each framework composes into any subsequent workflow that hits the same decision type. Each new project gets cheaper and more consistent than the last.

In practice

In a demand forecast for an oncology launch, the AI may propose using breast cancer patient volume as a comparator market. A senior analyst recognizes in 30 seconds that this does not work; the treatment pathway and payer dynamics are structurally different. That correction at a checkpoint is fast and clean. Auditing a complete 40 slide forecast built on that comparator takes three hours and demoralizes the team. The checkpoint is not overhead. It is the cost control.

The real long term asset is not a library of workflows. It is a library of decision frameworks that assemble into workflows.

How it works

The map: what runs on its own, and where someone decides

How to read this

A repeatable workflow is not a straight line. It is a set of connected blocks, dozens of small variables, and a handful of real decisions. The craft is knowing which decisions change the path — and which just tune the numbers.

One workflow, seen as a mapBlocks do the work. Dots are the variables. Circles are where someone decides.variablespathscopenumbersjudgmentThe questionwhat we need to decideThe datawhat we can measureLocal contextwhat's true in this marketThe methodhow we calculateThe numbersthresholds & rangesThe answerwith the reasoningattachedA different pathsome choices restart the mapevery grey dot is a variable someone once had to think aboutWhich path?can change everything afterWhat matters here?pick the local factorsHow much?set the numbersToo close to calla person decidesPEOPLE CHECK HEREclear data → a quick sign-offunclear → the lane widens, a person decides

The four kinds of decisions

in plain terms

Which path?

Direction decisions. Choose differently here and everything after it changes.

What matters here?

Scope decisions. Pick which local factors — segments, channels, constraints — belong in the work.

How much?

Tuning decisions. Set the thresholds, ranges, and cutoffs. The structure stays the same.

Too close to call

Judgment calls. The data doesn't decide; an experienced person does.

Every decision answers five questions

1What are we deciding?
2What do we already know?
3What would an expert do?
4What does a good answer look like?
5Who signs off before it moves on?

When it's unclear

When the data is clear, sign-off takes seconds. When it isn't, slow down: show the trade-off, hand it to a person, and write down why they chose what they chose.

The three layer implementation architecture

Layer 1Template

The fixed skeleton: calculation logic, data requirements, output format. This is the part that does not change across markets or business cycles.

Layer 2Decision Node MapOFTEN MISSING

Every judgment call written down explicitly, with the framework for making it AND the standard it is held against. The second element is almost always missing in practice.

Layer 3Human Checkpoints

Mandatory approval at each decision node, not a single sign off at the end. Reviewing at a checkpoint is fast. Auditing a finished output built on a wrong assumption is not.

A checkpoint in action: what the human actually approves

Assuming 8% volume decline in the base case, drawn from comparator markets A and B (avg: 7.4%, σ = 1.8%).
Note: output is sensitive to this assumption. A 4 point shift changes projected revenue by ~$2.3M.
Approve and continue
Adjust to 5% and flag why

Why decision frameworks compound: an indexed library

📌 Handling thin comparator market data
📌 Weighting lagging vs. leading indicators
📌 Calibrating base case volume decline
📌 Attribution in omnichannel markets
📌 Territory sizing with sparse data
📌 Adjusting for new entrant seasonality

Once a decision framework is written down and indexed, it gets reused in every future workstream that hits the same decision type. Each new project gets cheaper and more consistent than the last.

Technical detail

One variable that matters more than most implementations account for: which AI model handles decision nodes. Testing the same multistep workflow across frontier models shows the difference is not primarily in factual accuracy; it is in behavior at ambiguous decision points. Some models propose a reasonable default and proceed. Others surface the range of plausible assumptions, flag how sensitive the output is to that assumption, and ask which direction to lean. The second behavior is worth substantially more in a professional context. Evaluate models on this, not benchmark scores.

Key finding

When a senior analyst says something feels off about a number, that reaction is worth investigating. It is pattern recognition built over a decade, not vague discomfort. Build workflows that capture it.

The argument

The instinct in most AI augmented workflows is to treat human intuition as a corrective mechanism, the one you invoke when data runs out. This is too narrow.

In 1966, Michael Polanyi articulated something organizational theory has spent decades formalizing: "we can know more than we can tell." Human expertise is built around a layer of tacit knowledge, pattern recognition developed through sustained exposure to outcomes, a form of knowledge that resists full articulation. It operates below the level of explicit reasoning.

Gary Klein's research on naturalistic decision making found that experienced practitioners rarely compare options. They recognize a situation as similar to past situations, generate a course of action, mentally simulate its outcome, and act. For practitioners in domains with consistent underlying patterns, this process is faster and often more accurate than deliberate analysis, because it draws on a pattern library no explicit model has yet captured.

The Kahneman and Klein paper (American Psychologist, 2009) drew the boundary condition clearly: expert intuition is reliable when the environment has valid regularities and the practitioner has had sustained exposure to outcomes. Commercial analytics meets that condition.

Designing workflows to elicit that signal, building in moments where practitioners articulate what they are noticing, not just approve or reject, is the quality mechanism most likely to surface tacit knowledge in a form that eventually improves the model itself.

In practice

A model returns a 38% patient switch rate from Brand A to Brand B within 90 days of initiation. The AI does not flag this as unusual. An analyst who has built claims based cohort models before recognizes it immediately; switch rates of 35 to 40% in the first 90 days almost always trace to bridge programs or starter packs being miscoded as completed treatments in the claims feed. Without that recognition, a structurally wrong number goes into the forecast. The AI was right about what it computed. It had no way to know the data was wrong.

“We can know more than we can tell.” — Michael Polanyi, 1966

How it works

Recognition Primed Decision

👁️
Situation
familiar pattern detected
🧠
Recognize
match against experience library
Simulate
mental outcome simulation
Act
fast, calibrated, confident
Klein (1993)

Deliberate Analysis

Situation
novel or ambiguous
⚖️
Compare options
exhaustive list
📊
Analyze
models, confidence intervals
🔄
Decide
slow, cognitively costly
Novel domains

When is expert intuition reliable? (Kahneman and Klein, 2009)

✓ Reliable

The domain has consistent underlying patterns. The practitioner has seen enough outcomes to have a calibrated experience library. Commercial analytics qualifies.

Still humans are more reliable

In novel markets or first-exposure outcomes, human judgment becomes more important. Humans adapt faster, develop expertise from new feedback loops more quickly than AI, and can reason through context the model has not seen.

Workflow design implication: Build in moments where experienced practitioners articulate what they are noticing, not just approve or reject. This is the mechanism that turns tacit knowledge into something the model can eventually learn from.

Technical detail

Structured elicitation is not a checkbox. It requires asking experienced practitioners not just "approve or reject?" but "what are you noticing?" and then capturing the response in a form that can be compared against model outputs over time. This is how tacit knowledge transitions from an inaccessible heuristic to a documented decision framework node, eventually feeding back into the indexed library described in Section 02. The pipeline: elicit → articulate → formalize → index → deploy.

Key finding

Give junior analysts AI before they have learned to spot a bad output, and you get confident, wrong answers produced at scale. The tool is not the problem. The order of introduction is.

The argument

The problem is not that AI is present. The problem is that AI removes the friction that creates learning.

Judgment in analytics does not develop through training. It develops through repeated exposure to wrong answers and the process of diagnosing why they were wrong. A junior analyst who gets an implausible output has to reason about what went wrong: check the population logic, interrogate the assumptions, trace the error back to its origin. That reasoning process is the skill. If the agent catches the error first, or the analyst accepts the output without interrogating it, the reasoning never happens.

This is identical in structure to how numerical intuition develops, or fails to. Children who develop arithmetic sense before using calculators use calculators as accelerants. Children who reach for a calculator before they have number sense cannot catch the calculator's errors. The sequence determines the capability.

In practice: AI access to well specified query and retrieval tasks before it is extended to judgment dependent workflows. Deliberate exposure to cases where AI is wrong and the analyst must diagnose why. Review of AI outputs treated as a reasoning exercise, not a formatting task. This is not a training philosophy; it is a risk management requirement for any organization expecting to maintain output quality as the ratio of AI to human work shifts upward.

In practice

A junior analyst runs a market share model. Output shows share rising from 18% to 31% in two months. They present it. A senior analyst catches it: the denominator changed mid period when a new data source was onboarded. The model computed correctly for what the code did. The business question was answered incorrectly. That distinction only matters if you have been specifically trained to look for it. A junior analyst with six months of AI first workflow experience has not been.

The sequence is the intervention.

How it works

Wrong sequence

AI access from day one
Output produced quickly
Output accepted uncritically
Reasoning never develops

Right sequence

Well scoped query tasks, manual first
Wrong answer → diagnose why
Analytical judgment develops
AI access: now an accelerant, not a crutch

The calculator analogy

Number sense first → calculator
Uses calculator as accelerant. Can catch errors. Reliable at scale.
Calculator first → no number sense
Cannot catch calculator errors. Accepts implausible outputs. Quality degrades at the worst moments.

Technical detail

Operationally, this requires a tiered access model. AI tools are available for well specified retrieval tasks from onboarding, but access to judgment dependent modules like forecasting templates, pricing scenario tools, and territory sizing workflows is gated behind demonstrated proficiency. The benchmark should include deliberate exposure to known wrong AI outputs where the analyst must identify the error and trace it to origin. Certification should be evidence based, not time based.

Key finding

The firms chasing efficiency through AI are running the same race slightly faster. The firms asking which previously impossible problems are now viable are running a different race entirely.

The argument

The efficiency framing rests on two assumptions that frequently fail. First, that AI costs are negligible. Second, that being faster than competitors creates durable separation. Both assumptions deserve scrutiny before being embedded in a strategy.

On costs: running AI at scale across real workstreams, with the data infrastructure, model management, and quality control it requires, is more expensive than the productivity narrative suggests. Companies that have deployed widely have found that compute and infrastructure costs can erode the efficiency gains substantially, sometimes entirely, especially in the first two years before workflows are well optimized. The bet that AI makes you cheaper is more fragile than it looks.

On competitive advantage: even where efficiency gains do materialize and hold, they commoditize. If every firm on the same technology stack captures the same productivity improvement, the competitive landscape shifts but no individual firm gains separation. You are all faster. You are still running the same race.

The asymmetric opportunity is elsewhere. Every previous analytical technology wave, spreadsheets, database software, BI platforms, expanded the frontier of what was commercially viable to attempt, not just what was cheaper to execute. The firms that captured value in each wave were not the most efficient producers of the old work. They were the ones that identified the new problem categories the technology unlocked.

AI does the same thing. There is a backlog of commercially valuable problems that were never started because the human time required exceeded the value they would generate. Those problems went into a drawer. Some of them are now worth pulling out.

In practice

Rep level call activity analysis linked to prescribing outcomes at the individual prescriber level is a common example. Every brand team knows this would be strategically valuable. Most have never prioritized it because the analyst hours required were hard to justify against other work. If AI augmented delivery makes the analysis meaningfully cheaper to run, the problem does not become marginally more affordable; it potentially crosses the threshold from deprioritized to standard. That is a different kind of value than shaving time off a report that was already being produced.

Go back to the drawer. Find the problems that were commercially dead. Recalculate. Some of them are now alive. That is a different question than asking how much faster you can run the ones you were already doing.

How it works

Each technology wave expanded which problems were economically viable

1990s: Spreadsheets
2000s: Database software
2010s: BI platforms and statistics
2020s: AI augmented delivery

Problems back out of the drawer: recalculate the economics

Illustrative estimates
Rep level call activity linked to prescriber Rx outcomes
Weeks → daysest.
Omnichannel attribution with sparse conversion data
Days → hoursest.
Territory analysis in below threshold markets
Unviable → viable
Weekly monitoring workstreams (not just quarterly)
N/A → standard
Live scenario modeling during client facing calls
Post meeting → live

The directional logic is real; the time estimates are order-of-magnitude guesses, not benchmarks. The structural shifts (unviable to viable, post-meeting to live) are the more honest claims. Suggested method: take the last 3 years of declined projects, rerun the economics at lower delivery costs, and see what changes.

Technical detail

A practical drawer excavation: take the last three years of declined or deprioritized analytical projects. For each one, note why it was killed, whether the reason was analyst hours, time to delivery, or perceived return on effort. Then ask whether the cost structure has shifted enough to revisit it, not by assuming a specific efficiency multiplier, but by getting a real estimate from someone who has run a comparable workstream under an AI augmented model. The exercise tends to surface two or three live candidates that have been sitting unchased for years. The point is not the efficiency number. It is that the problem is now worth asking again.

Key finding

The work being automated is the work of producing the answer. What is left is harder: deciding what question to ask, structuring the logic, and knowing when the output is wrong.

The argument

The question used to be: can you produce an accurate output efficiently?

The question now is: can you design the decision frameworks the AI runs through, surface what experienced people know but cannot easily articulate, develop the judgment of people below you, and find the problems the business did not know it could afford to solve?

The first question was always going to be automated. The second one is not.

The analysts who will fare well are not those who resist AI; they are those who use the efficiency gains to build capabilities AI cannot replicate: judgment, architecture, knowledge elicitation, problem discovery. The window to build those capabilities while they are still in demand is not infinite.

Organizations that restructure roles without creating conditions for that practice, giving analysts AI tools but keeping them in execution heavy workflows, will not build the capability they need. The diagnostic question is what percentage of analyst time goes toward designing the frameworks and logic the AI uses, versus running outputs the AI could run autonomously. If the answer is less than 30%, the transition is not happening.

In practice

The analyst who spent 60% of their week building the forecast now spends 60% of their week on what the forecast reveals, deciding whether the biosimilar uptake assumption holds in a specific geography, building the decision rule for how to handle it next cycle, and walking through the logic with someone junior enough that they will need to make the same call independently in six months. The output volume is the same. The nature of the work is different.

The first question was always going to be automated. The second one is not.

How it works

The old question

"Can you produce an accurate output efficiently?"

↳ This question was always going to be automated.

The new question

"Can you build decision frameworks, surface what experienced people know implicitly, develop judgment in the people below you, and find problems the business did not know it could afford to solve?"

↳ This question is not automated.

Where skills are moving

SQL query construction↓ Automated
Dashboard formatting and packaging↓ Automated
Report generation↓ Automated
Decision framework design↑ Premium
Eliciting what experts know implicitly↑ Premium
Developing judgment in junior staff↑ Premium
Problem discovery (the drawer)↑ Premium

Technical detail

The skill transition has a compounding problem: the new premium skills, including decision architecture, tacit knowledge elicitation, and problem discovery, are not built through coursework. They are built through practice on real, consequential problems with feedback loops attached. A useful diagnostic: how much of the analyst team's time is spent designing the frameworks the AI uses, versus running tasks the AI could run autonomously? The ratio tells you whether the capability is being built or merely promised.

Conclusion

The analyst role is not ending.
It is being restructured
around a harder question.

These findings come from running the experiment and not theorizing about it, from building the workflows, watching where they failed, and drawing conclusions from what actually happened.

About this experiment

The workstreams described here are drawn from commercial analytics in healthcare, a domain where the gap between a technically correct output and a commercially useful one is wide, assumptions are consequential, and market contexts are specialized enough to stress test these principles properly. That specificity is what made the experiment useful. The patterns generalize. The examples came from there.

More writing ↗All projects ↗