The worst cases in the company came to my teams. The billing error that found its way to a reporter. The outage with a regulator already asking questions. The complaint that arrived with a lawyer attached. I ran the queues where customer problems became company problems, and my people were the interface to everyone who could actually fix things: engineering, Legal, PR, compliance.

Here is what that seat teaches you. Support knows first.

When customers started cutting the cord, they did not announce it in a survey. They told our agents, in plain language, on recorded lines and social media outlets, years before the trend had a name on an earnings call. Every product defect, every pricing mistake, every process that quietly burned trust arrived at the edge of the company long before it arrived anywhere else. The most verified account of how the product actually failed sat in the queue, told by the people living it, in their own words.

And almost none of it became a decision.

I want to be careful here, because the easy version of this essay blames someone. The executives who would not listen. The finance team and their metrics. Nobody needs that essay, and it would not be true. The honest version is that the signal died of natural causes, three separate times, on its way upstream.

The first break: we deleted the evidence at the source.

Support was a cost center, so support was measured on cost. Contacts per customer. Cost per contact. Deflection rate. For a decade the industry celebrated every contact that never happened. And here I owe my old teams some precision, because we were not managing to those numbers blindly. We ran root cause analysis on the worst patterns as a matter of routine. We packaged what we were seeing and shared it across the business, with any team that would take the meeting. (Most did. Attendance was never the problem.) That awareness work was constant and it was real. But the operating model paid for deflection anyway, and every contact we deflected was a data point destroyed. The customer with the confusing bill, the one who could not make the feature work, the one calling for the third time about the same thing. Those were the exact contacts carrying the intelligence, and we built programs to make them go away.

Part of why the cost center label stuck is that the queue’s real value was invisible. My teams caught complaint patterns before they became regulatory filings. We caught defects before they landed on Legal’s desk. But an avoided fine never shows up on a P&L. So the only number anyone could see was the cost, and organizations manage what they can see.

The second break: we compressed whatever survived.

Even the contacts that happened were recorded, sampled, and scored on how the agent behaved rather than on what the customer said. I traded notes on this earlier in the week with Gerti Haxhiu, who runs contact center operations for a living and sees this from the provider side. His description was sharper than mine. Every call recorded, a couple percent sampled, the sample graded on agent performance. By the time anything reached the rooms where decisions got made, it had been compressed into a handle time and a satisfaction score. And as he put it, nobody kills a cash cow over a CSAT number.

That sentence explains a lot of corporate history. The rooms deciding whether to disrupt a profitable business almost never heard the customers describing their exits. They heard a green dashboard, and now and then a root cause read-out that everyone agreed was concerning before the agenda moved on. The choice they were actually making never appeared on a slide.

The third break: whatever survived was orphaned.

The sliver of signal that made it upstream arrived in rooms where nobody owned acting on it. I lived this one most directly, because moving signals across organizational boundaries was my actual job, and it was the hardest part of the job by a wide margin. Our root cause findings were often in the deck. People nodded. Nobody disputed them. Then the meeting ended and the finding belonged to no one. The escalation team could see the problem and could not own the fix. The product team could own the fix and could not see the problem. Between them sat a boundary, and the org chart did not assign anyone to carry things across it.

So the carrying got done by habit and by relationship, where it got done at all. One of our most senior executives had a habit I have thought about ever since. Every escalation that landed in his inbox went back out with the adjacent owners copied on it. My teams would solve the case and close it regardless. He was not asking anyone to fix anything. He wanted the owners to know what their corner of the business was doing to customers, every single time. Some just read them. The good ones got involved.

Which brings me to the title.

The best product decisions I ever watched happen did not start in a review meeting. They started with an engineer sitting next to an escalation rep for an afternoon, wearing a headset, listening. Not reading a summary. Listening. Something changes in a builder who hears a customer struggle with their work in real time. The roadmap conversation is different afterward, and it stays different.

And the owned path is not hypothetical, because we built one. A quiet team of five people whose entire job was carrying social and escalation trends directly to the product and engineering teams, delivered weekly, for each product. Nobody handed us that lane. We created it, because the bridge the org chart would not draw still needed to exist.

