The Invisible Line
Less Queue, More Craft argued that when agents handle the queue, the bottleneck moves to judgment - strategy, coherence, and the bridge from prototype to production. This post names the place where that judgment is most urgently required: the moment something stops being an experiment and starts being relied on - and nobody can point to who decided, or who owns what happens next.
The platform can enforce a scan. It cannot enforce that someone understood what shipped.
Designed trust versus borrowed trust
At Hedera, I spent time in rooms with Fortune 500 engineering teams explaining asynchronous Byzantine Fault Tolerance - aBFT - the consensus design that lets a distributed network keep producing correct results even when some participants are slow, compromised, or dishonest. The insight that stuck was not the cryptography. It was the structural move: the system is built so it does not need trust in any single node. Correctness is a property of the architecture. You design dependence on trust out of the core.
That is the right way to build a ledger. It is not how most organizations govern AI-augmented software today. We still run on trust. Trust that whoever shipped the workflow understood it. Trust that someone would notice if the tool crossed from helper to dependency. Trust that "we'll clean it up later" will survive contact with production traffic. The platform can scan a binary and enforce a policy flag. It can block a dependency with a known CVE. What it cannot do is tell you whether a human actually understood what was deployed - or accepted accountability for its outputs when they reach a customer, auditor, or regulator.
I am not arguing against platforms. Central visibility, guardrails, and approved toolchains are necessary. But "the platform handles it" is the same shape of claim as "the blockchain handles it" - partly right, structurally incomplete. Technical correctness and institutional accountability are both necessary; neither replaces the other.
Enterprises bought distributed ledgers and still needed legal agreements, operational runbooks, and named owners for integrations - because the chain does not attend your steering committee when something goes wrong. AI-assisted development has the same shape at a different layer: the model may produce a correct-looking artifact while the organization has not produced a defensible decision about who will stand behind it. The gap is not hypocrisy; it is a category error between what the system outputs and what the institution commits to.
The invisible line
I saw the other side of that accountability chain at GoNetZero, leading product for enterprise carbon software. Footprint calculations for clients such as Singtel Data Centers were not productivity experiments. They fed compliance narratives, commercial decisions, and public disclosures. A wrong number there does not stay inside a sprint retrospective. It travels. The product question was never only "did the model produce a figure?" It was "who stands behind this figure, under what assumptions, and who gets called if reality disagrees?" The tool could assist; it could not absorb that responsibility. We had to design a chain where a named team could explain the pipeline, the data boundaries, and the limits of what the model was allowed to infer - because downstream, someone would treat the output as if it were definitive unless we told them otherwise.
That is the invisible line. On one side, you are learning: demos, sandboxes, internal proofs of concept. On the other side, someone is making a decision as if the output were true for purposes that matter - budget, safety, reputation, law. Organizations assume people know when they have crossed. They often do not. The boundary blurs when the tool is fast, when the demo is persuasive, and when nobody has defined what "production" means for that workflow. The same person can ship a prototype and a customer-facing surface in the same week; the repository does not always record which side of the line each deployment lived on.
The repository does not record which side of the line you are on unless you design it to.
More builders, accumulation risk, institutions
Democratization of Tooling established that people outside traditional engineering roles can now build real software with AI assistance. That is a genuine expansion of who can create. It also widens the pool of people who can cross the line without a formal handoff - not because they are careless, but because nothing in the tool tells them they have. The capability to build and the accountability for outcomes are two different things. Policy that only addresses the first will look like progress until the first serious audit.
The risk is not only "one bad deploy." It is accumulation. Many low-consequence experiments, each without an owner, still produce brittle dependencies - integrations nobody documented, prompts that became load-bearing, workflows that silently became the way work gets done. Individually they look fine. Together they become an architecture that cannot be reasoned about because no one was ever asked to own the whole slice. Ownership clarity is how you keep that from compounding.
In my current role at NUS, I see the institutional version of the same pattern: outputs that reach students, researchers, and partners. The scale is different from a startup, but the question is identical. Who is accountable when an assisted workflow touches a record that matters? If the answer is "the platform," you have not answered the question - you have deferred it to someone who will eventually need a name.
Intent review needs someone who can own the intent
Intent-Based Review asked reviewers to verify intent instead of every line of diff. That only works if the person reviewing has the standing and the understanding to own the intent they approve. Ownership clarity is the prerequisite. Without it, intent review becomes a ceremony - someone signs a box because the ticket needs a name, not because they could defend the decision under scrutiny.
What ownership clarity looks like
So what does ownership clarity look like in practice? It is smaller than a transformation program and larger than a policy PDF.
Named reviewer before deployment
A named reviewer before deployment is not "the team" - it is a human with a name and a role who can answer four questions without hand-waving: what does this system do in production; what data does it touch; what happens when it is wrong; and who is woken up? I have watched organizations default to "engineering owns it" when engineering did not know the agent rewrote a business rule. The reviewer does not have to be the only expert, but they have to be reachable and accountable - not a passive approval in a workflow tool. The point is not to add headcount; it is to eliminate the fiction that "someone must have signed off" when nobody could explain what they signed.
Prototype expiry
Prototype expiry means that if an AI-assisted workflow has not passed an explicit extension, it stops working until someone re-authorizes it. That sounds bureaucratic until you count how many "temporary" automations became load-bearing. Expiry forces a conversation: is this still an experiment, or does someone own it? Thirty days is a common default; the number matters less than the fact that inaction is not consent. If extending the prototype is too expensive, that is signal - the thing was already doing production work without a production owner.
AI-specific postmortem
An AI-specific postmortem template goes beyond generic incident reviews that ask what broke and how we patch it. AI-augmented failures often involve misunderstanding - what the tool did versus what people thought it did; who understood that gap; who owned the output; what changed in the model, prompt, integration, or data that made yesterday's acceptable behavior today's incident. If you cannot answer those, you do not have governance - you have a story you tell until the next story breaks.
The same judgment as knowing when to stop
Years earlier I closed a seed-funded startup after market validation showed the product would not clear the bar we had defined. Nobody fired that decision from the board deck. I had to look at the evidence, name the threshold, and stop - the same cognitive act as admitting a prototype has become production without an owner. It is uncomfortable. It is also what accountability looks like when the line is finally visible.
What comes next in the series
Ownership clarity is one component of readiness - the topic of this series. There are three others: failure-mode awareness, confidence calibration, and recovery design. You cannot trade them off against each other indefinitely; a gap in any one of them shows up as risk somewhere else. Sau Sheong Chang and others have mapped the capability dimension of AI in software work clearly - from in-context assistance toward autonomous software factories. This series builds the other dimension: whether your organization can safely absorb that capability at a given scope. The next post maps that full frame and names all four readiness components.
The Other Dimension · Part 1 of 6 · Next: The Other Dimension