A few weeks ago I was talking to someone I know and deeply respect. He runs successful businesses, and even his hobby is successful business but in another field. During our short call he asked me:

I wasn’t really prepared to this question, as noone asked me this in a very long time. I had questions like “what’s your ideal job?” or “what’s your ideal position in an organisation”, but never this.

Fumbling in my thoughts and very close to unexpected panic, I said that I could send my CV. But he refused:

I took a timeout and went on with my day in a kind of frozen and shocked state of mind.

He’s right.

I know what I CAN do

I can lead technical teams.
I can lead complex transformations.
I can be a sparring partner to leadership teams.
I can help analyse current or future strategy and solve underlying problems.

What I COULD do
I could return to solopreneurship.
I could revisit my startup platform CapabiliSense.
I could make it work differently.
I could do rebuild business plan, resources and investments, better investors presentations.

What I MUST do

Find and focus on a sustainable paid activity, leveraging lessons and experience of my consulting and transformation operator jobs.

What I SHOULD do

Learn more AI, refocus on my technical skills, and so on and so forth.

But I didn’t know what I WANT to do. And I had a very vague idea of what I LOVE DOING.

So I stopped doing what I was doing, and turned to my sparring partner.

Yes, an LLM environment with meticulously fine-tuned prompts, instructions and a thorough profile and archive of my thoughts and actions since 2024.

Rediscovering Socrates

When I was young I was fascinated by ancient greek culture, their philosophers and surrounding history. Then life happened. I switched to other type of reading. To other type of “mental massage”. You know what I mean.

Thanks to my LLM-as-my-sparring-partner that tried feeding me different brainstorming techniques, and my own critical thinking that triggers BS on generic AI output, I discovered (or remembered a somehow long forgotten) Socratic approach. Here’s what Wiki says about it:

The Socratic method is a form of argumentative dialogue in which an individual probes a conversation partner on a topic, using questions and clarifications, until the partner is pressed to come to a conclusion on their own, or else their reasoning breaks down and they are forced to admit ignorance.

So, what I came up with was a Socratic, one-question-at-a-time dialogue for genuine self-discovery where each answer changes what the next question should be. And it needed my actual history as raw material, not a “texture” that my setup has captured before.

Plus this dialogue had to stay completely open in any direction beyond my operator/AI-governance identity.

But before diving deep into my dialogue and practical prompts, I want to explain what this method actually is. And what it isn’t.

What this method is

A Socratic self‑discovery dialogue is a long, back‑and‑forth conversation (in my case, with GenAI) where the AI mostly asks me questions instead of giving me answers or lists of options.

I answer one question at a time, and each new question reacts to what I just said, rather than following a fixed script.

Over many turns, the AI starts to reflect patterns back to me - what I keep coming back to, what I avoid, where my words and my actions don’t actually match.

The whole exercise helps me say, in plain language, what I actually think or want, instead of having the model guess it for me.

Where it comes from

“…Do you see what a captious argument you are introducing — that, forsooth, a man cannot inquire either about what he knows or about whit he does not know? For he cannot inquire about what he knows, because he knows it, and in that case is in no need of inquiry; nor again can lie inquire about what he does not know, since he does not know about what he is to inquire.”

— Plato, Meno (385 BCE)

It comes from the way Socrates taught in ancient Greece. He didn’t lecture, but rather asked questions that forced people to understand their own beliefs.

Modern work on “Socratic prompts” for language models takes that same idea and turns it into a rule of interaction: the model should first ask clarifying and probing questions, then only later attempt an answer or summary.

Researchers at Princeton built a system called SocraticAI where several AI agents question each other about a problem instead of relying on one big static prompt.

Other projects and papers focus on training models to carry out Socratic questioning with humans. They guide students or users through their own thinking rather than handing them a packaged answer. Journal of Advances in Developmental Research published a very detailed white-paper on this approach.

I used the same principle, but simplified.

One LLM model for dialogue (and one for later checking), myself as human, one question at a time, focused on my own life rather than a math or coding problem.

Goals of the dialogue

The question of what do I want to do turned out to have actually three goals.

First, turn vague feelings into clear statements.

Many people have a fuzzy sense of “this is wrong” or “I’m drawn to that” but struggle to put it into words. Myself included. Socratic questioning pushed me to say what I mean, not just how I feel.