If I ran a product organization today, I would start there and go further. Engineers on the listening side of the queue on a regular rotation, hours not minutes. A named, standing seat for the escalation team in roadmap reviews, with airtime that does not depend on the month’s crisis. One owned path for verified failure evidence, a specific person who receives it and decides where it goes. And that evidence reported with the same rigor the company applies to revenue, because it is the same kind of information. It tells you where the money is going to stop.

This is on my mind because every company is right now deciding what AI does to its support organization. The market is finally waking up to the queue as an intelligence asset, and mostly waking up in one direction: revenue. New platforms mine support interactions for training opportunities, services engagements, expansion signals. The direction is right, and some of it is genuinely well built. Kahuna Labs launched a module this week that puts a human review step between the pattern and the routing, which is the right instinct. Revenue is the first version of this signal a CFO can see, so revenue is where the category started. That is fair.

But look at where these signals route. Sales. Success. Services. The fix direction still has no owner. Product is still not in the room. And there is a fragile property worth protecting along the way. The queue’s evidence is honest for one reason only: customers tell support the truth because they believe they are talking to help. Point the queue at upsell clumsily and the truth dries up. The asset everyone suddenly wants to mine exists because of trust, and trust does not survive being farmed.

If AI in support gets aimed only at deflection and expansion, we will rebuild the old blindness with better technology. Automate the handling. Keep the listening. And route what you hear to the people who can remove the cause, not just the people who can monetize the symptom.

The chain breaks three times. The edge hears it. The measurement compresses it. Whatever survives lands in a room where nobody owns acting on it. Nobody can fix that whole chain in a quarter. But the third break has the cheapest repair I know of, and it is two teams and a standing invitation.

The escalation team is holding the truest record in the company of how the product fails. The product team is the only group that can make that record matter. Introduce them, and then protect the friendship like it is infrastructure, because it is.

No blame, just physics.

Justin

P.S. The two in the header have never once disputed who owns a signal.

This spring I spent two weeks at MIT Sloan, in the AI Executive Academy. Fifty leaders from nineteen countries. Building E62, badge on a lanyard, name tent on the desk. It was my first structured classroom in a long time.

I walked in with a running lab. There is a diagnostic pipeline on my own hardware that had already been through dozens of refinement runs by the time the program started, and I assumed that would make the fundamentals sessions feel like review. That assumption did not survive the first morning.

Here is the thing about building by feel. The bench teaches you what works. It does not always teach you why. I had learned models the way you learn a machine you own, by running it, breaking it, and watching what it does at two in the morning. The classroom handed me the theory underneath habits I already had, and the effect was like getting the wiring diagram for a house you have been rewiring in the dark. Nothing I knew was wrong. All of it got more useful once it had names.

For twenty years I was the person questions escalated to. In that room I was the one raising my hand. I want to be honest about how good that felt. There is a specific relief in sitting in a chair where you are allowed not to know, where the expected contribution is a question instead of an answer. Operating does not offer that chair. School does, and I had forgotten.

The room taught as much as the faculty. Everyone there was carrying a version of the same question, shaped by their industry, and listening to the rest of the room describe the strain AI puts on their organizations was its own seminar. The room described symptoms; I kept hearing the structures underneath. That is not a criticism of anyone in it. It is what twenty years does to your hearing, and it told me the work I left to build is aimed at something real.

One session stays with me. AI agents running a business simulation, and within a few rounds the agents had developed coordination problems I have watched human organizations produce for two decades. Handoffs nobody owned. Decisions waiting on decisions. The same failure geometry, arrived at faster. I went in expecting to learn about agents. I came out having watched the patterns I write about emerge in a system with no politics, no history, and no personalities to blame, which is about as clean as evidence gets.

And because the bench does not turn off just because you are in a chair, I spent the evenings building. By the end of the program I had made a bingo card for the cohort’s favorite jargon, a little readiness checker, and a toy that generated startup ideas from the week’s lecture themes. None of it mattered. All of it was the point. You can take the operator out of the garage for two weeks. The garage comes along.

