If I Had These Capabilities Then: The Most Reusable Thing Might Have Been the Questions
Looking back across renewable energy, payments, travel and live events, I can see patterns. I can also see why patterns are dangerous. A pattern encourages you to believe that because two problems look alike, the same answer will work twice.
Cross-Portfolio Learning Layer Architecture
Four domain examples feeding a shared learning layer—questions, evaluation patterns, guardrails, and evidence, not copied solutions:
Sometimes a pattern works. Enough times that reuse matters. Not enough times that I would trust it blindly.
- Renewable Energy
- International VAT
- Travel Disruption
- Live Arena Operations
That tension feels especially relevant when thinking about probabilistic and generative capabilities across multiple businesses.
The Graham role that prompted this thinking is interesting precisely because the portfolio spans organizations with very different industries, maturity levels and operating environments. The role calls for identifying reusable approaches while still assessing readiness and constraints inside each individual business.
That made me think differently about what I would have wanted to carry between my own past projects.
Maybe it would not have been the solution.
Maybe it would have been the questions.
Renewable Energy and International Payments Could Both Use Contextual Support
At a high level, both environments involved people trying to make decisions from information they did not necessarily understand completely.
That sounds reusable: "Build a contextual assistant."
Except the contexts are completely different:
- In renewable energy, the value might come from helping a customer understand a difficult concept.
- In VAT refunds, the same kind of generative capability might help an employee interpret country-specific guidance.
One is primarily an experience problem. The other can become a compliance problem.
The underlying technique may be similar. The product boundaries should not be.
Travel and Live Events Both Operate Under Time Pressure
Again, there is a pattern: Information arrives. Conditions change. People need to act. A predictive or synthesis capability could potentially help people regain situational awareness.
But the consequences are completely different:
- A recommendation during travel disruption may change a customer's journey.
- A recommendation during a live event may affect an order or operational incident.
Even when the implementation technology travels, the evaluation criteria have to be rebuilt around the actual environment.
That is why I would be cautious about creating a universal scorecard that pretends context can be normalized away. I would rather create a reusable conversation.
Tracing Why Copied Solutions Fail Where Reusable Questions Succeed
Explore how the four domains share high-level similarities on paper, but require diametrically opposed boundaries when tested against real operational consequences.
Select a Domain Pair to Contrast
Choose two portfolio contexts that superficially look like candidates for identical solutions:
The 9 Questions That Can Travel
Rather than normalizing context into an abstract scorecard, I would carry a disciplined set of inquiries into every business unit working with probabilistic systems:
What problem are we solving? What does good look like here?
Core Inquiry: Strip away vendor rhetoric. Are we shortening time-to-orient, reducing rework, or eliminating cognitive panic during operational spikes? What exact business metric shifts if this works?
The Anti-Pattern: "Deploying generative AI to modernize the intake queue" without defining what failure or success looks like to frontline operators.
What information does the system actually have? What remains invisible?
Core Inquiry: What data is trapped in disconnected silos, physical room acoustics, customer body language, or unwritten union agreements that telemetry cannot perceive?
The Anti-Pattern: Assuming that connecting more APIs gives an LLM situational awareness of a crowded stadium concourse or a cancelled wedding.
Where is probabilistic behavior useful? Where do we need deterministic control?
Core Inquiry: Where is approximation an asset (synthesizing unstructured receipts, natural language queries) and where is it a liability (statutory VAT thresholds, FAA rest minimums, accounting ledger posts)?
The Anti-Pattern: Allowing an LLM to calculate currency conversions, tax refunds, or billing formulas directly.
What happens when it is wrong? Who is accountable?
Core Inquiry: When the synthesis hallucinates or misclassifies an exception, what fails? Does a transaction stall safely, or does an irreversible payment execute? Who signs their name to the outcome?
The Anti-Pattern: Designing a "One-Click Approve" button that induces passive rubber-stamping by frontline staff.
What evidence would justify expanding the capability?
Core Inquiry: What empirical production data proves that an assistant is ready to become an automated pass-through? If staff regularly inject context the model missed, why is the rest of the workflow still here?
The Anti-Pattern: Increasing system autonomy solely because model benchmarks improved on synthetic test sets.
Those questions can travel. The answers should not be expected to.
Readiness Is More Than Technical Readiness
This is another lesson I would carry forward across a portfolio. A business may have clean data and modern APIs and still not be ready for a new workflow:
Clean data pipelines, vector databases, modern REST/GraphQL APIs, high compute budget.
Yet the frontline employees do not trust the model. Ownership between Product and Engineering is contested. Leadership wants the prestige of AI without deciding which strategic outcome matters. Staff are exhausted by consecutive restructurings.
High Fragility RiskLegacy transactional monoliths, fragmented CSV logs, constrained engineering capacity.
Yet there is an acutely felt operational bottleneck, a united frontline team eager for cognitive relief, and leaders who treat pilot friction as learning rather than failure. The problem is crisp and the desire to improve is genuine.
High Transformation PotentialWhich one is more ready? I don't think that can be answered entirely from an architecture diagram.
People skills matter because readiness is partly human. The Graham description makes the same point explicitly: technical fluency matters, but so do trust, emotional intelligence and the ability to adapt to very different organizational cultures.
That is a part of this transition that feels familiar to me. I have repeatedly entered domains where I had to learn the language, understand the process, find the people who knew how things really worked and then translate that understanding into something a delivery team could use.
The capability is new. That operating pattern isn't.
I Would Build a Learning Portfolio
If I were supporting several businesses, I would want the learning from each implementation to become visible to the others. Not in the form of: "We built this there, so let's deploy it here."
More like building active organizational memory:
"We learned that retrieval quality collapsed when source policy documents had unclear departmental ownership and competing revisions."
"We learned that employees trusted generated case summaries only when verbatim source citations remained clickable alongside the brief."
"We learned that classification was 99% reliable for the standard path, but dangerously misleading on multi-jurisdiction edge cases."
"We learned that the legacy deterministic rule validation was actually creating more user drop-off than the generative explanation layer."
Now the portfolio has organizational memory. The next team can begin further forward without pretending its situation is identical. That is reusable leverage I believe in.
The System Should Become Less Dependent on the People Who Introduced It
There is one final piece I would design for deliberately. A successful implementation should not create permanent dependency on a central expert.
The local team should understand what the capability does, what it does not do, how its performance is evaluated and when something needs to be reconsidered.
That is not simply training. It is product ownership.
Eventually the people closest to the workflow should be able to say:
The Healthiest Sign of Product Maturity
That last sentence may be the healthiest sign of maturity. Technology should not need to defend its own existence. The business should remain free to choose the problem worth solving next.
And perhaps that is the thread connecting this entire retrospective series. If I had these capabilities during the earlier parts of my career, I would certainly have experimented with them. But I hope I would not have allowed the availability of a powerful new tool to decide what mattered.
The work still begins with people, goals, constraints and the reality of the environment. The technology enters after that.
And it stays only while it earns its place.
Choose what helps next
This perspective is complete on its own. If the situation is familiar, the routes below offer different kinds of context and support.
Try Sifting when signals need interpretation before commitment, or use the knowledge playbook when decisions need to survive a handover.
Learn how Richard works, start a direct conversation, or Review the bounded knowledge application. Reading and direct contact remain ungated.
Current questions