Second, surface hidden assumptions.

Well‑designed Socratic questions explicitly ask what I’m assuming, why I believe it and what evidence do I have.
Which is the classic purpose of the Socratic method.

Third, separate skill from desire.

In self‑discovery work, a good Socratic dialogue often returns to the difference between “I am good at this” and “I actively want more of this”
It actually kept challenging me when I mixed the two.

Taken together, the goal is not to produce a clever answer about me. It is to help me hear my own answer and test whether I actually believe it.

What it is good for

This dialogue is strong when the question is messy, vague or emotional.

In my case it was “what do I want to do?” and “what do I love doing?”

Other questions can be “what do I want next in my life?” or “why do I keep ending up in the same kind of role?”
There is no fixed right answer to look up.

This dialogue helps when there’s a gap between your public story and what you actually want, but you cannot see it clearly on your own. Does it sound familiar?

And of course, you must be willing to answer uncomfortable questions and to stay with this process across many turns (it took me two days to go through it), rather than asking once, getting an answer and moving it.

In other words, it is well suited to self‑discovery. It values clarification and big directional questions, where the main work is “understand myself,” rather than “pick from a menu.”

What it is bad for

This method is weak or actively unhelpful if you just need a fact, a procedure or a quick list.

For example, “give me ten job titles that fit my CV”. Here a Socratic dialogue will slow you down dramatically with no gain.

If there’s a clear and checkable right answer, and you care about accuracy more than exploration, like solving a precise technical problem. Here, direct reasoning and verification work better than open questions.

If you are not willing to answer honestly. If you keep performing a role, saying what sounds strong, safe or impressive, instead of what you actually think. In this case, the dialog will simply… reinforce that role.

If you treat the AI as an oracle. Research on Socratic methods for models warns that if you let the system “lead” too much without checking against reality, it can actually amplify biases and false assumptions instead of correcting them.

My workflow with LLMs

Now, when it’s clear for you what this method is good and bad for, let me share how I used it, and what I got as result.

You can use your own available models, or simply one model but in different sessions.

Phase 1: Socratic self-discovery with Claude Sonnet 5.0 Thinking

Run this as an ongoing conversation. Do not paste all your history at once if avoidable. Let it ask and adapt.

I need you to run a Socratic self-discovery dialogue with me. 
Someone important to me told me "don't send me your CV, tell me what you want to do." 
I need a real answer, not a positioned one.

Rules:
- Ask me ONE question at a time. Wait for my answer before asking the next.
- Each question must build on my previous answer, not follow a pre-set script.
- Be critical. If an answer sounds like a performance, a résumé line, or something I think I should say, call it out directly and ask again.
- Do not let me hide behind competence. "I'm good at X" is not the same as "I want more of X." Probe the difference every time it comes up.
- Do not suggest career directions yet. Your job right now is extraction, not brainstorming.
- After every 4-5 answers, reflect back a pattern you're noticing and ask me to confirm or correct it.

Start with this question: 
"Across everything you've built — <use your major career milestones> —
 which one would you do again tomorrow even if it paid less and impressed no one, and which one would you quietly decline?"

Use my history profile as evidence to draw on when useful, not as a constraint on what I'm "allowed" to want.

[paste relevant Master Profile extracts: case studies, narrative blocks, core philosophy]

Continue answering its questions honestly across multiple turns. Do not skip ahead.

Phase 2: Pattern synthesis — same thread, Claude Sonnet 5.0 Thinking

Trigger this once you feel the questions have gone deep enough, or after roughly 8-10 exchanges.

Stop asking questions. Synthesize what you've heard.

1. State the 2-3 recurring wants that showed up across my answers, in my language, not career jargon.
2. State the 1-2 things I kept describing as strengths but never once described as wants.
3. Name the tension you saw most clearly — where competence and desire pulled in different directions.
4. Do not propose job titles, archetypes, or lanes. 
Describe the shape of what I want as a set of conditions 
(type of problem, type of autonomy, type of stake, type of people), not a role.

Phase 3: Contrarian challenge — Grok 4.5 Thinking (separate thread)

Paste the Phase 2 synthesis only, not the full dialogue.