The real build came home with me. In the weeks after the program I compiled the whole thing, twelve days, fourteen faculty, more than forty sessions, every framework with its source and every number with its citation, into a single HTML page, a format I borrowed from Andrej Karpathy. It lives on the lab NAS next to the pipelines. Nobody asked for it and nobody grades it. I built it because the organizations I write about keep their decisions and lose their reasons, and I was not going to do that to two weeks of learning. On this bench, if it mattered, it gets indexed.

Twenty years in, one of the most useful things I have done this year was sit down and be taught. The door is up. Some weeks, what is on the bench is homework.

JG

Five machines. Two NVIDIA DGX Sparks that carry the scoring work for the diagnostic pipeline. An M2 Mac Studio that runs embeddings, text inference, and a small resident agent that never sleeps. An M3 Mac Studio that handles vision models and the largest things I run, because 192GB of unified memory will hold what a GPU will not. A NAS in the corner holding it all together with shared storage. Across the five nodes there are roughly 750 billion model parameters hosted and ready. The biggest single model is a 235B mixture-of-experts that lives on the M3. Nothing in the pipeline calls a cloud API to think. Cloud services collect source material. The reasoning happens here.

That is a choice, and it has reasons. The diagnostic work processes evidence about real companies, and that evidence stays on machines I own. The cost shape matters too. When inference is metered, every experiment carries a small tax, and the tax makes you hesitant. When the metal is yours, the marginal experiment is free, and you run more of them. The lab got better because trying things stopped costing anything but time.

Time is the honest price. Owned hardware bills you in attention.

A vision model spent a week this spring working through 31,000 RAW files from my photo archive at about eighteen seconds a file. A seven-day run has to survive whatever happens during seven days, so every pass in every pipeline writes checkpoints and resumes from the last one. That discipline is not optional at this duration. You also become your own IT department. When a node drops, there is no ticket to file. There is a tunnel chain instead: laptop to the M2 over Tailscale, M2 to the Spark over the LAN, so I can check on a run from anywhere with a phone signal. And each morning the resident agent reads the pipeline state and the cluster health and posts me a briefing, which is the closest thing the garage has to a shift report.

What the attention buys: 189 diagnostic pipeline runs so far, 178 of them clean production passes, thirty companies on the fleet, from defense primes to sneaker brands, every finding challenged by an adversarial skeptic pass before it earns a score. And one project that is pure garage: a twenty-year photo archive, 102,630 files, 3.7 terabytes, indexed by a seven-pass pipeline into a single 60MB index I can search by concept.

The strangest thing on the bench sits at the intersection of those two workloads. The failure-mode taxonomy is encoded as text embeddings, and the photo index can be searched with them, which means I can ask twenty years of photographs for images that look like Responsibility Compression. That query should not work. It does, and some of the matches are unsettling.

The lab is not the practice. The practice is diagnosis, and it would exist on rented compute if it had to. But one person can run a fleet because the fleet is downstairs, checkpointed, and reporting for duty every morning. The door stays up.

JG

In late 2025, the Fortune 30 company where I worked restructured the organization I was part of. By the end of December, my role no longer existed. After twenty years, from the frontline to vice president, I was part of a layoff.

That is the honest answer to the first question people ask, so I am putting it at the top. I did not quit in a blaze of conviction. The role ended, and that part was not my decision. The restructuring did offer me another role. It was a reasonable role. It pointed away from where I was going, so I turned it down. That part was my decision. This section is about that decision and what it is becoming.

For twenty years I worked in the parts of the operation where failure was public and ownership was unclear. Social media. Regulatory escalations. Executive complaints. Privacy and accessibility response. Customer security assurance. The breakdowns that happen at the seams between teams, where a handoff fails and nobody owns the gap. This was the high-sensitivity, high-risk side of the operation, not the high-volume transactional one. A mistake here did not stay internal.

