Writing · Framework
AI strategy starts with the decision, not the model
The model comes later. This framework examines the business outcome, the prediction required, the judgment around it, the resulting action, and the feedback that improves the system over time.
Distilled from my 46-slide guide, How to Become AI-Native, which builds on Prediction Machines by Agrawal, Gans, and Goldfarb. The full guide is at the end of this page.
01
The anatomy of a decision
Every AI opportunity can be traced through six steps. Most failed projects skip one of them, usually judgment or feedback.
- Input data
- Prediction
- Judgment
- Action
- Outcome
- Feedback
What the system observes. Quality of prediction is bounded by what goes in.
The question it answers
What does the system actually observe?
A common failure
Teams predict off the data they wish they had, not the data they actually collect.
A business example
A support ticket system logs the complaint text, but not whether the same customer already called about it.
Where this shows up on this site
Workflow Assessment Tool, starts by finding what data a workflow actually generates →
02
Principles
- 01AI lowers the cost of prediction, but value appears only when a better prediction changes a decision.
- 02Start with the workflow and ask what would change if a useful prediction became cheap, fast, and available at the moment of action.
- 03Redesign before automating. A broken process with AI is still a broken process, only faster.
- 04Treat automation as a risk decision. Data quality, error cost, reversibility, and human oversight determine how far it should go.
- 05Build the feedback loop. Outcomes, corrections, and exceptions should improve the next decision.
03
Why most AI spending stalls
Adoption is running ahead of value. The studies set different bars for success, and the same gap shows up in all of them.
- 39%
- of companies report any enterprise EBIT impact from AI
- McKinsey, 2025
- ~80%
- estimated AI project failure rate
- RAND, 2024, external estimate cited by RAND
- 42%
- have abandoned most of their AI initiatives
- S&P Global, 2025
- 46%
- of AI proofs of concept get scrapped before broad adoption
- S&P Global, 2025
The failure point is usually diagnosis, not tooling. 85% of executives told HBR their organizations are bad at diagnosing problems, and a pilot with no clearly named problem has no target to hit. The market rewards visible building and undervalues knowing what not to build. That gap is what this framework is built to close.
04
Matching the capability to the problem
The problem determines which capability I use. A transparent weighted formula may be the better choice when the decision logic needs to remain visible, while a transformer becomes useful when the input is messy or unstructured. I use agents when a workflow requires several connected steps and a defined point for human review.
Predictive and narrow AI
Classification · Forecasting · Ranking · Anomaly detection · Recommendation · Computer vision · Optimization
Demand forecasting, fraud detection, defect inspection, churn prediction, and market prioritization.
ToolsPython, pandas, NumPy, scikit-learn, PyTorch, Jupyter, Azure ML.
The ranking logic in Market Expansion Prioritizer and the word-vector clustering in Data as Fuel for AI both live in this category.
Transformers and generative AI
Extraction · Summarization · Semantic search · Translation · Drafting · Document comparison · Multimodal analysis
Policy search, complaint triage, knowledge assistance, research synthesis, and content transformation.
ToolsAnthropic API, OpenAI API, ChatGPT, local language models.
Workflow Assessment Tool and Customer Escalation Triage are the two projects where a language model performs the core analysis, and both use Claude Opus 4.8 with structured outputs.
Agents and workflow orchestration
Tool use · Multi-step workflows · Retrieval · Memory · Human approval · Exception routing · Monitoring
Case-resolution support, research workflows, approvals, and operational handoffs.
Toolsn8n, Claude Code, Cursor, Codex, APIs, and serverless functions.
I built this site with Claude Code through a multi-step development process that worked directly against the running application rather than generating the entire site from one prompt.
Evaluation and responsible implementation
Structured outputs · Rate limiting · Input validation · Human-in-the-loop design · Cost controls · Privacy boundaries · Failure handling · Output evaluation
These safeguards are less visible than the model itself, but they often determine whether a system is controlled and reliable enough to use.
ToolsZod schema validation, per-IP rate limiting, server-side credential handling.
Every safeguard listed in the "Designed for controlled use" panel on Workflow Assessment Tool and Customer Escalation Triage comes from this category, not from the model itself.
05
Build it or buy it
Build-versus-buy decisions are not only about cost, because they also determine who owns the learning loop. A company can give that away by default when it buys a system without considering how its feedback and workflow knowledge will be used.
When to build
- The workflow is your competitive edge, not a commodity
- Data is proprietary and not available to competitors
- Feedback from use would improve the system over time
- The model would directly shape the customer experience
When to buy
- The task is generic, not something that differentiates you
- Speed to deployment matters more than customization
- A vendor is demonstrably better at this than you could build
- Vendor dependency risk is manageable
What I'd ask a vendor before signing
- 1.Does the vendor train on our data to improve their shared model?
- 2.Will our feedback improve a model our competitors can later buy?
- 3.Can competitors get similar capability through the same vendor?
- 4.Can we export our accumulated learning history if we switch?
- 5.Can we leave without losing the workflow intelligence we built?
| Criterion | Points to building | Points to buying |
|---|---|---|
| Strategic differentiation | This capability is core to how you win, not a commodity | The task is well-solved and doesn't distinguish you from competitors |
| Data ownership | The data is proprietary and creates value nobody else has | The data adds little beyond what's already public or common |
| Feedback-loop ownership | Corrections and outcomes should train something you control | A vendor's shared model won't be tuned to you specifically anyway |
| Speed to deployment | You can afford the build time for the long-term control it buys | You need this working in weeks, not quarters |
| Customization | The workflow has requirements a generic tool won't fit | A standard configuration already covers the real need |
| Vendor dependency | You can't tolerate being locked into one vendor's roadmap | Switching cost is low enough that lock-in isn't a real risk |
| Exit and portability risk | You need to be able to walk away with what you've learned | The vendor relationship is easy enough to unwind if it doesn't work out |
06
The full guide
Read or download the full guide for a deeper explanation of how I connect prediction, workflow redesign, human judgment, and learning loops. Download the PDF