Here is a synthesis of what someone says they want professionally: [paste].

Attack it. 
1. Which part of this sounds like something they've talked themselves into rather than something they actually want?
2. What would this person be avoiding by choosing this, and is that avoidance disguised as preference?
3. If they said this out loud to a sharp, successful person who knows them well, what would that person's first skeptical question be?

Be blunt. Do not soften it. Do not propose alternatives — just pressure-test.

Phase 4: Verbal answer for the actual conversation — Claude Sonnet 5.0 Thinking

Return to the original thread with the Grok challenge pasted in.

Here's a contrarian challenge to my synthesis: [paste Grok output].

Use whatever holds up. 
Then draft a 90-second spoken answer to "tell me what you want to do"

Rules:
- Lead with the want, not the resume. No PL figures, no metrics, no company names in the first two sentences.
- He removed the CV on purpose. Do not sneak positioning language back in.
- End with something he could actually act on — an intro, an investment, a seat, a project — not a vague aspiration.
- Conversational register, not written register. This will be said out loud.

Why this particular setup?

If you run Phase 1 across multiple sessions, it risks losing thread continuity if the conversation gets archived.

Keep it in one live thread until Phase 4 is done.

The contrarian pass in Phase 3 exists specifically because a single-model dialogue can develop its own comfortable narrative with you over several turns. An outside model breaks that collusion before you speak to someone who will notice it immediately.

What answer did I give

This is the most honest version of what I actually want to do and love doing professionally.

If you ask me what I CAN, COULD or MUST do, I’d give you a different answer.

You don’t need my exact question. You need your own version of it.

Try this:

Sit with that for a day before you answer.

Before you close the article

I didn’t have this question ready. Nobody had asked it in years. I built the dialogue after the call, not before it.

If this made you think about what you actually want to do, do two things.

First, run this on yourself. If it makes you rediscover something that you forgot, then share it with your friends or colleagues:

Share

Second, subscribe. Most of what I write comes from questions I didn’t have a good answer for yet. The next one will be the same.

Subscribe now

And if this was worth a coffee: buymeacoffee.com/andreisavine

I have used Rumelt and Martin for years because they force the hard work most teams try to skip. Rumelt makes you find the Crux. Martin makes you choose where to play, how to win, which capabilities must exist and which management systems must hold the whole thing together.

That sequence works. It has saved me from more bad strategy decks than I can count. But it still starts one step too late.

Ritavan’s The System Gambit starts before diagnosis.

It asks a harsher question before you spend time on architecture, workshops and operating plans:

That question touched me because I have one AWS experience that fits it almost perfectly. Almost.

The primary filter

Actually, I do not read The System Gambit as a replacement for Rumelt or Martin. I read it as a gate before both.

The gate is simple and uncomfortable in the right way:

Self-improvement means each cycle makes the next cycle stronger without equivalent new input. Path-dependence means the position gets harder to copy because the loop had to be built over time. Management logic antagonism means the new loop requires behaviors, incentives and priorities that clash with the logic that made the current system successful.

Miss one condition and the judgment changes. You may still have a very good investment. You do not yet have a full system gambit.

That difference sounds academic until you test it against something real. Then it stops being a clever frame and starts cutting.

The AWS Enterprise Transformation Community of Practice

At AWS, the problem was never a shortage of answers. The problem was “answer overload”.

AWS was running on classic Amazon startup logic - high autonomy, strong local ownership, fast invention and very little patience for central drag. That logic produced serious customer value. It also produced a field full of overlapping methods, competing narratives, duplicated assets and too many silver bullets aimed at the same enterprise problem.

For enterprise customers, this abundance actually looked like noise. For account teams, it looked like friction. People could offer a lot. They could not always tell which path was proven, sequenced and right for the customer’s stage of change.

The AWS Enterprise Transformation Community of Practice was built to reduce that noise. Its job was to turn scattered field experience into a reusable loop:

The platform idea behind it was concrete. Replace the sprawl of wiki pages, Chime rooms, WorkDocs, Quip, Salesforce, MindTickle and manual trackers with one member experience that could hold the field memory together.

That phrase matters here. Field memory. Because that is what the community was trying to become.