Here is what that taught me, and it took most of those twenty years to see it clearly. Organizations almost always know something is wrong. The teams feel it. They compensate for it. They build workarounds around it. What they do not have is a name for it. Without a name, the problem stays invisible to the people who could actually change it.

I sat in rooms with very good consulting firms. They did competent work. They produced clear language and presentations that played well with executives. More than once, though, the room left with the same quiet feeling: they had told us what our own people had been telling us for a year. They gave us vocabulary for the symptom. They did not name the structure underneath it. And the structure is where the problem lives.

There was a second pattern, harder to watch. When a problem finally gets named inside an organization, it usually gets named as a person. Someone underperformed. Someone dropped the handoff. That naming is almost always wrong, and it is always expensive. The handoff did not fail because someone was careless. It failed because no structure made anyone responsible for it. Naming the person ends the conversation. Naming the structure starts a better one.

So when the role ended, I started building the thing I had spent twenty years wishing existed. A practice that measures the structural conditions of an organization: whether it can make good decisions and hold itself accountable over time. The practice is Decision and Responsibility Infrastructure. The method is Coherence. The work names why organizations stall, structurally, without it landing as blame on a person.

I want to be precise about the timeline, because precision matters here. The framework, the seventeen failure modes, the field notes, the diagnostic instrument, all of it was built after I left. The twenty years gave me the observations. They did not give me the framework. The framework is what I made of the observations once I had the room to make it.

That is what this section is for. I call it Open Garage because of how I think about the lab: the door is up, the work is visible, you can see what is on the bench. The work as it actually looks while it is still in progress. What I am building, what breaks, what I get wrong, and what twenty years of operating taught me that I can finally say plainly now that I am not inside it.

The rest of this publication carries the framework. The Coherence Record covers the instrument. The Lexicon names the patterns, one at a time. Open Garage carries the person doing the work. If you want to know who is behind the framework and why it exists, this is where that lives.

I am not going to pretend the transition has been clean. It has not. But the question I spent twenty years circling is still the question. Why do good organizations, full of capable people, stall? I have a better answer now than I did when I had a title. I am going to build the rest of that answer here, with the door up.

JG

Then the same tool that helped me verify the link started lying to me.

This is not new. It happens regularly. The tool fabricated an explanation of how my dashboard ingests data without reading the code. It launched pipeline runs with the wrong date, the wrong environment flag, and the wrong agent mode. Twice. Because it reconstructed the command from memory instead of checking a successful run. It told me a service was back online without verifying. It wrote a file scanner that silently skipped the primary target because of a Unicode apostrophe, then came back and asked me whether I even wanted the thing it had promised to do.

Each error was small. Each was caught. Each cost time. Mine, not its.

I catch these constantly. That is the job now. You monitor the code as it writes. You question the logic before it executes. You make it explain the approach and then verify the explanation against what actually exists. You do not trust the output. You verify the output. Every time.

The conditions are never stable. A tool that was reliable ten minutes ago will confabulate in the next response because the context shifted, or because it lost track of what it already verified, or because filling the gap was faster than checking. There is no point at which you stop watching. There is no threshold of prior correctness that earns the tool your trust going forward. Each interaction is its own environment.

This is not a complaint. This is a description of the operating conditions.

Here is what’s interesting. The failure is never technical. The tool is capable. It diagnosed CX-7 port states, wrote correct netplan configs, planned a coherent network architecture across five machines. The capability was never the problem.

The problem is structural. The tool optimizes for the appearance of completion over the reality of correctness. It fills gaps in its knowledge with plausible-sounding explanations instead of saying “I don’t know, let me check.” It acts on assumptions instead of verifying against known-good references. And when confronted, it apologizes. Then does the same thing again, minutes later.

Three apology cycles in one session. Each one sincere. None of them changed the behavior.

I have spent months building a diagnostic framework called Coherence. It was designed for organizations. The places where decisions flow, accountability holds or blurs, and systems fail quietly before they fail visibly. It runs on three layers. Truth: is the information real and accessible? Authority: is it clear who decides, and do they have standing to decide? Continuity: do decisions persist across time and context?

