AI strategy starts with the workflow and the decision.
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.
What the system observes. Quality of prediction is bounded by what goes in.
The question it answers
What does the system actually observe?
A business example
A support ticket system logs the complaint text, but not whether the same customer already called about it.
A common failure
Teams predict off the data they wish they had, not the data they actually collect.
Where this shows up on this site
Workflow Assessment Tool, starts by finding what data a workflow actually generates →Principles
- ·AI lowers the cost of prediction, but value appears only when a better prediction changes a decision.
- ·Start with the workflow and ask what would change if a useful prediction became cheap, fast, and available at the moment of action.
- ·Redesign before automating. A broken process with AI is still a broken process, only faster.
- ·Treat automation as a risk decision. Data quality, error cost, reversibility, and human oversight determine how far it should go.
- ·Build the feedback loop. Outcomes, corrections, and exceptions should improve the next decision.
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.
AI capabilities across the stack
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
Demand forecasting, fraud detection, defect inspection, churn prediction, and market prioritization.
Tools I've used: Python, 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
Policy search, complaint triage, knowledge assistance, research synthesis, and content transformation.
Tools I've used: Anthropic 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
Case-resolution support, research workflows, approvals, and operational handoffs.
Tools I've used: n8n, 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
These safeguards are less visible than the model itself, but they often determine whether a system is controlled and reliable enough to use.
Tools I've used: Zod 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.
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
- ·Does the vendor train on our data to improve their shared model?
- ·Will our feedback improve a model our competitors can later buy?
- ·Can competitors get similar capability through the same vendor?
- ·Can we export our accumulated learning history if we switch?
- ·Can we leave without losing the workflow intelligence we built?
| Criterion | When to build | When to buy |
|---|---|---|
| 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 |
The full guide
Download PDFYou can read or download the full guide below for a deeper explanation of how I connect prediction, workflow redesign, human judgment, and learning loops.