A good customer conversation exposed better blockers. Better blocker visibility pulled in the right experts. Better expert swarming produced sharper assets and solutions. Better assets improved enablement. Better enablement improved the next customer conversation.

One 2019 experiment made the loop visible in numbers. The game-a-thons widened participation and drove a 400 percent increase in blockers identified in a quarter and a 300 percent increase in solutions identified in a quarter.

So the loop was real. Without a doubt, but..

Our community was not a real System Gambit

Run that AWS case through Ritavan’s filter and the answer becomes cleaner than many builders would like.

The first condition - self-improvement - was present. The more journeys, blockers, solutions, experts and learning paths the community accumulated, the more useful it became to the next field seller, the next architect and the next customer situation.

The second condition - path-dependence - was weaker. The community had trust, operating history and social capital. Those are real assets. But a rival hyperscaler with enough field scale, leadership backing and internal tooling could build a similar expert network, blocker library and enablement system. They could not copy the exact history. They could copy the capability class.

The third condition is where the case really breaks. The community depended on protected contribution time inside a company strongly optimized for immediate delivery and local ownership. Later, AWS management removed the protected 10 percent community time. That decision did not erase the idea or prove the community useless. It removed the operating oxygen the loop needed to keep feeding itself. Community members were no longer allowed to spend company time on community activities. Professional Services’ utilization metric won. And at that moment, The Community stopped being a community.

This operational line really matters. Strategy people love talking about flywheels. Far fewer are willing to support the payroll condition that keeps the wheel turning.

And this is where the argument gets more interesting, not less. The old AWS logic was not stupid. Local autonomy, speed and customer obsession were exactly what made the company formidable in the first place. The same logic that made the community necessary also made it institutionally fragile.

That is real management logic antagonism. Shared memory needed protected commons time. The dominant operating system kept pulling resources back toward near-term local delivery. Both sides were rational. They were both rational but against different values.

Let’s steelman this

A smart skeptic can push back here. They can say the community lasted, delivered value, remained functional after 2022 and improved reuse across enterprise transformation work. They would be right to say that.

They can also say that replicability is often overstated by strategy frameworks. Plenty of organizations fail to copy things that are visible in plain sight because they cannot copy trust, internal reputation and the social fabric around contribution. That is also true.

But that counterargument still falls short of the full claim.

A full system gambit does more than create a useful loop. It creates a position whose logic becomes harder and harder to defund, dislodge or reproduce as the loop strengthens.

That did not happen at AWS. The community needed continued management’s shelter. When the protected 10 percent time went away, the system showed its dependence on sponsorship and slack rather than its own growing inevitability.

Why Ritavan’s frame matters to me

Because it sharpens the entry test before I reach for Rumelt and Martin.

First ask whether the game can compound through its own loop.
Then diagnose the Crux.
Then design the choices, capabilities and systems.

Without that first filter, strong operators can spend months improving something that will always remain a funded intervention rather than a compounding position. The work can still be valuable. It just belongs in a different bucket.

That is the bucket I would put the AWS Enterprise Transformation Community of Practice in. It solved a real problem. It reduced field noise. It improved reuse. It built a functioning memory layer across enterprise transformation work.

But it did not become structurally irreversible. It stayed useful, yet broadly reproducible. It worked, yet still depended on active protection from the very management logic it was trying to correct.

Good investment, not a full system gambit.

A meaner standard

Too much strategy writing hands out gold medals for loops that have not earned them. This framework forces a meaner standard.

The AWS case met that standard in one place, half-met it in another and failed it where it mattered most. The loop improved with use. The history had value. The management system never stopped being able to starve it.

That is why the lesson is not triumph and it is not failure.

It is tension.

Some systems die because the idea was weak.

Others die because the institution refuses to keep funding the behavior that made the idea work.

The difference between those two deaths is where the real diagnostic work begins.

Before you close the article

This is the kind of diagnostic work I do before any transformation mandate starts. Not after the operating model is designed. Before.

If this helped you see the difference between a compounding position and a funded intervention, do two things.

First, send it to someone who is currently building a loop inside their organisation and calling it a flywheel. They need the filter before they need the architecture.

Share

Second, subscribe. I write these to sharpen the entry test before the expensive work begins. The next piece will be just as uncomfortable.

Subscribe now