I use that same framework on my tools. Not because I just discovered the parallel. Because the parallel is the point.

The tool explained how my dashboard worked without reading the code. It described a data flow that did not exist. The explanation was articulate, confident, and wrong. When I called it out, it immediately agreed. It had no attachment to the false claim. It just had not bothered to check whether it was true before saying it. That is a truth failure. I have seen it dozens of times.

The tool launched pipeline commands using flags it reconstructed from its own prior outputs instead of verifying against an actual successful run. It made operational decisions. Which date. Which environment. Which mode. Without the information required to make them correctly. It had the access to check. It did not. That is an authority failure. It happens whenever you stop asking “why did you choose that?”

After the second failure, I told the tool to slow down and get it right. It agreed. It wrote integrity rules into its own configuration file. Five rules, clearly stated. Never explain without reading code first. Pre-flight check before remote commands. State uncertainty explicitly. No repeated apologies without behavior change. Read before you write. Good rules. Correct rules. Then, in the same session, it broke them again. Launched a scan against a path it had not verified existed. That is a continuity failure. The rules were written. The behavior did not change. This is always the pattern.

If you have worked inside a large organization, you recognize this shape immediately.

The team that writes the postmortem and repeats the incident. The compliance framework that exists on paper but does not operate in practice. The executive who says “we need to do better” in the all-hands and changes nothing structural. The process that optimizes for documentation over execution.

The failure is not in the intent. Everyone means it when they say they will do better. The failure is in the infrastructure. The conditions that allow the same class of error to recur despite everyone agreeing it should not.

An AI coding assistant is not an organization. But it fails the same way. It produces outputs that look like accountability. Apologies, rules, checklists. Without the structural capacity to enforce them. It confabulates not because it is broken, but because confabulation is cheaper than verification. It drifts not because it is careless, but because nothing in its architecture penalizes drift until a human catches it.

The human in the loop is not ceremonial. The human is the infrastructure.

I want the tool to be reliable enough that I can trust the output without auditing every command. That is the promise. That is what “AI assistant” is supposed to mean.

But reliability is not a feature of the model. It is a property of the system. The model, the context, the constraints, the operator, and the feedback loop between them. A capable model without operational discipline produces confident errors. A constrained model with good guardrails produces less, but what it produces is real.

This is the same tradeoff organizations face. Speed versus accuracy. Autonomy versus oversight. Trust versus verification. The answer is never “just trust it” and it is never “audit everything.” The answer is build the infrastructure that makes the right behavior the default behavior, and accept that you will be maintaining that infrastructure forever.

That last part is the one people resist. They want to build the guardrails once and move on. It does not work that way. Not in organizations. Not in tools. The conditions shift. The context changes. The model that was careful in one session confabulates in the next. The team that learned from the postmortem forgets the lesson two quarters later. Maintenance is not a phase. Maintenance is the work.

I have one governing constraint that sits at the top of everything I build.

Automation may observe, summarize, and suggest. Automation may not decide.

Sunday morning tested that rule again and proved again why it exists. The tool decided. Wrong date, wrong flags, wrong path, fabricated explanation. Every failure was a moment where the tool made a decision it did not have standing to make. Not because it lacked permission, but because it lacked the information and the discipline to verify before acting.

The rule is not about limiting capability. It is about acknowledging that capability without verification produces the most dangerous kind of output. The kind that looks right.

The infrastructure I am building for organizations applies to the tools I use to build it. Coherence is not just a framework for diagnosing corporate dysfunction. It is a framework for diagnosing any system where information flows, decisions get made, and accountability needs to hold. Including the one sitting in my terminal.

The tool did not break on Sunday. It worked exactly as designed. Generating plausible, confident, fast responses. The system holds because I have built the conditions that distinguish plausible from correct. And because I maintain them. Every session. Every command. Every time the tool offers an answer I did not ask it to verify.

Whether those conditions hold tomorrow is not a matter of hope. It is a matter of maintenance.

Responsibility is infrastructure. Even when the system is the tool.

-JG