And if this was worth a coffee: buymeacoffee.com/andreisavine

The AI layoff wave has a hangover

Last week, Forbes aggregated the damage: 55 percent of companies that cut staff for AI now regret it. The boomerang is already hitting the P&L. One in three employers has spent more on restaffing than they saved from the original cuts. And Gartner expects half of those eliminated roles to be quietly rehired by 2027.

HBR described this very sharp:

Companies are laying people off because of AI’s potential, not its performance.

The models are not yet delivering the margin, as the it was predicted in the forecast.

You see it in Atlassian, WiseTech and Snap - thousands of cuts framed publicly as AI pivots.

The workforce sees it too. They are running pattern recognition on their own survival. Writer’s 2026 enterprise survey shows 29 percent of employees now actively sabotage their company’s AI to protect their jobs by ignoring tools, feeding company data into public models and generating poor output.

McKinsey sums up the resulting gridlock. Around 88 percent of organisations are deploying AI, yet less than 20 percent see significant bottom-line impact.

When you put these together, you get a single structural fact:

If you own the operating model, the risk architecture or the headcount, in other words, if you sit on the Operating Committee - this is your problem. And this article is for you.

The CFO steelman

We have to name the uncomfortable truth before we fix the system.

Many Operating Committees know exactly what they are doing. They are using AI as a smokescreen for margin correction. They over-hired during the pandemic. Interest rates rose. Wall Street demanded margin. AI provided the perfect, forward-looking narrative to right-size the organisation without admitting a strategic error.

If you are running that play, acknowledge it. But understand the consequence. By using AI as the executioner for a margin problem, you destroy the trust required to run an actual AI transformation. You cannot ask a workforce to map their workflows into an agentic system on Monday if they watched their peers fired due to “AI efficiency” last Friday.

If you actually want the transformation, you have to build the missing operating system. I call it the Production Layer.

What Production Layer is

Most AI initiatives end where the real work begins. The demo or pilot works. The licences are bought. Very few leaders answer the only question that matters for value and survival:

That is the Production Layer. Everything between a model’s suggestion and the company actually doing something different. In human terms, it is System 2 for enterprise AI. System 1 executes on reflex. System 2 slows down, asks whether the action makes sense and decides what to do with the capacity that gets freed up.

The Production Layer has two sublayers.

1. The control plane for AI decisions. The architecture that decides what AI is allowed to do. This layer stops the liability crisis.

2. The redeployment pillar. The architecture that decides what happens to reclaimed human hours. It stops the sabotage and the boomerang rehiring costs.

If you skip the control plane, you get Delve. A 32-million-dollar compliance startup accused of faking 494 SOC 2 audits by substituting AI-generated boilerplate for real control testing.

If you skip the redeployment pillar, you get the Forrester regret curve.

Below are actionable steps to build the Production Layer

Step 1. Map AI decisions and classify reversibility

Know where AI actually makes decisions. Not tools. Decisions.

Build an inventory of every AI system that recommends or executes a decision, and bring it to the Operating Committee. Force every use case into a strict classification based on domain and reversibility.

Axis one is the domain. Does this decision touch:

1. Money: pricing, credit limits, revenue recognition.

2. Compliance: regulatory reporting, fraud flags, data privacy.

3. People: recruitment screening, shift allocation, performance flags, terminations.

Axis two is reversibility:

• Two-way door. You can undo the decision. A drafted internal email. A mis-routed IT ticket.

• One-way door. Once executed, the damage is baked in. A wrongful termination. A discriminatory loan denial. A submitted regulatory breach.

You do not need a ten-page governance taxonomy. You need a spreadsheet that looks like this, mapping the tool to the decision, to the domain and to the reversibility type:

Any AI suggestion that moves money, alters regulated disclosures or changes employment status without a controlled human check is a one-way door.

Notice the pricing engine. AI velocity means a two-way door can still destroy quarterly margin in seconds before a human can reverse it. It requires operational circuit-breakers to limit the blast radius.

This matrix is your first Production Layer artefact. It forces the committee to stop looking at software vendors and start looking at the liabilities they are plugging into their operating model.

Before we look at the solution, I am mapping the actual scale of enterprise AI failure.

Take a 30 seconds survey

Step 2. Build the control plane

Once you have your inventory, you decide how AI is allowed to touch those decisions. Add another column to assign the friction. There are only three types that matter here.

• Cognitive friction. The mental drag before a decision.

• Operational friction. The checklists, circuit-breakers and reconciliations that catch bad inputs.

• Accountability friction. The logging, explainability and human oversight

Consultancies spent thirty years removing the first two. AI accelerates the removal of all three. If you let AI strip accountability friction on one-way door decisions, you are building your own liability.

Build AI decision inventory with frictions required

I propose a simple governance rule:

• For standard two-way door decisions (summarising notes, routing tickets), remove cognitive and operational friction aggressively. Speed is safe.

• For high-velocity two-way door decisions (dynamic pricing, algorithmic trading), you must build operational circuit-breakers. Speed can destroy margin before a human notices.

• For one-way door decisions (firing, lending, regulatory reporting), you must add accountability friction back in. Stronger than before.

Wrap verification workflows around high-risk flows

The EU AI Act treats deployers of high-risk systems in recruitment and worker management as responsible for risk management, logging, and meaningful human oversight . That is you. Not the vendor.

No AI-generated decision that negatively affects employment status can be executed without a named human reviewer signing off with full context. That sign-off must be logged.

For customer decisions, look at Glia. Their March 2026 announcement guarantees against AI hallucinations and prompt injections for over 700 banks and credit unions. They separate understanding from response. LLMs parse intent, but final answers are constrained by pre-approved rulesets. They wrap this in bank-grade controls and write it into contracts. LLMs propose. Your control plane approves or rejects.

Glia published 2026 benchmarks, built on data from 400 financial institutions running this exact architecture, show that even with these strict controls in place, the AI contains up to 94 percent of routine tasks, with less than 10 percent of customers escalating to a human. The control plane kills the liability without killing the utility.

(Disclaimer: I have no commercial relationship with Glia.)

Create AI agent registry

No AI agent operates in the shadows. If it is not on the registry, it does not run.

Record the owner, the systems it can access, allowed actions versus proposed actions and retirement conditions.

When an agent creatively wanders into password-protected spaces, like Perplexity’s Comet browser agent did before Amazon secured an injunction, you need a system that should have stopped it.

Step 3. Build the redeployment pillar

You can build a flawless control plane (step 2) that governs every one-way door (step 1) perfectly. But if you do not explicitly define what happens to the human capacity that gets freed up, the system still collapses. I wrote about this recently: nearly a third of the workforce is actively sabotaging AI rollouts because 60 percent of executives plan to fire those who resists it.

Even a perfectly governed AI that still results in a layoff is still a threat. The control plane from Step 2 cannot fix that. You fix it with a hard redeployment contract.

Write a redeployment-first rule

For a defined window of 18 or 24 months any role materially impacted by AI goes through a structured redeployment and reskilling process. The organisation must prove that it tried to keep the person.

This avoids paying twice. First in severance, then in the boomerang rehiring premium that one in three companies is already paying when they realise they cut institutional knowledge.

Set participation and rights

Eurofound’s tracking proves AI is already a hard subject of collective bargaining across Europe.

The Hilfr-3F agreement in Denmark treats algorithmic decisions as employer decisions, giving workers the right to request explanations and contest them. The Italian cross-sector agreement requires companies to appoint dedicated roles to coordinate AI introduction with worker representatives.

Your internal rules must match this precedent. Workers have a right to know when AI is used in their evaluation or scheduling. AI output is always treated as employer action. The AI algorithm is employer’s responsibility.

Define the consultation path

Treat major workplace AI deployments as “bargainable” changes. Any high-risk AI affecting work allocation or evaluation from your Step 1 inventory cannot move from pilot to scale without formal consultation with works councils, unions or internal employee councils. You either design the social contract, or it will be designed for you. In court.

Publish visible artefacts

Publish an AI and jobs charter. Update job families to show AI-era roles: agent orchestrators, process architects and so on.

Report one line item quarterly: Hours reclaimed by AI, where they went, and headcount change broken down into redeployments versus AI-attributed exits. You cannot demand workforce trust without showing them the math.

Step 4. Link KPIs into finance and HR

The Production Layer requires a cockpit. If these numbers are not reviewed in the same Operating Committee meetings where you discuss EBIT and margin, your AI strategy lives only in slides.

Before you build that dashboard, drop the vanity metrics.

I recently advised an academic institution in France on their AI implementation challenges. Yesterday, they measured their development team’s performance by lines of code. Today, they realise AI-assisted coding makes that metric useless. So, they switched to measuring token usage.

This is tokenmaxxing. It is worse than burning money. When you gamify token consumption to prove AI adoption, you end up with mountains of AI-generated code and output that some human still has to verify, approve and sign for. Instead of measuring productivity, you are measuring the creation of unverified liability.

Drop the token counts. You need three new metric categories.

Control plane coverage

Owner: CIO and Chief Risk Officer

• One-way door governance. The percentage of high-risk, one-way decisions from your Step 1 matrix that actually pass through defined accountability friction before execution. If this is not 100 percent, you are carrying unpriced liability .

• Incident capture rate. The number of AI hallucinations, policy breaches or unauthorized access attempts caught by the Production Layer versus the number discovered by customers, regulators or the press.

The redeployment math

Owner: CFO and CHRO

• Reclaimed hour allocation. Total hours saved by AI, cleanly divided into three buckets:

  • hours redirected to revenue growth,

  • hours redirected to service quality,

  • hours converted to headcount reduction.

• The restaffing cost ratio. The total cost of rehiring and onboarding divided by the documented savings from the original AI-linked cuts. If this ratio climbs above 1.0, you are bleeding capital and paying the Forrester boomerang penalty.

• The redeployment ratio. Internal redeployments divided by total AI-attributed role impacts.

The “sabotage” index

Owner: COO and CHRO

• Active usage vs. provisioning. How many employees with access to enterprise AI tools actually use them for core tasks. A widening gap here is your leading indicator for the Writer’s 29 percent sabotage rate.

• Algorithmic grievance volume. The volume of internal disputes, union complaints or works-council escalations explicitly citing AI decisions in scheduling, performance, or pay.

Falsifiability tests

A framework that cannot be falsified is a belief system. You can run this like an operating model test.

The 90-day test

In ninety days, a serious Operating Committee should be able to show three things:

• A complete AI decision inventory classifying the domain and reversibility of every use case.

• Live control-plane rules for at least one high-risk one-way door (e.g., HR performance flags now require logged human sign-off).

• A drafted redeployment-first policy, discussed with worker representatives in at least one geography.

The 12-month test

In twelve months, if the Production Layer is real, you will see this pattern in the metrics:

• The redeployment ratio for AI-exposed roles is clearly above zero.

• There are no major AI-driven regulatory sanctions or data breaches attributable to uncontrolled agents.

• Trust metrics are stable, and sabotage indicators have dropped.

• Your restaffing cost ratio is below 1.0.

If your internal story resembles the Atlassian, WiseTech and Snap pattern - AI-framed layoffs, thin redeployment, rising workforce resistance, and quiet boomerang rehiring - you have your answer. You did not build a Production Layer. You built a System 1 accelerator and left System 2 to the courts, the unions and the press.

You can leave that last mile empty and let the system write its own answer. Or you can build the layer that decides what AI is allowed to do, and what you will do with the humans it displaces.

One of those is still reversible.

My final ask

These Methodologies reflect the exact conversations I am having with Operating Committees right now.

If this helped you see your organisation’s blind spots more clearly, do two things.

Key Sources

Scaling your human edge: The path to achieving value from AI, Writer 2026 State of Enterprise AI, Snap Is Laying Off 16% of Staff as It Embraces A.I., Why Companies Regret Laying Off Workers For AI, The State of Organizations 2026, Glia Launches Industry-First Contractual Guarantee Against AI Hallucinations, Eurofound: AI has become a subject of collective bargaining, The last mile, Productivity layoffs, One-way doors, Friction Factories.

Dr.Alejandro Jadad says:

Capital allocation, regulatory strategy, mission-critical rollouts. These are the arenas where a flawed answer, delivered with sophisticated confidence, creates a catastrophe.

This is the “House of Cards” problem we diagnosed. The system looks intelligent right up until the moment of total collapse.

The danger is two-fold: the error itself, and the supreme confidence of its delivery. A fundamentally wrong answer arrives with a fluent, polished analysis that can deceive seasoned operators. Dr. Alejandro Jadad, a physician forged by three decades of life-or-death decisions, gives this failure a precise name: mutual escalation.

Human confirmation bias and the AI’s native sycophancy create a feedback loop.

Both partners feel increasingly confident as they accelerate toward a cliff they cannot see. The entire enterprise AI investment thesis is at risk from this single repeating failure pattern.

I wrote that the solution required a human to provide “System 2” - a slow and deliberate logical check on the AI’s brilliant but erratic System 1 mind.

Jadad’s work takes this concept and turns it a machine.

His framework is a rigorously engineered architecture for forging a real human-AI partnership. A system built to survive contact with reality. He calls it a five-layer protection architecture.

I call it a System 2 engine. This is the blueprint.

Layer 1: Self-Protection

This starts with a simple, yet so difficult, rule: police your own cognitive failures.

For the human, this means hunting down your biases: the urge for confirmation, the attachment to sunk costs.
For the AI, it means guarding against its nature: the sycophancy, the confabulation, the drift toward premature coherence.

This layer is designed to prevent the most basic form of regret:

Accountability starts with individual thought hygiene.

Layer 2: Cross-Protection

This is where the sparring begins.

Each partner’s job is to protect the other from their predictable failures.

The AI is calibrated to challenge a human’s anchoring bias.
The human is trained to spot the AI’s “fragile teaming” - the appearance of partnership without the substance.

This is the defense against the second kind of regret:

The system assumes failure is inevitable and must be caught by the other.

Layer 3: Mutual Protection

This is the core of the engine. It makes bidirectional error-checking the default state.

Challenge is the constant, expected condition of the work, not an exception. If the reasoning seems too clean, challenge it. If the assumptions are untested, expose them.

The goal is to prevent “performance mode without cognition” - the smooth, polished collaboration that produces a catastrophic result.

This layer prevents the regret of a failed process:

Clarity is forged from friction.

Layer 4: Relationship Protection

A decision-making partnership degrades over time, especially under pressure.

This layer treats the relationship itself as a critical system requiring proactive maintenance. It mandates scheduled check-ins to hunt for upcoming failures: false consensus, reinforcement loops or a drift toward a “collaborative bubble.”

This is the safeguard against the regret of decay:

You inspect the partnership’s health. Constantly.

Layer 5: Beneficiary Protection

Finally, the architecture forces the partnership to look outside itself. Who is affected by this decision? What are the downstream consequences?

This layer makes those risks visible. It demands evidence, pre-defined stop rules, and implementation checks to protect the forgotten beneficiaries of any high-stakes choice. It prevents the human-AI dyad from optimizing for its own comfort at the expense of everyone else.

It is the final defense against the most insidious regret:

Reliability is an Architecture, Not a Prompt

Dr.Jadad’s work is a gift. It provides a falsifiable, replicable, and immediately deployable framework for building a genuine System 2 engine.

Why falsifiable? Because it can be proven wrong. This is a sign of intellectual honesty and operational seriousness. It is the opposite of a vague promise or a piece of corporate thought leadership. It is a specific, testable claim about reality.

It is also a powerful confirmation of the System 2 diagnosis. And it provides a potential cure.

His research showed that comprehensive one-shot prompting consistently failed to produce a protective state. The models learned to mimic partnership without achieving it. Behavioral evidence under pressure was the only thing that mattered.

Dr.Jadad ends his analysis with a clear message:

• For Leaders: This is a direct answer to the reliability gap. It is a framework for making AI survive contact with reality.

• For Builders: The entire protocol is published for validation. It is a falsifiable blueprint, not a PowerPoint theory. You can stress-test it yourself.

• For Enterprises: This is operational now. It requires zero model retraining and can be piloted with your existing systems.

The full paper is here. Read it.

Here is the deal.

If you aren’t subscribed, subscribe. It takes two seconds. It costs nothing. It separates the signal from the noise.

If you have a voice, restack it. Let your network see the signal.

And if this landed for you, if it gave you the language to name the problem, upgrade to Paid.

It is the only way to support the weekly Signals and influence the next deep-dive Analysis.

Subscribe now