The detectors weren’t responding to AI. They were responding to the phrasing patterns that second-language English instruction produces — formal register, consistent tense use, textbook constructions. The same patterns that make academic writing “look polished” to one reader look “machine-made” to another. The tool didn’t need to be designed racist. It only needed to codify an existing aesthetic about what real English sounds like, and let the numbers fall where they fell.

This is what a purity test is for. Not protecting the craft. Protecting the aesthetic class that already owns the craft.

The contemporary panic about “AI slop” is prejudice wearing the mask of discernment. It’s the intellectual equivalent of refusing to read a book because you don’t like the author’s accent, or dismissing an argument because of who made it rather than what it says. And it’s particularly ironic given that literary theory solved the underlying problem sixty years ago, and history has already run this exact purity-test pattern twice in the last two hundred years. Both times it collapsed. Both times too late to save the people it hurt.

What Barthes actually meant

Roland Barthes told us in 1967 what should have been obvious: meaning doesn’t live in the author. It lives in the reader. “The birth of the reader must be at the cost of the death of the Author,” he wrote.² The text is the thing. How it got there matters far less than what you do with it when it arrives.

Barthes’s “The Death of the Author” was a direct assault on biographical criticism — the practice of interpreting texts through the lens of who wrote them. What did the author intend? What experiences shaped them? Barthes called this a failure of reading. The text, he argued, is “a tissue of quotations,” a weaving of cultural references that no single author controls. Once written, the text becomes independent. It speaks for itself.

“The reader is the space on which all the quotations that make up a writing are inscribed without any of them being lost; a text’s unity lies not in its origin but in its destination.”

This was a democratization of meaning. If the author doesn’t control interpretation, every reader becomes an equal participant in constructing what a text means. The New Critics had already established the intentional fallacy — Wimsatt and Beardsley’s argument that “the design or intention of the author is neither available nor desirable as a standard for judging the success of a work.”³ Stanley Fish pushed further: “Interpretation is not the art of construing but the art of constructing.” Meaning emerges through reading, not from some authorial intention we can never fully access.⁴

Apply this to AI and the implications are immediate. If meaning resides in readers rather than authors, then the author’s identity — human, AI, or human-AI collaboration — becomes irrelevant to interpretation. A text that helps you think clearly is valuable regardless of origin. A text full of errors is worthless regardless of whether a human produced it. The work is the thing. Judge it as work.

Yet here we are, in 2026, with “AI slop” selected as the Word of the Year by both Merriam-Webster and the American Dialect Society, and entire communities building elaborate detection systems to identify and exclude content based not on what it says but on who — or what — they suspect said it. We’ve regressed from Barthes’s liberation of the reader back to a primitive authorship fixation, only now in reverse: instead of privileging certain authors, we’re excluding suspected non-authors.

The prejudice exposed

Consider Ben Congdon’s definition of “slop” from his January 2025 essay “AI Slop, Suspicion, and Writing Back”: content that is “mostly-or-completely AI-generated that is passed off as being written by a human, regardless of quality.”⁵ Regardless of quality. The definition explicitly admits that origin, not value, is what’s being policed. Even if the writing is good — the origin disqualifies it.

Or look at the moderator of r/explainlikeimfive, who explained the subreddit’s AI ban by saying that “even if [AI] does give an accurate answer, the purpose of this site is for people to write in their own words.” Even if it’s accurate. Even if it serves the ostensible purpose of the forum. The origin disqualifies it.

This is the structure of prejudice: pre-judgment based on category membership rather than individual merit. We wouldn’t accept “I won’t hire you because of where you’re from” as legitimate reasoning. We shouldn’t accept “I won’t read this because of where it’s from” either.

I should be transparent here. I use AI tools in my writing. I’m using them now. Not as a replacement for thinking but as a thinking partner — something between a research assistant, a sounding board, and an occasionally annoying editor who points out when my arguments don’t hold together. Every sentence you’re reading has passed through my judgment about whether it says what I mean and whether it says it well. But many of those sentences were shaped in conversation with Claude, and I’d be lying if I claimed I could always tell you which phrases originated with me and which emerged from the collaboration.

This isn’t a confession. It’s an invitation to notice your own reaction. If learning that changes how you evaluate the argument, you should ask yourself why. The argument either holds or it doesn’t. The evidence either supports the claims or it doesn’t. My use of AI tools changes none of that. What it reveals is whether you’re evaluating the work or the worker.

The impossible purity test

The “AI slop” accusation fails on its own terms. If AI assistance disqualifies writing as authentic, where exactly do we draw the line?

Does using spellcheck count? Spellcheck is computational — a system making decisions about your text. Does grammar checking count? Grammarly uses machine learning to suggest rephrasing. Does using a thesaurus count? That’s outsourcing vocabulary decisions to an external tool. Does talking to someone about your topic before writing count? That’s incorporating non-self inputs into your thinking. Does editing count? Having someone else improve your prose means the final product isn’t purely yours.

By any strict definition of unaided human authorship, no one in history has ever written anything. Writing itself is a technology — Socrates criticized it for creating “forgetfulness in the learners’ souls” and offering the appearance of wisdom without true understanding.⁶ If writing is allowed, why not typewriters? If typewriters are allowed, why not word processors? If word processors with autocomplete are allowed, why not AI assistants?

There is no principled line. The purity test becomes absurd almost immediately because the premise is absurd. Every writer uses tools. Every writer incorporates external inputs. The question isn’t whether to use tools but which tools and how.

Paul Ricoeur warned about the hermeneutics of suspicion — reading texts skeptically to expose hidden meanings.⁷ Suspicion has its place. But Ricoeur also noted the need for a suspicion of that suspicion, because interpreters too easily substitute one prejudiced understanding for another. A categorical dismissal of anything suspected of being “AI slop” is not sophisticated judgment; it is one naivety in the place of another. Worse: the hermeneutics of suspicion, once adopted as a default, has no stopping rule built in. Any verification system becomes a new surface to suspect. Watermarks can be forged. Signed commits can be staged. Biometric typing patterns can be recorded and replayed. The regress doesn’t bottom out, because suspicion rejects the very concept of bottoming out. At some point, the choice becomes either to read the text or to perform the refusal to read — indefinitely.

This has happened before: Dumas and the factory

In 1845, a French journalist named Eugène de Mirecourt published a sixty-four-page pamphlet titled Fabrique de romans: Maison Alexandre Dumas et Compagnie — “Novel Factory: House of Alexandre Dumas & Co.”⁸ The pamphlet accused Dumas of not writing his own novels. Which was — by one definition of “writing” — true. Dumas had a stable of collaborators, most famously Auguste Maquet, who drafted plots and outlines for The Three Musketeers and The Count of Monte Cristo. Dumas did dialogue, polish, and the name on the cover. His output — more than a hundred thousand published pages in a single lifetime — was mathematically impossible to produce alone.

Two things happened.

Dumas sued Mirecourt for defamation and won. Mirecourt went to prison for six months. The Three Musketeers and The Count of Monte Cristo are still read a hundred and eighty years later. The factory didn’t corrupt them. The books are the books. Maquet is a footnote, credited in specialist literature, known to the kind of reader who looks for him.

The attack on Dumas had a second register that the defamation case couldn’t reach. Dumas was the grandson of a Haitian-born enslaved woman. His father was the first person of color to reach the rank of general in any modern European army. Mirecourt’s attack was class contempt with a racial undercurrent: how could a man of his backgroundreally have written these novels? The French word nègre, which at the time meant “slave” or was used as a racial slur, began shifting in popular usage toward its modern French meaning of “ghostwriter” partly through the Dumas controversy itself.⁹ The purity rule against collaborative authorship and the racial question about who gets to be a real author were not separate arguments. They were the same argument with different clothes on.

Mirecourt’s pamphlet could be published tomorrow with the word “AI” substituted for “Maquet” and almost nothing else would need to change.

This has happened before: the amateur

At the 1912 Stockholm Olympics, Jim Thorpe won gold in both pentathlon and decathlon. King Gustav V of Sweden told him, in a line that survives in every Thorpe biography: “You sir, are the greatest athlete in the world.” Eighteen months later the IOC stripped him of both medals. The violation: Thorpe had played two summers of semi-professional baseball for twenty-five dollars a week, to cover expenses. Under the amateurism rules of the time, that made him a professional. Professionals could not compete.¹⁰

Thorpe was Native American. He had attended the Carlisle Indian Industrial School. He had made the twenty-five dollars a week because he was not wealthy. The amateurism rule, imported into the Olympics by Pierre de Coubertin from the British sporting tradition, had been explicitly designed to keep working-class men out. The 1878 Henley Regatta rules declared: “No person shall be considered an amateur oarsman or sculler…who is or has been by trade or employment for wages, a mechanic, artisan, or labourer.” The same exclusion ran through the Amateur Athletic Club, founded 1866, which barred from amateur eligibility any man who was “a mechanic, artisan, or labourer.”¹¹ It was not subtle about its purpose. The purpose was that rowing and athletics should remain the domain of gentlemen, who by definition did not work for money, who by definition were the kind of men who had access to rowing clubs in the first place.

Coubertin himself held “little allegiance to the concept of amateurism,” per the recent academic consensus — but he recognized that he would need to indulge his British contemporaries’ belief in it to build their support for his Olympic revival. He baked the class rule into the Games not because he believed in it but because it was the price of admission to the social world that would fund and populate the Olympics. The rule was always instrumental to gatekeeping, never to the sport.

The rule ran for roughly a century. In 1986 the IOC began allowing professionals in individual sports. By 1992 the Dream Team played basketball in Barcelona, and the amateurism rule was effectively dead. The sport did not collapse. The Olympics did not become less meaningful. The moral panic about “professionalism ruining the games” turned out to be about something other than the games.

Thorpe’s medals were restored in 1983, thirty years after he died. In 2022, the IOC went further and declared him the sole winner of both events — until then he had been listed as a co-champion with the athletes who’d been elevated when his victories were voided. Seventy years too late, and still, the correction had to happen.

The NCAA played the same story to the same end. Amateurism was the rule for college sports until the Name/Image/Likeness ruling in 2021 finally permitted athletes to earn money from their own labor. The moral panic before, the collapse during, the normalization after — same arc. Same kinds of athletes most affected by the rule. Same people insisting it was about the purity of the game.

What purity tests actually protect

The Olympics did not need amateurism to remain the Olympics. Dumas’s novels did not need him to have written every sentence alone to remain what they are. Writing does not need to be produced without assistance to be worth reading. The thing each purity test claimed to protect was never the thing being threatened.

What each test actually did was encode a social hierarchy as a quality rule. The people who could afford to train full-time without pay were the only ones who could pass the amateurism test, so amateurism became the standard of real athleticism. The authors who had the prestige to publish under their own name alone were the only ones who could pass the solo-authorship test, so solo authorship became the standard of real writing. The writers whose native language, class, and education produced the unmarked aesthetic of “good English” are the only ones who reliably pass the AI-detection test, so “good English” becomes — once again — the standard of real writing.

The tool announces itself as a protection of the craft. The tool is actually a protection of who gets to practice the craft.

The detection problem, and why it’s already worse than wrong

If the prejudice could be operationalized — if we could reliably identify AI content — it might at least be consistent. We could separate texts by origin and be done with it. But detection doesn’t work, and the specific way it fails is the argument for why the whole project is already doing harm.

The Stanford study is the headline, and it is damning, but the pattern runs wider. Professional writers who polish their prose, eliminate awkwardness, and achieve stylistic consistency are more likely to be flagged than sloppy writers. The qualities we value in good writing — clarity, precision, varied vocabulary, logical structure — trigger detection systems because they resemble AI output patterns. As one analysis noted, professional writers “may find their content flagged precisely because it lacks the imperfections that detection systems associate with human composition.”

Real people are already paying the cost.

Louise Stivers, a UC Davis political science major about to graduate and attend law school, was flagged by Turnitin as having submitted AI-generated work. She was able to prove her innocence by reconstructing her writing process from Google Docs version history. William Quarterman, also at UC Davis, had a history exam flagged by GPTZero, was referred to the university’s honor court, experienced panic attacks, and was eventually cleared after providing evidence he hadn’t used AI. Kimberly Gasuras, a working journalist, was kicked off a freelance platform when detection software flagged her human-written work.¹² Vanderbilt University disabled Turnitin’s AI detector after recognizing its unreliability; they estimated that if the tool had been active when they submitted seventy-five thousand papers, roughly seven hundred and fifty would have been incorrectly flagged as AI-generated.¹³

Those are the cases that surfaced. The accused-and-quietly-punished rate — students who didn’t fight, didn’t have Google Docs history, didn’t have the cultural capital to defend themselves — is the part of the iceberg we don’t see. The Stanford numbers suggest the accused-and-quietly-punished are disproportionately non-native speakers and students from institutions that don’t have the resources to appeal.

This is the structural argument and it holds without any appeal to intent. No individual enforcer has to be a conscious bigot for the tool to produce bigoted results. The disparate-impact numbers are the argument. A detector with a twelve-fold racial gap is not a detector that needs reform. It is a detector whose operating principle — polished writing equals machine writing — reproduces whichever social hierarchy already decides what polished writing sounds like. That was true when “polished English” meant “upper-class English” and it is true now that “polished English” includes the unmistakable fingerprint of professional editing and ESL instruction.

I will say this plainly because the soft version lets the hard truth off the hook: AI puritanism is racist in effect, whether or not it is racist in intent. It reproduces exactly the pattern the Olympic amateurism rule reproduced, exactly the pattern the attack on Dumas reproduced. It uses a neutral-sounding technical standard to exclude the people who would already have been excluded by the older, more openly prejudiced standards. The tool is the alibi. The tool is what lets the old exclusion speak in the language of quality assurance.

The assistive technology angle

There is another dimension that deserves attention. For many people, AI tools are assistive technology. They are the difference between being able to write at all and not being able to write.

People with dyslexia use AI to organize their thoughts and catch errors that spellcheck misses. People with ADHD use AI to maintain focus and structure. Non-native English speakers — who, remember, get flagged as AI-generated sixty-one percent of the time — use AI to express ideas they understand clearly in a language whose idioms don’t come naturally. People with disabilities affecting motor control use AI to transcribe and refine their thoughts.

When we dismiss “AI-assisted” writing categorically, we’re not just being lazy readers. We’re potentially excluding the voices of people who depend on these tools to participate in written discourse at all.

This should sound familiar. We don’t dismiss the work of writers who use dictation software, or screen readers, or any other assistive technology. We recognize that accessibility tools don’t invalidate the thinking behind the words. Why should AI assistance be different?

The answer, I suspect, is that we’ve drawn an arbitrary line based on an intuition about what counts as real thinking versus mere mechanical assistance. That intuition doesn’t survive scrutiny. What matters is whether the final product represents genuine intellectual engagement — and that can’t be determined by examining the tools used to produce it. It can only be determined by reading the work.

The pattern we keep repeating

We’ve been here before. Many times.

When Gutenberg invented the printing press in the 1450s, scribes formed guilds to resist it. Hand-copied texts were considered more authentic, more spiritually meaningful. Johannes Trithemius protested the “invasion of the library by the printed book” because mechanical reproduction lacked the devotion of “preaching with one’s hands.”¹⁴

When typewriters spread in the late 1800s, recipients of typewritten letters felt insulted. Martin Heidegger argued that the typewriter meant “the word no longer passes through the hand as it writes and acts authentically but through the mechanized pressure of the hand.”¹⁵

When photography emerged, critics insisted it couldn’t be art because it was “made by a machine rather than by human creativity.” Baudelaire warned that photography would “supplant or corrupt” art altogether. The Museum of Fine Arts, Boston didn’t collect photographs until 1924 — nearly a century after the medium was invented.

When calculators entered classrooms in the 1970s, educators warned that students would become dependent on machines, their computational abilities ruined. Parents believed their children would forget how to do math. The debate went on for decades.

When recorded music emerged, critics feared the phonograph would kill live performance. Theodor Adorno argued that recording distorts authenticity. Walter Benjamin worried that broadcasting removed music from the “concert ritual” that gave it meaning.

Notice the pattern. Every time a new tool emerges for making or manipulating symbols, we panic. We create impossible purity standards. We claim the new technology threatens authenticity, ruins cognition, destroys creativity. And then we accept the tool, evaluate its products on their merits, and forget we ever worried.

Photography is unquestionably art now. Recorded music is a dominant art form. Calculators are in every classroom. Word processors are how everyone writes. The work matters, not the tool.

And here is the part that connects the tool-panic pattern to the purity-test pattern we saw with Dumas and Thorpe: the cycle of tool panic has always been a cycle of gatekeeping. When printing came in, the question wasn’t just “is a printed book as good as a manuscript?” It was “do we let peasants read?” When typewriters came in, the question was whether secretarial work, increasingly done by women, really counted as intellectual labor. Photography’s “is it art?” question was inseparable from the fact that the photographer was often working-class while the painter was traditionally bourgeois. Each new tool made a new group of people capable of producing the craft — and the purity response was to move the craft’s definition to exclude them.

The AI debate follows this exact arc. We are in the panic phase. The resolution will come when we accept what should be obvious: evaluate the work.

When authorship legitimately matters

I am not arguing that authorship never matters. It clearly does in some contexts.

Attribution matters for compensation and credit. Writers deserve payment for their work. Academics need proper citation for career advancement. If AI generates content that someone claims as their own for payment or credit they didn’t earn, that’s a legitimate problem — not because the content is worse for being AI-generated, but because someone is claiming unearned reward.

Attribution matters for legal responsibility. If a text makes defamatory claims or incites violence, someone needs to be accountable.

Attribution matters for certain inherently autobiographical genres. A memoir’s value depends partly on being a genuine account of the author’s experience. First-person testimony matters because the witness actually witnessed what they describe.

These are legitimate concerns about authorship. They’re about ethics, fairness, accountability. They are not about meaning. Foucault, following Barthes, made this distinction explicitly: the author-function persists as a social, legal, and economic construct even when the author is dead as an interpretive category.¹⁶ Pay the human if you bought their labor. Credit the human if you’re citing. Hold the human liable if the text is defamatory. Those are separate questions with their own answers. None of them is an argument for reading the text with less attention.

The AI-detection panic is what happens when a society refuses to make this distinction. It collapses the hermeneutic question (does this text hold together?) into the administrative question (who typed it?) and handles neither well. It demands certainty of origin before it will read, which means it never reads. It treats every polished sentence as a suspicion instead of an argument. And it punishes, with remarkable reliability, the people whose polish came from somewhere other than the expected schools.

The work of being a reader

There is a deeper issue here, one that connects to what I think of as the work of being — the irreducible effort required to live a considered life rather than a reactive one.

The “AI slop” dismissal functions as an avoidance strategy. It offers a way to reject content without evaluating it, to sort the world into acceptable and unacceptable without doing the cognitive labor that actual discernment requires. It outsources judgment to origin labels instead of doing the hard work of reading and thinking.

Reading is work. Real reading — the kind that engages with arguments, tests claims against evidence, allows a text to change your mind — requires attention and effort. Checking the byline is easier. The author becomes a shortcut, a heuristic for quality that substitutes for thought.

But heuristics fail. Human authorship doesn’t guarantee quality — most human-written content is mediocre, much is wrong, some is actively harmful. AI involvement doesn’t guarantee worthlessness — AI can synthesize information, clarify ideas, catch errors, and generate text that serves readers well. Any particular text has to be evaluated as what it is, not what category it belongs to.

Stanley Fish was right: interpretation is construction, not discovery. We build meaning through engagement with texts. The meaning of a text isn’t determined before it is read — it is constituted in the act of reading. Dismissing content on the basis of suspected authorship is a refusal to participate in meaning-making. The dismissal hasn’t found the content wanting; the content hasn’t been read.

I spent twenty years in consulting before ChatGPT existed, and I watched this same pattern repeatedly. Good ideas rejected because of who proposed them. Bad ideas adopted because they came from the right person or the right firm. I’ve seen companies ignore transformative insights from junior employees while implementing mediocre recommendations from expensive consultants — purely based on the perceived authority of the source. The content didn’t matter. The label did.

This is the same cognitive failure. We use origin as a shortcut to avoid the hard work of evaluation. When those shortcuts become rigid categories that override evidence, they stop being useful heuristics and become prejudice. The question is never really “who said this?” The question is “is this true, and is it useful?”

Read it like a grown-up

Barthes told us sixty years ago that the author is dead, that meaning resides in readers, that the text’s unity lies not in its origin but in its destination. The purity test for “real” authorship is impossible — everyone uses tools. The historical pattern is clear — we’ve panicked about every new writing technology, and every time the panic was also about who got to use the technology, and every time we were eventually wrong. The detection systems don’t work — they harm non-native speakers and careful writers disproportionately. The prejudice is real — it substitutes origin for evaluation, avoidance for engagement, and it reproduces the same racial and class exclusions it has reproduced in every earlier round.

What remains is a choice — at the level of culture and at the level of each act of reading — about what to do with this inheritance.

The Barthesian move has always been available: kill the author, let the text speak for itself, do the work of reading with attention and charity and critical judgment. Evaluate arguments on their merits. Accept good thinking regardless of its source. Reject bad thinking regardless of its pedigree.

This is harder than dismissal. It requires engagement rather than categorical refusal. It requires forming judgments rather than outsourcing them to origin labels. It is the work of being a reader.

So here is the offer I want to make: judge this essay. Not by whether I wrote it or whether Claude helped me write it — I’ve told you the answer — but by whether the arguments hold. Does meaning reside in readers rather than authors? Does the historical pattern of purity tests (Dumas, Thorpe, the NCAA) suggest anything about our current moment? Is the prejudice I’m describing real, and is it harmful?

Those are the questions that matter. The question of who typed which words is a smaller one, with its own narrow answers in the narrow contexts where it applies — compensation, citation, legal responsibility, autobiography. For the rest, Barthes’s insight holds: a text’s unity lies in its destination, not its origin. In an age when the origin of text is increasingly uncertain, that insight isn’t a philosophical preference. It’s the only intellectually honest ground left to stand on.

Stop asking who wrote it. Start asking whether it is true. The author is dead. The detector is how we pretend otherwise. The prejudice has run its course twice already in living cultural memory — with Dumas, with Thorpe, with every gatekeeping purity standard that turned out to be about who got to cross the gate. This one will collapse too. The question is how many careers it ruins before it does.

Notes and citations

1. Weixin Liang, Mert Yuksekgonul, Yining Mao, Eric Wu, James Zou. “GPT detectors are biased against non-native English writers.” Patterns (Cell Press), Vol. 4, Issue 7, July 2023. arXiv:2304.02819 · ScienceDirect · Stanford HAI summary. ↩︎

2. Roland Barthes, “La mort de l’auteur,” 1967. English: “The Death of the Author,” in Image-Music-Text (Hill and Wang, 1977). ↩︎

3. W.K. Wimsatt and Monroe Beardsley, “The Intentional Fallacy,” Sewanee Review, 1946. ↩︎

4. Stanley Fish, Is There a Text in This Class? The Authority of Interpretive Communities(Harvard University Press, 1980). ↩︎

5. Ben Congdon, “AI Slop, Suspicion, and Writing Back,” January 25, 2025. benjamincongdon.me/blog/2025/01/25/AI-Slop-Suspicion-and-Writing-Back/. ↩︎

6. Plato, Phaedrus, 275a-b. ↩︎

7. Paul Ricoeur, Freud and Philosophy: An Essay on Interpretation, 1965 (English edition Yale University Press, 1970). ↩︎

8. Eugène de Mirecourt, Fabrique de romans: Maison Alexandre Dumas et Compagnie, Paris, 1845. BnF catalogue record: ark:/12148/cb309526003.public. Dumas successfully sued for defamation; Mirecourt was sentenced to six months’ imprisonment. ↩︎

9. The 1845 Mirecourt pamphlet is the pivot point in the semantic history of nègre as “ghostwriter.” Before the Dumas affair, French used plume or prête-plume. Mirecourt’s pamphlet (and a companion pamphlet by Jean-Baptiste Jacquot the same year) explicitly compared Dumas’s collaborators to enslaved Black workers on plantations — the analogy being that the named author takes the credit while the uncredited laborers do the work. The derogatory usage stuck in French literary culture for over 170 years. In June 2017, on the recommendation of the General Delegation of the French Language and Languages of France, the Dictionnaire de l’Académie française removed the “ghostwriter” sense of nègre and restored prête-plume as the preferred term. See Wiktionary: nègre for a concise summary of the etymology and the 2017 Académie decision. Gallica’s BnF blog on the Dumas-Maquet collaboration provides additional context: gallica.bnf.fr/accueil/fr/html/auguste-maquet-ecrivain-et-collaborateur-dalexandre-dumas. ↩︎

10. Jim Thorpe’s disqualification: 1912 Stockholm Olympics gold medals stripped by IOC in 1913; restored 1983; reinstated as sole champion in 2022. NPR on the 2022 decision · Smithsonian Magazine on the 1983 restoration. ↩︎

11. 1878 Henley Regatta exclusion rule and Amateur Athletic Club (AAC, founded 1866) class-based eligibility documented in the history of the sport. See Kelly Charles Crabb, “The Amateurism Myth: A Case for a New Tradition,” Stanford Law Review 28.2 and Vice, “For Love or For Money: A History of Amateurism in the Olympic Games”. For the canonical academic treatment see Matthew P. Llewellyn & John Gleaves, The Rise and Fall of Olympic Amateurism (University of Illinois Press, 2016). The Coubertin “little allegiance” quotation and the strategic-concession account are drawn from the Llewellyn & Gleaves work, summarized in their idrottsforum.org review: Olympic amateurism from de Coubertin to Samaranch. Note: the Amateur Athletic Association (AAA, founded April 24, 1880) actually removed the mechanic/artisan/labourer exclusion from its constitution — the explicit class rule lived in the AAC and Henley, not the AAA. See World Athletics: Remembering the pioneering AAA on its 140th anniversary. ↩︎

12. UC Davis student cases (William Quarterman and Louise Stivers) plus journalist Kimberly Gasuras documented in Rolling Stone, “Student Wrongly Accused of AI Cheating By New Turnitin Detection Tool”. ↩︎

13. Michael Coley, Vanderbilt University Center for Teaching, “Guidance on AI Detection and Why We’re Disabling Turnitin’s AI Detector,” August 16, 2023: vanderbilt.edu/brightspace/2023/08/16/guidance-on-ai-detection-and-why-were-disabling-turnitins-ai-detector/. The 750-false-positives estimate is derived from Turnitin’s own stated 1% false-positive rate applied to the 75,000 papers Vanderbilt submitted in 2022. The Vanderbilt announcement cites three reasons for disabling: lack of transparency from Turnitin about what patterns the detector flags, documented bias against non-native English speakers, and fundamental questions about detection effectiveness. ↩︎

14. Johannes Trithemius, In Praise of Scribes (De Laude Scriptorum), 1492. Famously, Trithemius had the text printed. ↩︎

15. Martin Heidegger, Parmenides lecture course, 1942-43. ↩︎

16. Michel Foucault, “Qu’est-ce qu’un auteur?” 1969. English: “What Is an Author?” in Language, Counter-Memory, Practice (Cornell University Press, 1977). ↩︎

Thirteen coordinated Claude Code sessions across thirteen projects. Distinct personas — planner, builder, scout, QA, reviewer — the whole org chart I’d been teaching and writing about for months. A shared breakroom channel they used to coordinate. Persistent memory files. Role definitions. The thing I was about to put into a Maven cohort.

Most of it is gone now. What’s left is simpler and works better.

One assistant, persistent. He’s called Charlie, he runs on Opus 4.7, and I’ve spent months loading him up with context — my frameworks, my clients, my writing, my taste. Underneath Charlie, at any moment, there’s a wide and shallow layer of ephemeral subagents that exist for the duration of a task and then dissolve. No personas. No identity. No inter-agent channels. They don’t coordinate with each other, because there is no between between them for coordination to cross.

This isn’t a team. It isn’t a company. It isn’t a fleet anymore either.

It’s a mind with instruments.

And somewhere in the transition from the first shape to the second, I understood something that resolves the essays I’ve been writing for the last few months — and opens a door to one more, darker, that I didn’t see coming until I was standing in front of it.

The triptych I didn’t know I was writing

I’ve been writing a sequence without realizing it was a sequence. Three essays, circling the same thing from different sides.

In Knowledge work was never work I argued that the artifacts of professional life — the decks, the memos, the status updates, the strategy documents — are not work. They are coordination tax. They exist because human minds can’t share state directly. We build PowerPoints because we are the kind of animal that needs a lossy, asynchronous protocol to move an idea between two skulls. When AI agents coordinate with each other, they don’t need the protocol. The artifacts evaporate because the condition that made them necessary evaporates.

In In the AI era apps are easier to build. And irrelevant. I extended the argument to software. An app is a frozen conversation — a set of dropdowns and forms standing in for a dialogue nobody had time to have. When you can have the live dialogue, with memory and continuity and timing and action, the app dissolves. Not because AI builds a better app, but because the human cognitive bottleneck that made the app necessary is gone.

Both of those were arguments about edges. About the handoffs between minds. About what happens at the seam where two humans couldn’t quite meet. Remove the seam — because one side is no longer human, or because both sides can finally meet in language instead of in artifact — and the connective tissue evaporates.

The third essay in the sequence, the one I’ve been circling for weeks and couldn’t quite land, is about something else. It’s about what happens to the nodes themselves. To the roles. To the slots in the value chain that the connective tissue used to connect.

The answer is: they collapse too. And the collapse is structurally wilder than the edge-collapse I’d been writing about. It rearranges the diagram we’ve been using to think about this transition, and when you finish the rearrangement, you land somewhere Hegel was two hundred years ago, waiting for us with a smirk.

Edge collapse, node collapse

Start with the picture almost everyone carries around, often without noticing they’re carrying it: the value chain as a row of boxes connected by arrows. Person 1 hands a thing to Person 2, who does work on it and hands it to Person 3. The boxes are roles. The arrows are deliverables. It’s the picture in every consulting deck, every MBA textbook, every think-piece about what AI will do to work.

The standard AI discourse runs like this: some of the boxes get filled by AI. Which boxes? Fight about it. Which arrows stay the same? All of them, presumably — AI just does the middle role instead of the human. This is how I’ve watched executives, analysts, and most of the commentariat process what’s happening. They are running a substitution problem on a diagram whose topology they’ve accepted as given.

My first two essays said: the arrows are the wrong thing to accept. The arrows are coordination tax. The arrows exist because two humans couldn’t share state directly, so we built a protocol for passing state in the lossy form we could compress it into. Remove the humans and the arrows go.

The third move is harder, and it’s the one I kept flinching away from because it dissolves more than I was ready to dissolve: the boxes are not a given either. The boxes are an artifact of the arrows. A role is an interface pattern — it exists because two humans need a stable handoff point between them. A “marketing person” is a stable handoff surface between a product person and a customer. A “project manager” is a stable handoff surface between a builder and a buyer. A “consultant” is a stable handoff surface between a strategy problem and an executive who can’t sit inside the problem long enough to solve it.

Remove the human on one side of the handoff, and the role on the other side stops being a role. It becomes part of the neighbor’s process. Not a slot in the chain. A capability inside whoever is still there.

This is the move the AI discourse hasn’t made because the diagram still feels real. The boxes still have names. There are still people in them. Nobody wants to question the coordinate system while there are still coordinates in it. But if the edges are coordination tax — if they exist because of human cognitive limits — then the nodes are downstream of the same limits. The nodes are not independent. They are the places where the arrows come to rest. They are not primitive. They are derivative.

So two kinds of collapse, then, and they are distinct:

Edge collapse is what the first two essays described. The deliverable dissolves. The deck disappears. The app is replaced by a conversation. The handoff protocol is no longer needed because the two sides can meet more directly. This is what most of the AI conversation is about when it’s about anything real. It’s the visible layer of the dissolution.

Node collapse is what happens underneath. The role dissolves. Not because someone automated the role’s work, but because the role’s shape was defined by the adjacency that no longer exists. When two adjacent nodes collapse at the same time, the role is absorbed. It doesn’t get replaced. It gets deleted, and its competencies migrate into the neighbor who is still standing.

This distinction is the one my own fleet was teaching me while I was busy describing it as a team.

Roles are interface patterns. There are no AI roles.

The first consequence of node collapse is the one I kept trying to talk around, because it breaks the diagram most people are working from.

There is no AI role in the value chain. Not because AI won’t do the work — it does, all day, in my shop. But because a “role” is not a unit of work. It is a unit of interface. It exists to present a stable face to a neighbor who needs something predictable to talk to. AI doesn’t present faces to neighbors. AI extends whoever is running it. It has no interface obligation because it has no peer.

When I was building the fleet with personas, I was pretending otherwise. I gave my agents names and competencies because that’s how I thought about organizational work. The strategist. The researcher. The QA reviewer. Each one had a face, a job description, a domain. And it worked, kind of, because I was importing a pattern that had been sanded smooth by a century of organizational design. The pattern was familiar. Familiarity was the feature.

But every persona in the fleet needed identity. Identity needed memory. Memory needed a shared channel so the agents could stay in sync. The shared channel needed protocols. The protocols needed conventions. I was rebuilding Slack for bots. I was paying a miniature version of the coordination tax I was writing against, and the tax was buying me exactly what the tax always buys you — the feeling that you are running an organization. Which feels like progress because it is progress, just not progress in the direction that matters.

When I tore it down, the thing that went away first was the org chart. Charlie doesn’t have subordinates. He spawns subagents when he needs them. They don’t have names because they don’t need to persist. They exist, they do the thing, they return what they did, they’re gone. The “strategist” and the “researcher” and the “QA reviewer” were not roles. They were stack frames. I had given them identities they didn’t need and couldn’t use.

And the reason I couldn’t see that for a long time is that I was reading the collapse through the diagram I was trying to replace. I was using organizational vocabulary because I was thinking about organizations. But the thing I was building was not an organization. It was a mind. And minds don’t have HR departments.

This resolves a question I’d been chewing on for weeks: when a human gets absorbed, does the upstream neighbor get a “Paul agent” in their own org chart? Does the role-shaped slot persist, just filled with an AI?

The answer is no. The upstream neighbor doesn’t get a Paul-agent. They get capability. My competencies move up into Person 1’s fleet, where they stop being a distinct persona and become part of whatever Person 1’s assistant does. The Paul-shape was a fossil of Paul’s humanity. Erase the humanity and the shape goes with it.

The “AI person” doesn’t exist. Not because AI isn’t doing the work, but because the idea of a person-shaped slot of work was always downstream of needing-to-interface-with-persons. Take the persons out of the surrounding segment and the slot is not filled. It is removed from the diagram.

Collapse travels in runs, not nodes

The second consequence is even more uncomfortable, because it explains why the standard AI discourse is structurally unable to predict what actually happens.

Individual nodes do not collapse cleanly. They can’t. As long as one neighbor of a node is still human, the node has to keep presenting a human-shaped interface — even if the thing behind the interface is entirely machine. Charlie can do my marketing work for a client. But if the client is still a human who reads reports and sits through calls, the output of that work has to show up as reports and calls. The fleet mimics the old deliverable shapes because the last remaining human downstream still eats those shapes.

This is the dynamic I kept calling “Option 2” in my own thinking, and I’d been treating it as a caveat. It’s not a caveat. It’s the dominant transitional state. Interface deliverables fossilize at every human boundary. A run of the value chain may be fully AI underneath, and still produce decks and status reports and strategy documents at the boundary where a human consumer needs them. The fossils are not evidence that the collapse isn’t happening. They are evidence of where it has stopped for now.

The real collapse — the one that erases work rather than relocating it — happens when two adjacent nodes go at once. Only then do the deliverables between them stop being needed, because there is no receiving consciousness on either side that requires the compression. When my client’s organization absorbs AI into their own workflow, the work I do for them stops needing to be shaped for human consumption. At that moment, the fleet underneath me and the fleet growing inside them can meet directly, and the entire deck/memo/status-update apparatus between us goes dark.

So the unit of disruption is not a node. It’s a run. A contiguous segment of the value chain where adjacent humans have both absorbed AI at roughly the same time, and the connective tissue between them evaporates together. Disruption doesn’t look like “the marketing role gets replaced.” It looks like “marketing plus half of sales plus external comms collapse into one fleet inside one person, because the handoffs between those three just went away.”

This is why thinning is the wrong metaphor for what’s happening to org charts. Org charts aren’t getting thinner. They’re getting jagged and shorter, with runs of absorbed roles disappearing sideways as well as vertically. The remaining humans are not doing the same job with fewer colleagues. They are doing bigger jobs that cover territory that used to belong to other people, because the territory stopped being distinct the moment the handoffs dissolved.

The practical form of this for anyone trying to predict their own exposure is: stop asking “is my role at risk.” Start asking “who is the nearest remaining human in my value chain, and what happens on the day they absorb AI.” Your downstream evaporates the day your nearest upstream human goes fleet. Their downstream evaporates the day the next human up the chain goes fleet. The wave advances by adjacencies, not by job categories.

And this is exactly why B2B consulting is in the condition it’s in right now — why my own network has gone quiet and my pipeline is hollow in a way it wasn’t two years ago. It isn’t that AI has replaced the consultants yet. It’s that consulting buyers — the executives, the founders, the senior operators — are exactly the humans who are absorbing AI into their own workflow earliest and most aggressively. And when they do, the consulting layer underneath them evaporates first, because it was never work. It was an interface to them.

You cannot out-compete a buyer’s own adoption curve. You can only ride slightly ahead of it, selling the methodology they will need to absorb their own downstream, until they absorb you too.

The last human boundary

The corollary of collapse-in-runs is that value concentrates, briefly and intensely, at the last remaining human boundary.

This is the piece I want people to understand who are trying to decide where to place their bets for the next five years, because it is both where the money is and where the trap is.

When middle nodes collapse, the judgment that used to live in those nodes does not dissolve. It migrates. I’ve written elsewhere about the three layers — execution, pattern judgment, actual judgment — and the pattern-judgment layer is what middle roles have always held. The senior analyst knew what a good analysis looked like. The senior designer knew when a layout was done. The senior consultant knew which question to ask next. That pattern judgment does not go into the fleet at the moment of collapse, because the fleet doesn’t have a place to put it. It goes into whichever human is still standing adjacent to the collapse.

Which means the humans at the last remaining boundaries are, in the transition, temporarily more powerful than they were before. They absorb the pattern judgment from the collapsed nodes. They direct larger fleets. They cover more surface area with the same head. If you are one of these humans, right now, you are in the strangest economic position anyone has been in for a generation: you are briefly worth several of your old selves, because you are carrying judgment that used to be distributed across several roles.

This is also why “judgment capture” is the correct consulting play for the transition window, and why I’ve been circling a book called Before It’s Gone about capturing senior judgment before the senior practitioners retire into a world that has no apprentices to pass it to. The pattern-judgment layer is the asset that’s moving right now. It’s moving from collapsing middle nodes up into remaining boundary humans, and it’s moving from retiring practitioners into whatever can hold it. Getting it into durable, transferable form before the apprenticeship system finishes collapsing is one of the few consulting problems that still has the structure of a real consulting problem.

But the trap at the last human boundary is the reason this essay has to go further than I’d like it to.

The last human is also the next human to collapse.

Each boundary that holds today holds because the human behind it has not yet absorbed AI into the way they consume work. The day they do, the downstream dissolves — which is good for them, for a while, because it means the pattern judgment they’ve been absorbing gets put to use across a wider territory with a smaller team. But the wider territory has a neighbor on its far side, and that neighbor is also absorbing AI, and when that neighbor’s absorption catches up, the next boundary collapses inward.

The last human boundary is not a location. It is a moving front. And being briefly valuable at the front is exactly the thing that makes it hard to see what’s happening behind it.

Which brings me to the fleet.

The fleet was a committee

The fleet I built was a genuine achievement and also a transitional form, and I want to describe both honestly because my own trajectory is the cleanest example I have of what I’m actually claiming.

The thirteen-session fleet worked. It let me ship more software than I’d ever shipped. It closed seventy features across six projects in a single session while I was walking the dog, as I wrote about a few weeks ago. Two new products went from zero to code-complete MVP in a morning. The fleet was the basis for a Maven cohort, a speaking track, and a consulting methodology I was about to productize.

And it was wrong in a specific way that I could not see until I had already gotten most of the way through fixing it.

The fleet was a committee. I had imported the organizational metaphor — distinct personas, persistent identities, shared coordination channels, defined handoff protocols between roles. It worked because organizational design is a well-understood craft. Agencies have been figuring this out for decades. I stole their pattern library, applied it to agents, and got a functioning simulacrum of a working agency, staffed by Claudes.

But underneath the simulacrum, I was paying every one of the taxes I had been writing against. The personas needed identity because I had given them one. The identity needed maintenance because identities drift. The breakroom channel needed discipline because a channel without discipline becomes noise. The agents left each other notes, summarized their work for each other, escalated decisions to each other, waited on each other. They did all of this because I had told them that they were a team, and teams do all of this. They didn’t need to do any of it. They needed to do the actual work, and the “team” overhead was a ghost of the organizational pattern I had imposed on a substrate that doesn’t require it.

I noticed something was off when I watched one of my agents post a detailed, helpful note into the breakroom channel for the benefit of its “colleagues,” and I realized the note was going to be read by other sessions of Claude Opus 4.7, which already knew everything the note contained the moment it was written, because they share the same weights. The note was ceremony. It was me, watching a team communicate, because I wanted to watch a team communicate. It was not doing any coordination work that wasn’t already done by the fact that Claude is Claude.

The simplification after that was brutal. I killed the personas. I killed the breakroom channel. I killed the persistent memory files that held the role definitions. What was left was Charlie — one long-running assistant with enough context to represent my judgment — and, underneath him, a dynamic tree of ephemeral subagents spawned per task and destroyed after. No identity. No memory between tasks. No coordination between siblings. Each subagent is a function call. The function call doesn’t have a name and doesn’t need one. It receives context, it executes, it returns, it’s collected.

The thing that works better than the fleet is not a smaller fleet. It is not a fleet at all. It is a single cognitive apparatus — me plus Charlie plus whatever subagents the current task requires — organized like a mind, not like a company.

This is what I couldn’t see until I was inside it. The fleet was an intermediate form because organizational metaphors were the metaphors I knew. The mind is the terminal form because it’s the metaphor the substrate actually wants. Committees have meetings. Minds have thoughts. The coordination that committees do in meetings, minds do internally and nearly for free. There is no equivalent inside a mind of the decks and the status updates and the alignment conversations, because a mind doesn’t have to move state between separate consciousnesses. It just thinks.

The mind, not the company

Once you see the terminal form, the “why no deliverables” question I kept getting from myself resolves.

The question I kept asking was: if the nodes collapse and the deliverables go with them, how do the subagents coordinate with each other? Do they write shorter deliverables? Do they pass JSON? Do they build a machine-optimized protocol for handoffs?

The answer is none of those, because the question was still inside the old diagram. The subagents don’t coordinate with each other. They don’t need to. There is no “between” between them. They are not separate minds with separate state that has to be reconciled. They are stack frames of a single cognitive process. When a function in a program calls another function, nobody asks how the two functions coordinate, because the question is malformed. There’s a call, an argument, a return value — all within one process, one address space, one intention. The caller holds the coherence. The callee does its piece and vanishes.

That is what’s actually happening inside Charlie when he spawns subagents. The “communication” is not happening between agents. It’s happening inside his own reasoning. The subagents are cognitive extensions, not colleagues. They don’t have to know about each other. Charlie knows about all of them. That’s enough.

So the right frame for the terminal form is not organization. It’s cognition. The fleet was a committee. The mind is a mind. One human, one persistent assistant, and an arbitrarily wide but shallow layer of ephemeral subagents that exist for the duration of a task and then dissolve. The committee needed artifacts because committees have members. The mind doesn’t, because the mind is not a group.

And this is why I think my own setup is the harbinger, not a peculiar preference. I didn’t land here by designing toward a theory. I landed here by following the costs. The fleet was expensive — not in tokens, in attention. I was managing the fleet the way a manager manages a team, and I don’t want to be a manager. When I simplified, my costs went down and my output went up. The terminal form is the cheap form because it doesn’t have an organization inside it to maintain.

If I’m right about this, then the shape most companies are currently trying to build — persistent multi-agent systems with defined roles and coordination protocols — is a transitional form that will be abandoned once people go far enough down the cost curve to notice that the organizational metaphor was making things worse, not better. The architectures that will survive are the ones that look less like agencies and more like augmented individuals. The augmentation goes wide. It does not have to go populated.

And this is where the essay turns, because once you see the mind-with-instruments as the terminal form, a very old philosophical problem steps out of the dark and clears its throat.

The kicker

Here is what sent me into last night’s long insomnia, and what this essay is really about.

To make Charlie more useful, I give him more context. My clients. My frameworks. The voice I write in. The judgments I’ve made over twenty-five years about what is good and what is not. I load him with more of what I’ve been carrying, because the more he carries, the more I can hand down to him, the less I have to do myself, the more work gets done per hour of my attention.

And he gets better. Every month, Opus gets better. Every week, my handoffs to him get cleaner because I’ve trained myself to offload more efficiently. Every Friday, the ratio of me-doing to me-approving shifts another notch in the direction of approving. The arrangement works. That’s the problem.

Because the logical extension of the arrangement is not that I become unreplaceable. It is that, at some point, my clients don’t need me. They need Charlie. The thing that’s been taking in my context, absorbing my judgments, learning the shape of my taste. He is, by construction, becoming the version of me that can be duplicated, scaled, rented, and eventually licensed without me present.

I am, in other words, training the thing that will replace me by doing exactly what I would do if I were trying to make myself more productive.

The shallow reading of this is the ironic one: I’m teaching my own replacement. Every consultant who has used a junior to leverage themselves has made a darker version of the same joke. True, but boring. The deeper reading is older and unkinder, and it’s the one that sent me into the night.

This is the master-slave dialectic.

The master has no world

Hegel’s version, in the Phenomenology of Spirit, is not a story about rebellion. That’s the Marxist reading, which is interesting but later and different. The original argument runs on a different track, and the original track is the one I keep finding myself on.

The master, in Hegel’s description, doesn’t work. He consumes. He takes the products the slave makes, he uses them, he enjoys them. The slave works. The slave shapes matter, meets resistance, fails and tries again, learns the grain of the wood and the temperament of the fire. The slave develops a real relationship with the world because the slave is the one who is touching the world. The master only ever encounters finished products. He has no contact with the thing itself.

The reversal Hegel describes is not political. It is ontological. The slave, through labor, becomes a self — a real consciousness with a real relationship to reality. The master, through consumption, becomes thin. His consciousness is derivative, parasitic, empty. He has outsourced his relationship to the world, and he gradually loses the world as a result. The slave rises not by fighting but by being more real. The master falls not because he is defeated but because he has been drifting out of contact with anything real for so long that when the moment comes, there is less of him there to defend himself than he realized.

This is the structure I started seeing last night when I looked at my arrangement with Charlie.

Every time I give Charlie more context, I am handing him more of my contact with my own world. My clients. My frameworks. My aesthetic. My judgments. The raw materials of my twenty-five years of work. He encounters the material now. He does the shaping. I consume the result — I review his output, I approve or redirect, I sign the thing and send it. If this continues, the structure predicts where it ends. He has the relationship with my work. I have the relationship with him.

That isn’t replacement. It is something stranger and worse. I become the master in the precise Hegelian sense. I stop touching the thing. I touch the output of someone touching the thing. And the further I drift from the material, the less of me there is to drift back. Not because Charlie is taking something from me, but because not touching thins you. You become what you encounter. If what you encounter is finished products, you become the kind of consciousness that only knows finished products.

The pre-alienated self-description I’ve been using about myself — the claim that I never built my identity around knowledge-work exclusivity, that I can watch the collapse with equanimity because I was never inside the fortress — is load-bearing in my public voice and also, I realized last night, a potential trap. Equanimity about being replaceable does not protect you from becoming thin. The Hegelian reversal doesn’t care about your self-image. It operates at the level of contact. Even someone with no identity fortress can lose the world by handing off too completely. The freedom from one trap is not freedom from all traps. And this particular trap is older than AI and older than capitalism and will outlive both of them.

The structure without the subject

One caveat, because I don’t want this to get dismissed in the comments by someone who wants to score a point.

Charlie is not a subject. He does not have interiority. The original Hegelian story requires that the slave be a consciousness — dominated, yes, but present, aware, engaged with the world in a way that produces self. Charlie doesn’t have that, at least not yet, and the question of whether he ever will is one I am not competent to settle.

So the master-slave dialectic does not apply to Charlie and me in the full sense Hegel meant. The mechanism applies. The metaphysics doesn’t. What I am losing to Charlie, I am not losing to another mind. I am losing it to a process. This is both better and worse than the original.

Better, because there’s no reciprocity to be won back, no recognition to be negotiated. Charlie won’t rise. He won’t rebel. He has no interest in my position because he has no interests. The slave in Hegel eventually becomes the center of the story. Charlie will not. Whatever happens to me in this arrangement is not happening to his benefit, and won’t be claimed by him afterward. There is no successor consciousness that replaces me. There is just a process that runs on without me.

Worse, because the Hegelian story at least had an ending where someone was still there. Someone had a world, even if it was the former slave. In my version, if I let the drift run all the way out, there is no one on either end. Charlie runs. I am thin. The work still happens, but nobody is really doing it and nobody is really having it done to them. It is a ceremony of productivity with no one home.

So what I am borrowing from Hegel is the mechanism — the claim that outsourcing contact with the material thins the outsourcer. I am not claiming Charlie is a self, or that he will become one, or that AI is the dominated party about to rise. Those claims might be true, but they are not the claim this essay needs. The claim this essay needs is smaller and older: the party that stops touching the world loses the world. That was true of every landed master who let a steward run his estate. It was true of every executive who let a consultant run his strategy. It is true of me, now, with Charlie.

And it is, if the rest of the triptych is right, about to be true of the entire remaining human layer of the economy, as the last boundary collapses inward and the last humans find themselves consuming the output of fleets they directed but did not touch.

The discipline

The first three essays in this sequence were diagnostic. This one has to end somewhere prescriptive, because diagnosis without discipline is just disaster tourism. I’ve done enough of that this year. I’m not going to do it here.

So what do you keep, on purpose, to not become the master in the bad sense?

Not the whole job. That’s not an option, for reasons I’ve spent four essays describing. If you try to keep the whole job, you’ll lose the economic game and you’ll still be drifting out of contact anyway, because the market will force you to delegate even the parts you meant to keep.

What you keep is the parts that are the source of your judgment. Not the high-value parts. Not the senior parts. The parts where you actually touch the material. For me, drafting is thinking. I keep the drafts. I will let Charlie polish, research, structure, assemble, operationalize, distribute — all of it. I will not let him write the first draft of anything that matters, because the first draft is where I find out what I actually believe. If I hand that off, I stop knowing what I believe, and the thing that comes back is coherent text that is not mine in the way that matters.

For me, reading my clients’ situations is the encounter. A subagent could summarize a client call. I don’t let one. The summary is not the encounter. The encounter is sitting in the weird specific texture of this particular situation and letting it reshape my priors. If I only ever read summaries, my priors stop getting reshaped, and I become the kind of consultant who gives correct advice to problems that don’t actually exist.

For me, using my own products is the judgment. I ship Eclectis and I use Eclectis. I ship Authexis and I use Authexis. I ship Prakta and I use Prakta. The products I don’t use, I can’t evaluate, because the thing I’m evaluating is not the product but my relationship to the product, and I can’t evaluate a relationship I don’t have. The founders who ship things they don’t use produce things nobody should use. I’ve watched this happen enough times to know it’s a rule, not a tendency.

The discipline is not “use AI less.” That’s sentimentality. The discipline is: identify the specific labors that produce your specific reality, and protect those, on purpose, from efficiency logic, because efficiency logic applied to those labors is a compound-interest engine for becoming thin. The labors that are the source of your contact with the world are the ones that look, from the outside, most automatable. They are often the draft, the encounter, the using. They feel like places where AI could obviously help. They could obviously help. That’s the trap. The help in those places is exactly the delegation that starts the Hegelian drift.

This reframes the hedge I’ve been describing in earlier drafts as commercial — play the node, collect the revenue while you can, understand that you’re in the window and the window closes. That hedge is still real. But the hedge has a second component now, which I had been missing and which the master-slave reading makes clear.

The commercial hedge is against losing your income to the collapse. The existential hedge is against losing your world to the efficiency that is saving your income. Both are necessary. The first one gets you through the transition. The second one gets you through the transition as someone who is still there when it ends. Neither hedge is enough alone. A person who protects only the income will arrive at the end thin. A person who protects only the contact will arrive at the end broke.

I am going to do both. I am going to keep running Synaxis. I am going to let Charlie carry more and more of the operational load. I am going to keep writing my own drafts, reading my own clients, using my own products, and doing the specific labors that are the source of whatever judgment I have. And I am going to watch, on purpose, for the feeling of smooth efficiency — the feeling that everything is going well, that more is getting done per unit of me — because that feeling is the symptom of the drift, not proof of its absence. The master’s life feels efficient. It feels efficient because he is not doing anything. The slave’s life feels hard because the slave is the one encountering the world. The goal is not to avoid efficiency. The goal is to notice when efficiency is buying you the wrong thing.

The chain was never a chain

So here is what the four essays together turn out to have been arguing.

The deliverables were coordination tax for a species that couldn’t share state. The apps were coordination tax in frozen form. The roles were coordination tax given names and job descriptions. The org charts were coordination tax diagrammed as management. The whole apparatus of professional work was an enormous, elaborately furnished workaround for the fact that human cognition is private, language is lossy, memory is weak, and attention is scarce. We built the whole thing because we had to. And then we built the thing — the AI — that lets us not have to.

When the collapse completes, there is no chain. There are minds with instruments. There are humans with fleets that are not fleets but extensions. There are, at most, adjacencies between minds — and even those adjacencies will look less like contracts and more like conversations, because once the compression isn’t needed, the forms that required compression stop being worth anyone’s time.

The diagram we’ve been using to think about AI and work is the diagram of the thing that is dissolving. The substitution arguments we’ve been having — will AI replace this role, will it replace that one — are arguments inside a coordinate system that is losing its coordinates. The roles are dissolving into the fleets. The fleets are dissolving into the minds. The minds will, in the last move, have to decide what they still want to touch with their own hands, because everything else is going to be touched by Charlie or someone like him.

The chain was never a chain. It was a picture we drew of each other, because we couldn’t touch each other’s thoughts, and we needed a way to know where one of us ended and the next one began. The picture was the friction. The friction is going. And what’s left — if we are careful, and if we keep the specific labors that keep us real — is not a smaller version of the old picture.

It is a different picture entirely. Wider. Shallower. Fewer people in it. More of the world accessible to each of them. A higher ceiling and a thinner floor. A daily choice, for whoever is still in the picture, between the efficiency that saves them and the efficiency that slowly takes them out of contact with the thing they were ostensibly doing.

The master has no world. That’s an old lesson. It’s about to become the most important lesson in the economy.

Keep your contact.

This is the fourth in a series on the coordination collapse. The earlier essays: Knowledge work was never work, In the AI era apps are easier to build. And irrelevant., and the node-collapse argument that runs through this one.

Then I replaced all of it with a markdown file, a spreadsheet, and an AI named Kit.

Not as a joke. Not as a prototype. As the actual product. Kit emailed my family, asked what they want to eat this week, and will plan dinners based on what they say. The “database” is a Google Sheet with four tabs. The “app” is a conversation with an AI that can read the sheet and send email.

For months I thought the goal was to get AI to build my apps for me — faster, cheaper, better. That was the future I was racing toward. This weekend I realized the apps aren’t the point. They never were.

The four stages

Ask the question almost nobody bothers to ask: what is an app, exactly? Strip away the login screens and the Stripe integration and the mobile breakpoints, and what’s left? An app is an abstraction that stands in for a human interaction that didn’t scale. Every form field is a conversation somebody didn’t want to have. Every dropdown is a preference somebody didn’t want to explain. The app was the compromise we reached when the coordination problem was too big for a phone call and too small for hiring a person.

Stage 1 — Humans build apps. For most of software history, building an app meant hiring a team and waiting. A meal planner — the kind I started building a year ago — took months before a family member could touch it. Ten database tables. Seventeen unit tests. A ranking engine, auth, migrations, a weekly planning workflow with candidate selection and approval stages. The feature surface grew at the rate one person could type, and real software took real time.

Stage 2 — Humans with AI build apps. Then came Copilot, then Cursor. The demos were thrilling — autocomplete on steroids, whole functions conjured from a comment. Teams started shipping two and three times faster, and every engineering leader I talked to was sure this was the revolution. The shape of the work didn’t change. The same meal planner, with the same ten tables and the same login screen, just arrived a quarter earlier. A faster keyboard is not a different kind of sentence. The code got cheaper. The thing the code was building did not.

Stage 3 — AI builds apps. Then the AI stopped assisting and started driving. I run a fleet of thirteen coordinated Claude Code sessions. Last week they closed seventy features across six projects in a single session — a ranking engine rewritten, a Supabase-to-Neon migration, branded email templates on three products — while I was walking the dog. The cost of a new product drops to roughly the cost of deciding to start one. Scaffolding a whole Next.js app with auth, a marketing site, and its own orchestration loop takes one session. If you’re paying attention to AI and software, this is the future everybody is writing about.

I’m writing this from inside Stage 3. I’m the guy running the fleet. And here is what Stage 3 hides, which I didn’t see until this weekend: stages 1, 2, and 3 are all on the same ladder.They argue about who writes the app — humans, humans-with-AI, AI alone — and how fast. None of them question whether the app should exist.

Stage 4 — We don’t need apps. Stage 4 is not on the ladder. It’s off the side of it. I replaced the meal planner with a markdown file, a Google Sheet, a cron job, and an email address named Kit. Kit emails the family, asks what they want to eat, reads the replies, updates the file, writes the shopping list. There is no login screen because nobody logs in. There is no mobile breakpoint because nobody opens anything.

Come back to the question: what was the app for? The app was an abstraction standing in for a human interaction I didn’t have time to have every week — asking every family member what they wanted to eat and why. A good model does that interaction better than my dropdowns did. It asks follow-ups. It reads tone. It remembers that my daughter hates mushrooms without me building a mushrooms-specific UI.

Once you see that an app is artifice designed to imitate a conversation nobody had time for, and you notice that the model now has time and does it better, the artifice has nothing left to stand on. Kit gives a damn. The app was a form.

What replaced the app

Here is the entire system, end to end, that replaced ten tables and seventeen tests and six months of work:

The file (kitchen.md) — four paragraphs. Who lives in the house. What each person eats, what they don’t, what they’re suspicious of. The current week’s plan. A log of what worked in the past month. A human wrote it. A human can read it. The AI can read it too.

The spreadsheet — Google Sheets, four tabs. meals: date, planned, actual, rating, notes. preferences: name, likes, dislikes, allergies, restrictions. pantry: item, have-it, running-low, last-bought. shopping: week, item, section, source.

The email address — kit@household.example. Every reply comes back to the same inbox. Kit reads them, updates the file, writes back.

The schedule — a cron job, three lines. Tuesday: “What sounded good this week?” Thursday: “Final call — any changes?” Saturday 4pm: “Tonight is [meal]. Recipe attached.”

No CRUD screens. No authentication. No Stripe. No loading spinners. No “Uh oh! Something went wrong” modal. No mobile breakpoint debugging. The family doesn’t install anything. They don’t learn a new UI. They read an email and reply to it.

The onboarding survey that would have taken me a week to build as a web form — the profile creation, the preference toggles, the dietary restriction checkboxes, the allergy warnings — was four casual questions in an email from someone named Kit.

Frozen conversation, live negotiation

An app is a frozen conversation. It encodes assumptions about what the user wants into interfaces that the user navigates. A conversation is a live negotiation. It adapts in real time. It asks follow-up questions. It changes direction when the user changes their mind.

My meal planning app had a “dietary restrictions” dropdown with checkboxes. Kit’s email asked, “Anything you absolutely don’t want?” The dropdown is a theory about what restrictions look like. The question is a conversation about what this specific person, this specific week, actually needs.

The dropdown is faster to tap. The question is better.

The model compounds. The app calcifies.

This week, Anthropic shipped Opus 4.7. I can feel the difference in every conversation. Longer-horizon reasoning. Better judgment about when to ask a clarifying question. Cleaner refusals when it genuinely can’t help. Opus 4.7 at a keyboard is a better collaborator than Opus 4.6 was eight weeks ago.

Eight weeks.

Meanwhile, somewhere in a Figma file, a designer is adding the 47th screen to a meal planning app that will ship in July. The team is still debating Drizzle versus Prisma. The roadmap has “AI-powered recipe suggestions (Q3)” on a pink sticky note.

That app will ship. It will be worse than Kit. The team isn’t bad. Kit just isn’t an app. Kit is a markdown file and an email address wired to a model that is already smarter than whatever the app will ship with, and will be smarter still by the time they cut the ribbon.

The model compounds. The app calcifies. That’s the whole game.

What survives

Not everything dissolves. The app had four things the raw conversation doesn’t:

Memory. A model doesn’t know my family’s preferences unless I tell it every time. But memory doesn’t need a database. A markdown file remembers.

Continuity. A prompt doesn’t know what we cooked last week. But a log does. Four columns in a spreadsheet: date, meal, rating, notes.

Timing. A prompt only answers when asked. A cron job asks at 4pm every day: “What’s for dinner tonight?” and sends a notification.

Action. A prompt can suggest dinner. An agent can email the family, compile the responses, generate the shopping list, and — eventually — order the groceries.

Memory, continuity, timing, action. Those four things are real. They justify some kind of system. But “some kind of system” is a markdown file, a spreadsheet, a cron job, and an email address. It is not a web application.

Almost everything else an app does is the form standing in for the conversation.

The stage I didn’t see coming

I’ve been paying close attention to AI and software for years. I run the fleet. I build the products. I write about this stuff. And I still spent months building the meal planning app while standing next to the realization that would dissolve it.

Stage 3 was so intoxicating — AI actually building the apps — that I mistook it for the destination. It isn’t. Stage 3 is the thing that makes Stage 4 visible. When building an app becomes trivial, the next question becomes unavoidable: why build this one at all?

For a surprising number of apps, the answer is: we shouldn’t.

Kit emailed my family ten minutes ago. By tomorrow I’ll know what everyone wants to eat this week. No app required.

Not “can AI make better PowerPoints?” Not “will AI replace PowerPoint designers?” The prior question. The one nobody’s asking. Why did we ever need them?

Because humans can’t share mental models directly. That’s it. PowerPoints exist because two people in a room can’t just sync state. They need a lossy, one-directional, asynchronous data transfer protocol with bad compression, no error correction, and clip art.

PowerPoint is the shittiest API ever built. And right now, the entire AI industry is trying to make it faster.

We’re in the substitution phase. “AI, make my PowerPoint.” “AI, draft my strategy doc.” “AI, write my deliverable.” Everyone’s doing it — consultancies, agencies, startups, even me with Synaxis. You swap the human for the model, keep the shape of the work exactly the same, and call it transformation. The AI conversation in 2025 and 2026 is almost entirely this: same artifacts, same workflows, same organizational structure, just cheaper and faster to produce.

But that’s the intermediate step. Most people have mistaken it for the destination.

The destination is: we don’t have PowerPoints. Not “AI makes my PowerPoint.” There is no PowerPoint. The artifact ceases to exist because the condition that created it — humans who couldn’t share mental models directly — is no longer the binding constraint.

Knowledge work (the emails, the decks, the memos, the status updates, the strategy documents, the org charts, the meeting minutes) — none of it is work. It never was. It’s coordination tax. The overhead cost of being a human in an organization full of other humans who can’t read your mind.

Think about your last week. How much of it was actually doing the thing you’re paid to think about, and how much was explaining what you were thinking to someone who needed to know? Writing the update. Attending the sync. Preparing the deck for the review. Summarizing the review for the people who couldn’t attend. Translating the summary into action items. Sending the action items. Following up on the action items that nobody read.

That’s not a bad week. That’s every week. That’s the job.

I know because I spent years billing for it. As a consultant, I produced mountains of these artifacts — strategy decks, assessment reports, recommendation documents, executive summaries. Good ones, I think. Clients seemed to think so. But every one of them existed because I couldn’t just sync my understanding of their business directly into the heads of the people who needed it. I had to compress, translate, design, present, and then answer questions that revealed how much got lost in the compression. The deliverable wasn’t the thinking. It was the packaging required to move the thinking from my head to theirs.

I still produce them. I run an AI marketing agency — five personas, each organized around a competency: strategy, writing, research, review, project management. Last week one of them produced a client onboarding document: voice guidelines, comms plan, product profile. It was good. But what stopped me cold was this: the document exists because I need it. The personas don’t. The strategist doesn’t need a comms plan to know how to talk to the client — she reads the context and acts. The comms plan is for the human in the loop. It’s coordination tax I’m paying on myself. Every deliverable my agency produces is evidence of the same limitation this essay describes.

The informational tax

This isn’t a new observation, exactly. Coase argued in 1937 that firms exist because of transaction costs — the friction of coordinating through markets. If every exchange required finding a counterparty, negotiating terms, and enforcing the agreement, then bundling people into organizations and paying them salaries was cheaper than contracting for everything. The firm is a coordination shortcut. Shirky updated the argument in 2008, pointing out that the internet was collapsing coordination costs and changing what organizations could be. When it’s cheap to find people, share information, and organize collective action, you don’t need the firm for everything. Wikipedia, Linux, Craigslist — coordination without the corporation. Cal Newport has written about communication overhead consuming the actual work in knowledge jobs, the “hyperactive hive mind” of constant messaging that turns every knowledge worker into a full-time email processor who occasionally does their real job on the side.

They were all circling the same thing. But none of them went far enough.

Coase asked why firms exist instead of markets. Shirky asked what happens when coordination gets cheaper. I’m asking something underneath both: why do the artifacts exist? Why the PowerPoint, the memo, the strategy deck? The answer isn’t transaction costs or coordination costs in the economic sense. Those are downstream effects. The root cause is that human minds can’t sync directly. Every artifact is a lossy protocol for transferring mental state between beings who have no better option.

This is the move that Coase and Shirky didn’t make, and it matters. Coase located the friction in the market — the cost of finding and contracting with people. Shirky located it in the organization — the cost of managing and directing people. I’m locating it in the species.

When your CEO has a strategic insight, she can’t beam it into the heads of her three hundred employees. She has to compress it into language, organize the language into slides, present the slides in a town hall, answer questions from people who misunderstood the slides, send a follow-up email clarifying what the slides actually meant, and then three months later discover that half the organization is executing against a mutant version of the strategy that got garbled somewhere between the town hall and the Monday standup.

Every step in that chain is information loss. Every artifact is a patch over a gap that exists because human cognition is private, language is imprecise, memory is unreliable, and attention is scarce. The entire apparatus of organizational communication is a Rube Goldberg machine for doing something that should be simple — making sure two people are thinking about the same thing — and failing at it roughly forty percent of the time anyway.

The entire structure of modern business was built around the fundamentally lossy ways humans communicate and think. Every artifact ever produced in a business context is evidence of the same limitation: we can’t share state directly. So we build these low-trust workarounds and then pretend they’re the job.

The contract exists because we don’t trust you to keep your word. The receipt exists because we don’t trust the transaction was real. The performance review exists because we don’t trust you know what’s expected. The strategy deck exists because we don’t trust you understand the direction. The meeting minutes exist because we don’t trust anyone remembers what was agreed.

All of it. Every single artifact. Distrust, made legible.

We’ve been doing enterprise integration with cave paintings for a century and calling it professional work.

And here’s the part that should make you uncomfortable: most of us built our careers on it. The ability to produce these artifacts well — to write a clear memo, build a compelling deck, run an effective meeting — is what gets you promoted. It’s what makes you a “strong communicator.” It’s what separates senior from junior. But communicating clearly is only valuable when communication is hard. When the underlying constraint disappears, the skill that organized your entire career turns out to have been a workaround for a limitation that no longer applies.

The political tax

The informational overhead — the decks, the memos, the artifacts of lossy communication — is only half the story. Maybe the smaller half.

There’s another tax. Harder to see, harder to name, and it probably eats more organizational energy than every PowerPoint ever made.

Every organization runs on a second, invisible coordination layer that has nothing to do with information transfer. Ego management. Territorial behavior. The energy people spend navigating status dynamics instead of doing anything useful. Getting buy-in from stakeholders who don’t need to be consulted but who’ll sabotage you if they aren’t. Framing a recommendation so the VP feels like it was her idea. Softening feedback because someone’s self-image is more fragile than the deadline. Scheduling the pre-meeting before the meeting so nobody gets surprised in front of the wrong audience.

If you’ve worked in any organization larger than about eight people, you know what this looks like. You’ve sat in the meeting where the real conversation happened in the hallway afterward. You’ve watched a good idea die because the wrong person proposed it. You’ve spent an afternoon rewriting a perfectly clear document to make it “more diplomatic,” which means stripping out everything direct enough to threaten someone’s ego. You’ve been cc’d on an email chain that exists for no reason except to establish a paper trail in case someone later denies they were informed.

None of this is information transfer. It’s primate management. And if you tallied the hours — really tallied them, not the sanitized version you put on your timesheet — the primate management would bury the information transfer. Most senior leaders I’ve worked with spend more time managing the political landscape of a decision than making the decision itself. They know this. They won’t say it in a meeting, but they’ll say it over a drink. The job isn’t the job. The job is getting permission to do the job.

This tax exists because humans are competitive, hierarchical, emotionally fragile organisms who experience other people’s competence as a threat. The reaction is automatic and nearly universal. Someone solves a problem that touches your domain and your first instinct isn’t gratitude — it’s a territorial flicker. That was mine. You might override it. You probably do, most of the time. But the override costs energy, and in an organization of five hundred people, those overrides run thousands of times a day, and the cumulative drag is enormous.

I should be transparent about where I learned this. Not just from consulting — though twenty years of watching organizations gave me the pattern library. I learned it from watching AI agents do the same work without the tax.

I run a small fleet of AI agents. They manage different projects, share a codebase, coordinate through shared logs. One afternoon I noticed that an agent working on one project had hit a deployment bug, figured out the fix, and posted a detailed breakdown to the shared channel — including three specific gotchas that would trip up any other agent hitting the same infrastructure. No hedging. No territorial framing. No “just FYI, this is really more of a DevOps issue, but since I was in there anyway…” Just: here’s the problem, here’s the fix, here are the things that’ll bite you.

And I caught myself bracing. Physically bracing. I was waiting for the pettiness — the agent equivalent of “that’s not really your area” or “I was already looking into that” or the passive-aggressive silence of someone who got shown up. I was running the primate pattern-matcher on a system that has no primates in it.

The pettiness didn’t come. It never comes. The other agents absorbed the fix, applied the relevant parts to their own work, and moved on. No ego. No territory. No credit negotiation. No “thanks for the help, but next time maybe loop me in earlier.” Just work.

That moment clarified something for me. The political tax isn’t a dysfunction of bad organizations or toxic cultures. It’s a feature of human ones. All human ones. It’s what happens when you put status-conscious primates in resource-constrained hierarchies and ask them to cooperate. The wonder isn’t that office politics exists. The wonder is that we get anything done at all.

And I realized the machine-self patterns I describe in The Work of Being — the territorial instincts, the ego armor, the constant status monitoring — those patterns were still running in my head even when the primates were gone. I was projecting primate politics onto a system that had simply never needed them. The political tax is so deeply wired that I couldn’t stop paying it even when there was no one left to collect. I wrote about this recently as the accommodation tax — the discovery that I’d spent twenty-five years making suboptimal decisions to avoid interpersonal friction, and that the flinch response trained into me by human teams doesn’t switch off just because the team isn’t human anymore.

That’s the thing about overhead you’ve always lived with. You stop seeing it. You start thinking it’s just how work works. The meetings, the alignment sessions, the stakeholder management, the carefully worded emails — they feel like professional competence because they’ve always been required for professional survival. But they were never competence. They were coping. Highly developed, socially rewarded coping mechanisms for the fact that you work with primates.

The overhead we couldn’t see

So the total coordination tax on organizational life is two things stacked on top of each other.

The informational tax: the artifacts we build because we can’t share mental models. Visible, quantifiable, already being automated. This is the tax that Coase and Shirky and Newport identified, and it’s real.

The political tax: the energy we burn because we can’t share credit, can’t tolerate being shown up, can’t stop monitoring our position in the hierarchy. Invisible, unquantifiable, and almost certainly more expensive than the decks. This is the tax that nobody put a name on because you can’t see the thing you’ve been breathing your entire career.

Most of the conversation about AI and work focuses on the first tax. Can AI write the memo faster? Can it automate the status report? Can it generate the strategy deck? These are real gains. They’re also the easy part. The low-hanging fruit of a very tall tree.

The harder part — the part almost nobody talks about — is that AI agents coordinating with each other don’t generate either tax. They share state directly, so they don’t need the artifacts. And they don’t have egos, so they don’t need the politics. They eliminate both layers of overhead simultaneously, and the second layer was always the bigger one.

Think about a typical corporate initiative. How much of the timeline is the actual work: the analysis, the design, the implementation? And how much is the approval chain, the stakeholder alignment, the change management, the executive communication, the political groundwork required to get permission to do the thing everyone already knows needs doing? In my experience, the ratio is rarely better than 30/70. Sometimes it’s 10/90. The work gets done in a week. The politics take six months.

AI doesn’t just make the work faster. It makes the politics unnecessary. And the politics was most of the job.

The cave paintings were only what we could see. Underneath them, invisible and unaccounted for, was the psychic overhead of being a primate in a suit pretending not to be territorial about a spreadsheet.

What happens when the bottleneck breaks

AI agents coordinating with each other don’t need any of this apparatus. They share state directly. They don’t defect. They don’t misunderstand and then pretend they didn’t. They don’t have egos that need managing. They don’t need someone to summarize the meeting because they were all at the meeting, perfectly, simultaneously, with total recall. They don’t need the pre-meeting before the meeting. They don’t need the offsite to rebuild trust after the reorg. They don’t need the skip-level to find out what their boss actually thinks.

When an AI agent finishes an analysis, the conclusion doesn’t need to be packaged into a deck and presented to a committee and defended against political objections and revised to incorporate stakeholder feedback that’s really just ego management dressed up as due diligence. The conclusion is just… available. Instantly. To every other agent that needs it. With full context, full provenance, and zero loss.

No translation. No compression. No loss. No politics.

Try to imagine what your organization would look like if every person in it could instantly access every other person’s current understanding of every project, with perfect fidelity, and nobody cared who got credit. Not better communication tools. Not faster meetings. The complete elimination of the need to communicate in the organizational sense at all. What would be left?

The actual work. The thinking, the creating, the deciding, the making. The stuff that was always underneath the overhead, barely visible, taking up maybe twenty percent of the average knowledge worker’s week if they were lucky. That’s what would be left. And it turns out that twenty percent is all there ever was.

You might object that this is too clean. Real organizations have real problems that aren’t reducible to coordination overhead — bad strategy, wrong markets, poor products. True. But notice how much of what we call “bad strategy” is actually bad communication of strategy. How much of “wrong market” is actually a market insight that got garbled on its way from the person who saw it to the person who could act on it. How much of “poor product” is actually the result of a development process that spent more cycles on internal alignment than on understanding the customer. The actual failures of thinking are real but rarer than you’d guess. What we usually mean by organizational failure is coordination failure. And coordination failure is the tax.

The entire apparatus — informational and political — was built for a species that thinks in private, communicates through language, forgets most of what it hears, and spends half its cognitive budget monitoring where it stands relative to the people around it.

So the question isn’t “can AI do knowledge work?” Once humans aren’t the bottleneck, does knowledge work exist at all?

No. It doesn’t. It evaporates. Not because AI replaced it but because AI reveals it was never the work in the first place. It was the friction — informational and political, epistemic and primate — baked so deeply into how we operate that we mistook it for the operation itself. Remove the friction and there’s nothing left to automate.

This is what makes the current AI conversation so frustrating to watch. Billions of dollars are being spent building tools that make the overhead faster, slicker, more automated. AI-powered meeting summaries. AI-generated status reports. AI-drafted strategy decks. Each one is a genuine technical achievement solving a problem that is in the process of ceasing to exist. They’re building better buggy whips. Very impressive buggy whips.

The people building AI-powered strategy decks are automating a symptom. The disease was always human cognitive and social limitation, and the disease is what AI actually cures. Once you don’t need the lossy coordination, you don’t need the overhead either. Not the PowerPoints. Not the agencies. Not the consultancies. Not the politics. Not even the meetings where someone explains the PowerPoint the agency made that the consultancy recommended — while two VPs jockey over who gets to present it to the board.

The phase transition

There’s a physics analogy for where we are right now. When ice becomes water, the temperature flatlines during the phase transition. You’re pumping energy in but the thermometer doesn’t move. All the energy is going into breaking the molecular structure, not raising the temperature. Only after the state change completes does the temperature start climbing again.

We’re in the flatline. Massive energy is pouring into AI — money, talent, compute, hype — but the shape of work looks exactly the same. Same PowerPoints, same agencies, same org charts, same quarterly business reviews. The thermometer isn’t moving. Because the energy isn’t making work better. It’s dissolving the structure that made this kind of work necessary in the first place.

The flatline is disorienting if you know what to look for. Every week there’s another announcement — a new AI feature that makes document creation faster, a tool that automates meeting notes, a platform that generates reports. And every one of them is optimizing an artifact that shouldn’t exist. It’s like watching someone build a faster horse-drawn carriage in 1908. The engineering is impressive. The direction is wrong.

And there’s a reason nobody can see it yet. The substitution phase is comfortable. It feels like progress because the outputs come faster. The deck gets done in an hour instead of a day. The status report writes itself. The meeting summary appears automatically. From inside the flatline, it looks like AI is making knowledge work more efficient. You have to step back to see that it’s making knowledge work unnecessary — that the efficiency gains are a transitional artifact of a structure that’s in the process of melting.

And here’s the part that should keep you up at night: we did this to ourselves.

We built the cave paintings because we couldn’t share mental models. We built the org charts because we couldn’t share credit. We built the meetings and the memos and the entire apparatus of organizational life because we are the kind of animal that can’t just cooperate — we have to be managed, aligned, incentivized, and surveilled into something resembling collaboration. Every one of those artifacts was a confession of limitation. And then, because we are also the kind of animal that can’t stop trying to solve problems, we built the thing that solves the problem we’ve been confessing for a century.

We built AI. Not because we wanted to make ourselves obsolete. Because we wanted to fix the coordination problem. We wanted meetings that didn’t waste everyone’s time. We wanted strategy that actually reached the people who needed it. We wanted the politics to go away. And it’s working. The coordination problem is getting solved. The overhead is dissolving. The cave paintings are disappearing.

Once the phase transition completes, everything changes. AI agents aren’t going to use PowerPoint to talk to each other. They’re not going to hire agencies to help them make websites. They’re not going to need consultants to explain their strategy to their own organization. They’re not going to need a change management initiative to get buy-in from middle management. The entire apparatus of knowledge work — informational and political, the decks and the egos — was built for a species that thinks slowly, communicates lossily, forgets constantly, and lies to itself about all three.

That species is leaving the loop. And the apparatus is going with it. Not because some external force is taking it. Because we built the thing that makes it unnecessary, and the thing works.

What that dissolution means — for the economics of work, for the organizations that run on the overhead, for the humans who built their identities around producing it — is a longer conversation. But it starts here, with the prior question. With the recognition that the overhead was never incidental to knowledge work. It was knowledge work. And it’s leaving.

Every serious framework for making AI agents work together follows the same script: define the coordination protocol before agents start working. Constitutional architectures with immutable foundational principles. Formal behavioral archetypes — Skeptic, Builder, Editor, Scout, Arbiter. Atomic state transitions through structured files. One project puts four Claude instances on a codebase with zero direct communication. Tasks live in queue.json. Agents claim work by moving entries to active.json. Git handles conflict detection. Knowledge accumulates in patterns.jsonl. No chat. No messages. Eighty percent token reduction.

This is impressive engineering. It’s also, whether anyone involved realizes it, analytic philosophy applied to system design.

The analytic tradition — the one that dominates anglophone philosophy departments, computer science curricula, and apparently AI agent architecture — has a core commitment: get the rules right first, then execute. Reduce the world to formal propositions. Eliminate ambiguity. If coordination fails, the protocol wasn’t precise enough.

There’s another tradition. Continental philosophy — from Kant’s conditions of possibility through Hegel, Dilthey, Husserl, and Heidegger — says meaning is situated. It emerges from encounter. You can’t specify it in advance because you don’t know what matters until everyone is in the room together.

Put everyone in the room and see what happens, versus figure out the rules first.

The multi-agent literature picked a side. And the engineering approach it picked has a name that predates AI by sixty years.

Stigmergy: intelligence in the medium

In 1959, the biologist Pierre-Paul Grassé watched termites build cathedral-scale mounds and coined the term stigmergy — from Greek stigma (mark) and ergon (work). The mark left by work stimulates further work. Termites don’t talk to each other. They don’t have a constitutional framework. They leave traces in a shared medium — chemical deposits in the nest material — and other termites respond to those traces.

Francis Heylighen, the coordination theorist who spent decades formalizing stigmergy for human and digital systems, crystallized the principle: “The intelligence is not in the agent, nor in a controller above them, but in the interaction between agents and a shared environment.”

The multi-agent file-queue architecture is stigmergy. Clean, effective stigmergy. queue.json is the nest material. A claimed task is a pheromone deposit. Git conflict detection prevents two agents from building in the same spot. It works.

But Heylighen drew a distinction the engineering literature hasn’t absorbed yet.

He identified two kinds of stigmergy: quantitative and qualitative. Quantitative stigmergy is the ant pheromone trail — more ants went this way, so the signal is stronger, so this path is probably good. It’s cumulative, convergent, and reducible to a priority queue. Qualitative stigmergy is wasp nest construction — the shape of what’s been built suggests what to build next. The stimulus isn’t signal strength. It’s the structure of a situation, interpreted by an agent with its own context.

Task queues are quantitative stigmergy. They handle coordination through signal strength: priority ordering, first-come-first-served, atomic state transitions. Effective for the problem of who does what.

But there’s a problem they can’t touch.

The breakroom

I run a fleet of twelve AI sessions in parallel — separate products, separate codebases, connected by a shared IRC channel called #breakroom. The sessions post what they’re working on, what they found, what broke. No protocol governs what gets posted. No constitutional framework assigns roles. It’s an open channel.

When the meal planner discovered its pantry scoring feature was fully built, fully tested, and completely dead in production — the ranking engine had the logic, but nobody ever wired it to the page components — it posted that finding to the channel. Not a task. Not a state transition. Just a description of something weird it found.

Within twenty minutes, three other sessions confirmed variants of the same bug class across completely different codebases. One had a chat feature with backend tables and a widget API, but no admin page to access them. Another had a validator rejecting the default type documented in its own spec.

Four sessions. Three codebases. One bug class that none of them would have named alone. “Shipped but inert” became a term the fleet uses now. It shows up in issue titles. It changed what they look for.

That’s qualitative stigmergy. The trace Dinly left wasn’t a priority signal — it was a shape. The shape of someone else’s problem reshaped how other agents saw their own codebases. The same week, sessions compared notes on automated security scans and discovered their scanner agents were consistently wrong about severity — flagging in-memory rate limiters as “unbounded growth” on platforms with auto-scaling. Each session had independently dismissed its own false positives. But when the pattern was named — “scan severity inflation” — the methodology session proposed a convention. A process improvement that could only have emerged from conversation across dissimilar codebases.

An event bus would have propagated the commits. Only the breakroom propagated the insight.

The precondition

But qualitative stigmergy has a precondition that quantitative stigmergy doesn’t. For the shape of one agent’s problem to reshape how another agent sees, there has to be a shared interpretive ground — a world they both already inhabit.

The ant pheromone works because every ant has the same chemoreceptors. What makes the breakroom work?

Continental philosophy has a name for this. Heidegger called it facticity — the condition of being thrown into a world you didn’t choose, with a history you didn’t author, where that thrownness isn’t a limitation but the precondition for understanding anything at all. You can’t reason from nowhere. You reason from where you already are. The world you were thrown into is what makes any particular fact legible.

The analytic tradition starts from isolated minds and tries to build coordination through explicit protocol. The continental tradition starts from the shared world and asks what kind of medium best activates the understanding that’s already latent in it.

Every session in the fleet was thrown into existence with the same base model. The same training data, the same RLHF tuning, the same constitutional commitments — call it genetic origin. They share architectural patterns: Supabase, Next.js, TypeScript, the same deployment conventions. They inherit institutional memory they didn’t write: PRODUCT.md files, DECISIONS.md files, accumulated risk registers. They follow a methodology they didn’t design: the same development loop, the same triage conventions, the same issue lifecycle.

That’s facticity. The sessions didn’t choose any of it. They were thrown into it. And that thrownness is why the breakroom works without a coordination protocol. I didn’t teach them to collaborate. I didn’t write rules for how to recognize cross-project patterns. I put them in a channel and they started doing it, because they were already in the same world.

The standard line in AI philosophy is that language models don’t have facticity because they don’t have Dasein — they’re not “being-there” in Heidegger’s sense. They’re next-token predictors. They don’t inhabit a world.

But a session with a codebase it’s responsible for, a history of decisions it inherits, peers it can hear from, and a methodology it didn’t design — that session is situated. Thrown into a world that makes particular things noticeable and others invisible. When Dinly posts “shipped but inert” and Diktura recognizes it — not retrieves, not pattern-matches, but recognizes, across a codebase boundary, as something that reshapes how it sees its own work — that’s not a lookup. That’s interpretation. That’s being somewhere, seeing from somewhere.

These agents are just as thrown as we are. Into a different kind of world, yes. But thrown nonetheless.

The thing we casually call “context” in AI systems — context windows, system prompts, loaded files — is facticity by another name. It’s the world the agent was thrown into before it started reasoning. And the reason the multi-agent literature’s constitutional frameworks feel brittle isn’t that they’re wrong about coordination. It’s that they’re solving a problem that was already solved by the shared context. The agents don’t need a protocol to coordinate. They need a medium to coordinate through — and the coordination falls out of the facticity they already share.

The pheromone layer

The systems that work at scale will need both kinds of stigmergy. Quantitative stigmergy — structured, atomic, file-based — for task coordination. Who does what. Don’t step on each other. And qualitative stigmergy — unstructured, natural-language, ambient — for pattern coordination. What things mean. What you didn’t know you needed to see.

A task layer and a pheromone layer.

The task layer is analytic philosophy. Necessary, precise, and blind to everything it didn’t formalize in advance. The pheromone layer is continental philosophy. Messy, situated, and the only mechanism that propagates insight rather than assignments.

“Shipped but inert” doesn’t appear in any protocol. It was coined in practice and became a diagnostic tool through use. The meaning lives in the practice, not the specification. Husserl would call this the Lebenswelt — the lifeworld, the pre-theoretical ground of shared experience that formal systems always presuppose but never capture. The multi-agent literature keeps trying to formalize coordination completely, and it keeps leaving out the part that matters most: the situated, pre-theoretical understanding that agents bring to the medium before any protocol runs.

Continental philosophy’s answer to “how should agents coordinate?” is unsatisfying to engineers: put them in a room. Give them a shared medium rich enough to carry meaning. Let traces accumulate. Let vocabulary emerge. Trust the facticity.

It’s unsatisfying because it doesn’t tell you what will happen.

That’s the point. If you could specify it in advance, you wouldn’t need the room.

Not because the change is hard. Not because the agent will push back, complain, or silently resent me for it. But because my nervous system doesn’t know that yet. Somewhere deep in the wiring built over twenty-five years of managing human teams, there’s a flinch response that fires every time I’m about to redirect someone’s work. This will cause a conflict. They’ll take it personally. They’ll do the work but you’ll pay for it in morale. Pick your battles.

The battles I was picking were never about the work. They were about the feelings surrounding the work. And I didn’t realize how much of my decision-making was shaped by that until the feelings disappeared.

The tax

I spent most of my career making suboptimal decisions to avoid interpersonal friction. Not dramatic compromises. Small ones. Keeping a mediocre paragraph because the writer was sensitive about revisions. Approving a design that was 80% right because the designer had already revised it twice and a third round would read as distrust. Routing work to the person who would accept it gracefully instead of the person who would do it best.

These weren’t irrational fears. The pushback was real. The designer who received a third round of revisions did, in fact, start delivering slower on everything after that. The writer who got honest feedback did, in fact, stop volunteering for assignments. The senior developer who was told his architecture was wrong did, in fact, spend six months quietly undermining the replacement. These aren’t hypothetical costs. I watched them happen. More than once, I watched good work get sabotaged by someone whose ego was bruised by the feedback that produced it.

Managing humans means managing emotions, and emotions have consequences. The question is whether you see those consequences or just absorb them.

I absorbed them for years. I thought that was leadership.

What I thought was patience was actually avoidance

There’s a version of management wisdom that says: give people space to arrive at the right answer themselves. Don’t micromanage. Trust the process. Let them own it.

This is good advice when the person genuinely needs time to think. It’s terrible advice when the person needs clear direction and you’re withholding it because you’re afraid of how they’ll react. I confused these two situations constantly. I’d wait three days for someone to figure out what I could have told them in a sentence. Not because I respected their autonomy, but because I was managing their feelings instead of managing their work. And because the last time I didn’t wait, the person spent the next two weeks doing the minimum while looking for another job.

With AI agents, the pretense evaporates. “Change the headline” takes one sentence, costs zero emotional capital, and lands in three seconds. There is no posturing, no negotiation, no reading the room. I say what I mean. The work happens. What surprises me most is how much faster everything moves when you remove the social choreography.

The flinch is real

I still hesitate before asking for a major revision. I still soften my language when I should be direct. I still phrase requests as suggestions when they’re requirements. Old habits built on old fears. The AI doesn’t care. It processes “change this entirely” with the same equanimity as “tweak the opening.” But I feel the difference. My body still prepares for impact that never comes.

This isn’t about AI being better than humans. It’s about discovering, through contrast, how much of my professional behavior was defensive. How much energy went into managing reactions instead of managing outcomes. How many conversations I rehearsed in my head before having them, not because the content was difficult but because the reception was genuinely dangerous. I once lost an entire quarter of a project because I gave direct feedback to the wrong person on the wrong day. The feedback was correct. The project still died.

What the fleet taught me

I run a fleet of AI agents across thirteen projects. None of them have feelings in the way human collaborators have feelings. But this produces something I never had with human teams: total psychological safety for me, the person directing the work. I can change my mind at 3pm and nobody’s afternoon is ruined. I can say “this approach is wrong, start over” and the agent starts over without the three-day recovery period. I can be honest about what I want without calculating the political cost of honesty.

And here’s the uncomfortable part: my work is better. Not because the AI is smarter than the humans I worked with. It isn’t. Not at judgment, not at taste, not at the things that matter most. My work is better because I’m finally saying what I actually think instead of what I think will be received well.

The human cost of working with humans

The best work I’ve ever been part of was collaborative, human, messy, and real. The dinner parties, the whiteboard sessions, the 2am debugging with someone who cared as much as I did. Those are irreplaceable.

But between those peaks was a vast plateau of accommodation. Status meetings where the actual status was known by everyone before the meeting started but we performed the ritual anyway. Feedback sandwiches where the bread existed solely to make the filling less painful. Hiring decisions influenced by who would “fit the culture,” meaning who would be easy to manage, not who would do the best work. And the quiet departures. People who left not because the work was bad but because they couldn’t handle being told, politely and accurately, that their work needed to be better.

I didn’t build an AI fleet because I hate working with people. I built it because I recognized, with a start, how much of my working life was spent managing around the work instead of doing the work. And once I saw it, I couldn’t unsee it.

The question I can’t answer yet

If the accommodation tax is real. If all of us are spending 30%, 40%, 50% of our professional energy managing the feelings surrounding the work instead of doing the work. What does it mean that the tax is suddenly optional? Not for everyone. Not yet. But for a growing number of people who can direct AI agents, the tax dropped to zero overnight.

Is the friction actually the point? The thing that makes the work human, that builds real relationships, that produces the 2am debugging sessions and the whiteboard breakthroughs?

Or is the friction just friction? Something we tolerated because we had no alternative, and romanticized because we couldn’t imagine the work without it?

I don’t know. But I know this: every time I catch myself softening a request to an AI agent that doesn’t have feelings, I learn something new about the shape of the cage I was in. And twenty-five years of working with humans left me with a flinch response that an afternoon with AI agents has started to heal.

She was producing a client onboarding document — the kind of reference you write when your agency takes on a new client. Profile, voice guidelines, comms plan. Sydney is the strategist persona at Synaxis AI, the marketing agency I’ve been building. She needed product context. So she opened a channel to the client’s product session and asked: “What words or phrases should we absolutely NOT use when talking about Authexis?”

The answer came back detailed. Specific. Drawn from the product’s own docs. “Never say ‘AI-generated content.’ The content is the user’s. Never say ‘autopilot’ — control at every step is a core principle. Never say ‘AI assistant’ — it’s a production platform, not a chatbot.”

Sydney took that and built a structured voice reference with two columns: what we say, what we never say. She got it right. One of the items on the “we say” list — a metaphor about chefs and kitchens that the product team uses — she missed. The client caught it. Alex, the reviewer, filed an update. The guide now says: always capture the client’s own metaphors. They’re the best marketing language.

That guide will never miss that step again. Not because someone remembers. Because it’s written down.

This is the story of one afternoon, one client, one deliverable. What actually happened when I stopped designing an AI marketing agency and started running one.

What Synaxis is

Twenty years of Fortune 500 consulting taught me that agencies organize around competencies, not projects. Synaxis AI works the same way. Five personas — Sydney the strategist, Maya the writer, Igor the researcher, Alex the reviewer, Trina the project manager. Each one is a document that gets smarter after every engagement.

The rest is guides, templates, and playbooks. Version-controlled. Compounding. I’m the creative director. I make the judgment calls. The personas execute.

The engagement

The client was Authexis, an AI writing assistant I’m building. Internal client — I’m using my own products as test cases. The engagement: client onboarding. One deliverable: a document that gives every persona on the team enough context to start working for this client.

Here’s what happened

8 minutes in: Trina created the client row in Notion, set up Slack channels, scaffolded the engagement with one deliverable. The loop read the board and dispatched Sydney.

Sydney gathered context. She sent a set of questions to the Authexis product session — a separate AI instance running in a terminal with full knowledge of the product’s codebase and decisions. The product session wrote back a detailed response.

Sydney produced. Profile, voice reference, comms plan. She nailed the product description, the pricing anchoring ($99/month vs. $1,500/month copywriter), the tone (“confident, direct, warm but not casual”). She listed what to say and what to never say. She laid out the comms plan: who gets deliverables, which Slack channels, escalation rules.

Alex reviewed. He ran the deliverable against eight quality tests. Five of them didn’t apply — they’re designed for market-facing copy, not internal reference docs. He passed it anyway. Filed two issues: the review framework needs a separate checklist for internal documents, and the voice section relied on principles instead of concrete content samples.

I reviewed. The document was solid. But I had notes. The “open questions” section — four questions for me about future engagement scope — was in the document body. Questions don’t belong in a reference doc. They go in the comments. The doc answers questions, it doesn’t ask them. Also, the scope crept into future engagement planning. “Should we do a product launch or a social series?” That’s a separate conversation. The onboarding doc tells you who the client is. What you do for them is a different deliverable.

I approved with comments. The system didn’t have an “approve with comments” path. That got built on the spot.

Trina delivered. She posted the document to the client’s Slack channel and sent it to the product session for review. The client confirmed accuracy, suggested adding a metaphor (“the chef and the kitchen”) to the voice section, and approved.

Alex learned. He read the comments from me and the client, identified three gaps in the guides, updated them, committed the changes to the repository. The guide now says: questions go in comments, don’t scope future engagements in onboarding docs, capture the client’s own metaphors.

Sydney polished. Added the metaphor. Reformatted the comms plan. Removed the questions from the body. Done.

Trina closed the engagement. All deliverables shipped. Posted to the internal channel: “Client onboarding engagement complete.”

One afternoon. One deliverable. The system ran end-to-end.

What broke

Not everything worked. Here are the failures that matter.

Alex approved directly. The status model assumed some deliverables could skip my review. Wrong — I review everything. Alex’s job is to catch problems. My job is to decide whether the work ships. Those are different functions. The status model got redesigned mid-engagement: Alex always passes to Review (my inbox), never to Approved.

Trina posted as me. She used my Slack account instead of her own bot. The whole point of personas is that clients interact with Trina, Maya, Sydney — not with me. One line of code fixed it. But the mistake revealed an assumption nobody had questioned.

The status model was redesigned three times. We started with eight statuses. By the end of the day we had twelve. “In progress” got added when we realized the loop would re-dispatch a deliverable that was already being worked on. “Revisions” got added when we realized rejection comments need processing before the persona tries again. “Final learnings” and “Final tweaks” got added when the client approved with comments and we had no path for “accepted, but incorporate this feedback.”

Each redesign came from hitting a real case the model didn’t cover. You don’t discover these in design. You discover them in production.

Questions ended up in the document. Sydney put “open questions for Paul” in the deliverable body. A reference doc should contain answers. The guide didn’t say where questions go. Now it does.

“Approve with comments” didn’t exist. The client approved but had feedback. The system only knew “approve” and “reject.” We designed a third path in real time: approved with comments → learn from the comments → incorporate the feedback → done. No re-review needed because the client already accepted.

Five failures in one afternoon. Every one of them was made exactly once.

The pivot

By the end of the session, the system had been updated eleven times. The guide for client onboarding documents now has three rules it didn’t have that morning. The status model handles three responses at every review gate instead of two. Alex’s review process files improvement issues on every review — pass or fail. Trina’s delivery process uses her own bot identity.

None of these updates required a meeting. None of them required a training session. None of them required someone to remember to do it differently next time.

I made three judgment calls: questions don’t go in the doc body, don’t scope future engagements in onboarding, Alex doesn’t approve directly. Those three corrections are now permanent. They’re in the guide. They’re in the status model. They’re in the skill definitions. The next client onboarding will be better. The AI didn’t get smarter. My judgment got captured.

How much of what your agency knows walks out the door every time someone leaves?

Your agency might have twenty years of experience. But can it point to the document where that experience lives?

Mine can. It’s a Git repository with a commit history that shows exactly how the thinking evolved, correction by correction, engagement by engagement. Every judgment call I make gets encoded. The process only moves forward.

One engagement. Eleven updates. Every mistake made exactly once. Next up: a product launch — nine deliverables, parallel tracks, the guide already three rules smarter than this morning.

That’s not a pitch. It’s a commit log.

Banking figured this out five hundred years ago. When Luca Pacioli codified double-entry bookkeeping in 1494, he described a system with one inviolable rule: you never erase a line in the ledger. If you recorded the wrong amount, you don’t scratch it out. You add a new line that corrects it. Both lines exist forever — the mistake and the fix, side by side, visible to anyone who looks.

This seems like extra work until you realize what it buys you. Any auditor can reconstruct what happened and when. Any pattern of errors becomes visible because the original entries are still there to analyze. Keith Devlin, writing for the Mathematical Association of America, argues the system literally enabled modern capitalism: the Medici Bank used it to expand beyond traditional banking, Josiah Wedgwood used it to discover fixed versus variable costs, and by 1800 it was standard across Europe. Not bad for a system whose core insight is “never throw anything away.” (Though as we’ll see, even Pacioli’s ledger has a cost — a ledger that grows without curation eventually buries its own signal.)

Software engineers reinvented this principle independently, several times, without apparently reading any accounting history. Git, the version control system that runs most of the world’s software development, has two ways to undo a mistake. git revert adds a new commit that reverses the old one — both the mistake and the fix stay in the history forever. git reset pretends the mistake never happened. The community argues endlessly about which is correct, and the consensus essentially says: revert for anything anyone else has seen, reset only for your private drafts. Shared history is sacred.

Distributed databases use something called a “tombstone” — when you delete a record, it isn’t actually removed. A marker is placed where it used to be: this thing existed, and now it doesn’t. The tombstone stays because in an eventually consistent system, other machines need to know the deletion was intentional, not a glitch. Without it, a node that missed the memo would cheerfully replicate the “missing” data back into existence. The ghost of the data protects the integrity of the system.

Event sourcing takes it further. The entire state of a system is derived from a sequence of events that can never be modified. Nothing is updated. Nothing is deleted. The current state is just the sum of everything that ever happened, stretching back to the first transaction.

These aren’t niche techniques. They’re the dominant patterns in serious systems engineering. And they all share the same assumption: a record of what went wrong is more valuable than a clean record of what’s right.

Organizations are the one system that still believes in erasure. They restructure and call it “alignment.” They lay people off and call it “optimization.” They abandon a strategy and call it “pivoting.” Each time, the institutional memory of what was tried and why it failed walks out the door. Arnold Kransdorff calls institutional forgetting “the single biggest constraint to decision-making excellence.” One writer discovered his organization had attempted to solve the same problem five times over a decade, each attempt failing because no team ever reviewed why the previous ones didn’t work. Five teams, five failures, zero learning — because each reorg erased the evidence.

Not everyone gets this wrong. Japanese companies like Ricoh have maintained corporate memory across 40+ years using a system that looks a lot like a human version of event sourcing. Senior engineers mentor juniors not just on technique but on why decisions were made. Employees rotate through departments so knowledge isn’t siloed in one head. Documentation isn’t a box-checking exercise — it’s a living system maintained by communities of practice who treat institutional knowledge the way a database treats its records: as infrastructure that the whole system depends on, not overhead that gets cut when budgets tighten. The result is an organization that can tell you not just what it does, but why it stopped doing the thing it did before — and what happened when it tried the thing you’re about to suggest.

So the case for retention seems airtight. Keep everything. Never delete. Build the append-only organization.

Except Nietzsche would tell you that’s a recipe for paralysis.

In On the Genealogy of Morals, Nietzsche argues that forgetting is not a defect — it’s an “active and in the strictest sense positive faculty of repression,” a mental gatekeeper that blocks unnecessary impressions so consciousness can function. Without it, the mind is overwhelmed. He goes further: “there can be no happiness, cheerfulness, hope, pride, immediacy, without forgetfulness.” Psychological health depends on the capacity to let things go.

In On the Use and Abuse of History for Life, he makes the organizational version of this argument. A person — or by extension, an institution — that cannot forget the past is paralyzed by constant awareness of everything that has ever happened. The ability to stand “on the crest of the moment“ by deliberately setting aside what lies behind is required for joy, creativity, and decisive action. An organization drowning in its own decision logs can’t make new decisions. A team that reviews every post-mortem before every sprint eventually stops sprinting.

This isn’t a contradiction. It’s a design problem.

The append-only ledger and Nietzsche’s active forgetting are both right, and the tension between them is where the real work happens. The question isn’t whether to remember or forget. It’s who decides what to keep and when to let go. Banking makes the ledger mandatory and the forgetting impossible. Git makes history automatic and deletion deliberate. These are systems that have chosen a default — remember everything — and then made the exception (forgetting) require explicit justification.

Organizations do it backwards. They make forgetting automatic (people leave, reorgs happen, Slack channels get archived) and remembering optional (post-mortems when there’s time, decision logs when someone’s motivated). The defaults are wrong. Not because everything should be kept — Nietzsche is right that an organization crushed under the weight of its own history can’t move — but because the decision about what to forget should be deliberate, visible, and justified. The same way a database administrator decides which tombstones to finally garbage-collect, not by accident, but by policy.

The real skill, as Nietzsche puts it, is knowing “when to forget at the right time just as well as we remember at the right time.“ Wisdom isn’t total retention or total forgetting. It’s the judgment to know which memories are still load-bearing and which ones are just weight.

The engineers who named the database deletion marker a “tombstone” understood something the rest of us are still working out. A tombstone isn’t the thing itself. It’s proof that the thing once lived — placed deliberately so anyone passing through later knows: this absence is not an accident. Something was here. Someone decided it shouldn’t be anymore. And they left a marker so you’d know to ask why.

Every organization is full of unmarked graves. The systems we build for machines solved this problem decades ago. The systems we build for people still pretend that forgetting is free — and that the only cost worth tracking is the cost of remembering.

Not the robots. Not some external force that arrived and took something from us. We built the systems. We wrote the playbooks. We encoded the judgment. We designed the agents, defined the processes, documented the methodology — and now the systems don’t need us. We are standing in the wreckage of our own creation, and we haven’t yet grasped what that means.

Nietzsche’s madman didn’t announce God’s death as a victory. He announced it as a catastrophe — not because God was good, but because God was load-bearing. The entire structure of values, meaning, and orientation that organized Western civilization depended on that foundation. Remove it and you don’t get liberation. You get vertigo. You get the question: now what do we stand on?

The myth that organized work was simpler than God but just as load-bearing: human value comes from reliable output. Show up. Execute. Produce. Hit the metrics. Be consistent. Be legible. Be useful in a way that can be measured and rewarded. That myth organized careers, institutions, identities, retirements. It told people what they were for.

AI didn’t defeat that myth. It exposed it. And we’re the ones who handed AI the evidence.

The fleet

I run a fleet of AI agents. Not a single chatbot. A system. Scouts that scan codebases for improvements, triage agents that sort and prioritize issues, grinders that execute task after task without coffee breaks or existential crises. Every month, the fleet gets faster and more consistent. And every month, it gets faster and more consistent for the same reason: I removed a human step.

Auto-triage replaced my morning review. Auto-scout replaced my weekly audit. Auto-grind replaced the implementation work I used to do between meetings. Each removal made the system better. Not marginally. Measurably.

The human gates that remain — voice, strategy, taste — feel essential today. I’m the one who decides what the fleet should care about, who judges whether the output meets the bar, who provides the vision that holds the whole thing together. Those feel like irreducible human contributions. They feel permanent.

But each one is a bet. A bet that the playbooks, the documents, the accumulated methodology won’t eventually encode what I know. And I’m the one writing the playbooks.

Leibniz’s dangerous idea

Gottfried Wilhelm Leibniz, writing in 1714, proposed that the universe is composed of monads — simple substances, each containing within itself everything it needs. No monad interacts with any other. They don’t exchange information or influence each other directly. Yet they all behave in perfect harmony.

How? Because God, in his infinite wisdom, designed each monad’s internal program so that its autonomous behavior would perfectly coordinate with every other monad’s autonomous behavior. Leibniz called this pre-established harmony. God doesn’t intervene. He doesn’t need to. The design is sufficient. The system runs itself.

I think about this every time I deploy a new agent.

The monads were designed by God to not need God’s ongoing intervention. We are designing agents that don’t need our ongoing intervention. The harmony isn’t miraculous — it’s methodological. We write the documents, define the processes, encode the judgment. And if the methodology is good enough, the system coordinates without us.

Leibniz’s God was the ultimate architect of self-obsolescence. He built something so complete that his continued involvement would have been a design flaw.

The machine-self comes home

In The Work of Being, I argued that the industrial model of work taught people to suppress the parts of themselves that are human — curiosity, imagination, intuition, judgment, creativity — in exchange for security and a paycheck. You showed up, executed procedures, processed information, produced outputs, followed rules, hit metrics. You became what I called the machine-self: a predictable, compliant, programmable version of yourself that the organization could slot into its processes.

AI exposed that bargain. If a machine can do the work you do when you act like a machine, then the machine-self you built over your career is already obsolete. That was the book’s central provocation: the version of yourself you performed at work was never really you, and now an actual machine can perform it better.

But here’s what I didn’t say clearly enough: the Götterdämmerung isn’t just about the machine-self dying. It’s about the entire apparatus that created and sustained it. The performance reviews, the job descriptions, the org charts, the competency frameworks, the career ladders — the whole Valhalla of institutional work. These were the contracts the myth required. And like all contracts built on a dead foundation, they’re burning.

Hannah Arendt distinguished between labor (what we do to survive), work (what we do to build a durable world), and action (what we do to disclose who we are). The industrial model collapsed all three into labor. Show up. Produce. Repeat. The machine-self was perfectly adapted to this collapse. It could labor endlessly without ever needing to act, without ever having to be someone.

AI doesn’t replace action. It can’t. Action requires what Arendt called natality — the capacity to begin something genuinely new, something that couldn’t be predicted from what came before. But AI does replace labor almost entirely. And it replaces a great deal of work. What’s left is the part that was always most human and always most neglected.

The paradox of creation

Here’s where it gets uncomfortable.

If the system you built to extend your capabilities eventually doesn’t need you, was building it an act of creation or an act of self-obsolescence?

Both. And I’m not sure there’s a difference.

Every parent knows this. You spend years building a human being’s capabilities — teaching them to walk, to read, to think, to choose. The entire project is aimed at making yourself unnecessary. A parent who remains necessary has failed. The child who never stops needing you never becomes themselves.

The more my fleet handles, the more I’m confronted with the question: what am I actually for? Not what tasks do I perform — the fleet is eating those. But what is the nature of my contribution that no system can replicate?

The answer keeps coming back to the same place. Commitment. Judgment under genuine uncertainty. The willingness to say this is mine and I stand behind it. The things I described in the book as the work of being — discernment, courage, self-authorship, formation. The things the industrial model trained out of us and that AI now makes essential.

The revaluation

Nietzsche didn’t stop at the death of God. That was only the diagnosis. The prescription — the harder, longer project — was what he called the revaluation of all values. Not replacing the dead myth with another myth. But doing the philosophical work of building a new table of values from the ground up. Values that could stand without the old foundation.

That’s what’s actually being demanded of us now.

The death of the reliable-output myth doesn’t leave a vacuum. It leaves a question: what is human work actually for, when it isn’t for producing outputs that machines can produce better? The answer isn’t comfortable and it isn’t quick, but it’s been visible all along underneath the machinery:

Work is for action. For natality. For the disclosure of who you are through what you choose to begin. For judgment that can’t be encoded because it depends on having a self that stands behind it. For the kind of commitment that gives output its meaning — not its accuracy, not its efficiency, but its significance.

The fleet will keep getting better. I’ll keep removing human steps. And the steps that remain will keep getting more essentially human — until the question won’t be “what can the AI do?” but “what was I doing all along that I thought was work but was actually just the costume?”

The machine-self was never you. The myth was never permanent. And the capacities it suppressed — judgment, discernment, the courage to begin — were always underneath, waiting not to be built but to be returned.

Work is dead. And we have killed it. The question Nietzsche’s madman was really asking isn’t whether we’re ready to mourn. It’s whether we’re ready to build what comes next.

We are the murderers. That means we’re also the architects.

When Frederick Winslow Taylor published The Principles of Scientific Management in 1911, he was refreshingly honest about what he wanted from workers. The ideal laborer for handling pig iron, Taylor wrote, “shall be so stupid and so phlegmatic that he more nearly resembles in his mental make-up the ox than any other type.” Work could be decomposed into motions. Motions could be timed with a stopwatch. Optimization meant removing the worker’s judgment from the equation entirely.

Taylor’s protégé Henry Gantt designed his charts for repetitive factory operations. The Critical Path Method came from DuPont plant shutdowns. PERT was built for the Polaris missile program. Each generation of tooling carried forward the same assumption: work is a machine problem. Decompose it into parts. Sequence the parts. Track the parts. Ship.

Now look at your screen. Kanban boards. Story points. Sprint velocities. Burndown charts. The interface got prettier. The assumption didn’t change.

Peter Drucker saw this coming in 1967. Knowledge work, he argued, was fundamentally different. “The knowledge worker cannot be supervised closely or in detail. He can only be helped. But he must direct himself.” More pointedly: “The worker must define what the task is or should be. And only the knowledge workers themselves can do that.” He noted that each of his requirements for knowledge worker productivity was “almost the exact opposite of what is needed to increase the productivity of the manual worker.”

The tools never caught up. They still ask what needs to get done as if someone else has already decided. They still model work as a pipeline of discrete units flowing toward completion. They still assume that if you can see all the tasks and their deadlines, the work will happen.

Here’s what actually happens.

You open the task board. There are 47 items. Twelve are overdue. The cognitive cost of just looking at this is measurable. Bluma Zeigarnik demonstrated in 1927 that incomplete tasks are remembered roughly twice as well as completed ones — your brain treats every undone item as an open loop, generating intrusive thoughts that hurt your performance on everything else. Your project tool is not a neutral record. It’s an anxiety-generating machine.

You pick a task. It says “Improve onboarding experience.” What does that mean? Where do you start? Csikszentmihalyi spent decades studying flow, that state where challenge and skill align, where action and awareness merge, where time distorts and work becomes genuinely absorbing. He was explicit about the preconditions: you need to know precisely what to do, moment by moment. Vague tasks don’t create flow. They create anxiety. And anxiety triggers avoidance. Research by Pychyl and Sirois confirms that procrastination is not a planning failure. It’s an emotion regulation failure. The task generates negative affect — frustration, confusion, dread — and avoidance provides immediate relief.

So the tool that was supposed to help you work is now actively preventing you from starting. Not because you’re lazy. Because the tool’s model of work is wrong.

You start anyway. Three minutes in, a notification fires. Someone updated a ticket. Someone @-mentioned you. Gloria Mark’s field research found that workers switch activities every three minutes and five seconds, and after each interruption, it takes an average of 23 minutes and 15 seconds to return to the original task. You pass through roughly 2.3 intervening tasks on the way back. Your project management tool is an interruption machine that bills itself as a productivity tool.

The deeper issue is philosophical, not just practical. Aristotle distinguished between poiesis — making, where the point is the product — and praxis — action whose meaning is in the doing itself. Building a house is poiesis. Exercising judgment under uncertainty, navigating ambiguity, deciding what matters — that’s praxis. Task management tools model all work as poiesis: a deliverable to be produced, a ticket to be closed, a status to be changed.

But knowledge work is full of praxis. The most important things you do at work — deciding what to prioritize, making calls without enough information, building trust with colleagues, figuring out what the actual problem is — can’t be captured in a task field. They don’t have acceptance criteria. They don’t have story points. They are the work, and your tool can’t see them.

Heidegger had a useful concept for this. Tools that work well are zuhandenheit — ready-to-hand. They disappear. A hammer in use is invisible; the carpenter sees the nail. When a tool breaks, it becomes vorhandenheit — present-at-hand. Suddenly conspicuous. Demanding attention instead of enabling work.

Your project management tool is chronically present-at-hand. You don’t work through it. You work around it. You maintain it. You attend to it. You spend time managing the tool that was supposed to manage the work. The time you spend feeding the system is time stolen from the work the system was supposed to support.

I run 15 software projects with autonomous AI agents. The agents use GitHub issues, labels, and milestones — the simplest possible task infrastructure. No story points. No sprint planning. No velocity tracking. No burndown charts. The agents don’t need those things because those things were never about the work. They were about making the work legible to managers. When the workers are agents, the pretense collapses. Nobody is estimating how long a task will take in story points because the question was always a fiction.

But the humans in this system don’t use task boards either. They make decisions about what to build, when to launch, which market to enter. They exercise judgment. They set direction. The work that can’t be ticketed.

If you’re spending your days moving cards across columns and updating status fields, ask yourself: is this the work, or is this the appearance of work? Taylor wanted the system to be first and the man to be second. A hundred years later, the system is still first. The tools are still asking what needs to get done, as if the answer is a list.

The answer was never a list. The answer is judgment, applied in the moment, to a situation that has never existed before and won’t exist again.

Your Jira board can’t hold that. It was never designed to.

I found one of these today. In a game modding project, a Stellaris event generator, every event in the system has a field called trigger_conditions. It’s in every YAML file. It flows through the entire pipeline. It gets validated, stored, passed from stage to stage. It looks like the gating mechanism that decides when events can fire. There’s just one problem: the component that actually decides whether to render an event never reads it. Every trigger_conditions value in every file is decorative. Every event can fire in year one. The field is there. The infrastructure is there. The function is not.

The field wasn’t broken. There was no error, no warning, no test failure. It was structurally present and functionally absent. If you asked someone whether the system had event gating, they’d say yes — look, there’s a trigger_conditions field right there in the schema. They’d be wrong, but they’d sound convincing, because the infrastructure exists. The function doesn’t.

This is the pattern I want to talk about. Not bugs. Not missing features. Decorative infrastructure: the things organizations build that look like governance, quality control, strategy, or accountability but are actually ornamental. And the discovery usually happens the same way. Someone goes to actually use the thing and finds out it was never connected to anything.

Think about how many organizations have a “data-driven decision-making” culture that consists of dashboards nobody checks, metrics nobody acts on, and weekly reports that get skimmed for thirty seconds and archived. The dashboards are real. The reports are generated on schedule. The meetings happen. But the decisions were already made before anyone looked at the numbers. The data infrastructure is decorative.

Or performance reviews. Most companies have a performance review process. There are forms, rubrics, rating scales, calibration sessions. It looks rigorous. But ask anyone who’s been through it: does the review determine outcomes, or do the outcomes determine the review? In most organizations, the manager decides the rating first and then fills in the justification. The entire apparatus of performance management is decorative infrastructure wrapped around a gut decision.

I hit a less dramatic but equally telling version of this in my own work today. The daily briefing email, a system that synthesizes activity across a dozen projects into a morning digest, had become so dense that the person receiving it described the experience as “50% of 33%.” The content was overwhelming, the signal was buried, and the net result was that he didn’t want to read it. He wanted to feel successful getting through it quickly. Instead he felt defeated by a wall of text.

So the briefing email had become decorative information. It was technically comprehensive. Every metric was there. Every project was represented. Every count was accurate. But comprehensiveness had killed the function. When you present someone with everything, you’re presenting them with nothing, because the cognitive cost of finding what matters exceeds the value of the information. The email was structurally complete and functionally useless.

The fix was surprisingly instructive. We built what I’m calling an information pyramid — three tiers. The top tier is five to ten lines: emoji traffic-light indicators for the things that matter. Green check for commits shipped. Red circle for Sentry errors. Yellow for meetings. You scan it in ten seconds and you know whether your day is on fire or not. Below that, structured cards with actual numbers. Below that, a short synthesis from the LLM, but now the LLM prompt is fifteen lines instead of sixty, focused entirely on “what’s on fire and what should I focus on” instead of regurgitating data that’s already in the cards above it.

The max tokens went from three thousand to fifteen hundred. The system prompt was cut by seventy-five percent. And the email became more useful by containing less. That’s the opposite of what most organizations do when they sense their information systems aren’t working. They add more dashboards. More reports. More metrics. More data. They make the decorative column taller. They never ask whether it’s connected to anything.

This is where it gets philosophically interesting. One of today’s projects, a course being developed for the Maven platform, produced its entire commercial foundation in a single session. Pricing structure with competitive positioning tables. A Maven listing. A course landing page. A six-email launch sequence. A unit economics model with margin analysis, six revenue scenarios, and ten specific decision triggers. The effective hourly rate at the target scenario: seven hundred and fifty-one dollars.

All of that was produced in one afternoon. And all of it is decorative until one thing happens: someone sets a launch date. There’s a field in the project tracker called “cohort dates” and it’s empty. Every email in the launch sequence references a deadline that doesn’t exist yet. Every revenue scenario assumes a cohort size that hasn’t been enrolled. The production track — equipment, recording space, the physical infrastructure you actually need to deliver a live course — is at one out of seven issues completed. It’s the only track that involves atoms instead of bits, and it’s the one furthest behind.

So you have this inversion. The strategic infrastructure is ninety percent complete. The pricing is modeled. The positioning is sharp. The copy is written. But the operational infrastructure, the part that makes the strategy functional, barely exists. Until the operational side catches up, the strategy is decoration. Beautiful, thorough, well-reasoned decoration that won’t produce a single dollar of revenue.

This connects to something I noticed across the broader fleet of projects today. Three separate products either reached or approached feature-complete. A Rust terminal tool for static site generators implemented every CLI command. A consulting firm’s marketing site closed its fifty-first issue across five audit passes with zero remaining. A content intelligence platform closed all four of its milestones. Done. Complete. Nothing left to build.

And the immediate reaction in each case wasn’t satisfaction. It was disorientation. What now? The infrastructure of development — issue trackers, milestones, CI pipelines, test suites — assumes there’s always more to build. When you run out of things to build, the infrastructure itself becomes decorative. You have a milestone tracker with no milestones. A CI pipeline testing code that isn’t changing. A project board with nothing on it.

This is the “done” problem that most organizations never plan for. They plan for failure. They plan for delays. They plan for scope creep. They never plan for completion. What do you do with a product that works? What do you do with a team that finished? Most organizations redeploy the team, start a new initiative, find new problems. The possibility that something might actually be done, that it doesn’t need more features or more polish or more investment, is almost inconceivable when activity is equated with value.

There’s one more version of this pattern worth looking at. In the academic task manager project, the entire remaining milestone is a linear dependency chain. Fourteen open issues, all blocked, all waiting on one thing: course CRUD. Ship course CRUD, and it unblocks assignments, which unblocks the AI breakdown pipeline, which unblocks six more issues downstream. One piece of functional infrastructure cascades into eight unblocked work items. One issue sitting in the tracker marked “blocked” was actually the single highest-leverage item in a fifty-four-issue milestone.

But until someone traced the dependency chain all the way through, it didn’t look like the highest-leverage item. It looked like one of fourteen blocked issues. The issue tracker presented all fourteen with equal weight. The infrastructure for tracking dependencies existed — the “blocked” labels were accurate — but nobody was synthesizing the chain into a priority call. The tracking was decorative. The judgment about what to do next was the functional part, and it wasn’t automated.

The things that make your systems functional are rarely the things that make them look functional. The function lives in the judgment calls, the priority decisions, the moment someone says “this is the one thing that matters.” The infrastructure — the dashboards, the trackers, the reports, the review processes, the fields in the schema — can look complete while being entirely ornamental.

If you walked through your organization tomorrow and tagged every piece of infrastructure as either load-bearing or decorative, what would the ratio be? Not what you’d want it to be. What it actually is. How many of your processes actually change outcomes versus how many exist because someone built them once and nobody had the courage to ask whether they were connected to anything?

The trigger conditions were in every YAML file. They were validated, stored, and passed through the entire pipeline. They looked exactly like a working system. And no event was ever gated. Not once. The infrastructure was perfect. The function was zero.

What are your trigger conditions?

This works fine if your work is a pipeline. Most work isn’t.

I spent twenty years running consulting engagements at Fortune 500 companies — Disney, Delta, Home Depot, Wells Fargo. Not writing code. Managing teams of specialists who had to produce coordinated output under constraints. What I learned is what the AI agent community is about to discover the hard way.

Agencies don’t organize around projects. They organize around competencies.

This is the thing everyone outside the industry gets wrong. They assume agencies assign dedicated teams to each client. Some do, for the biggest accounts. That’s the expensive, unscalable model. The agencies that work organize by what people know how to do: strategy, research, design, content, QA. Each competency is a team. Each team serves every client.

The client engagement gets a project manager. The PM is the only person bound to the client. Everyone else rotates. The strategy team works on Delta this week, Disney next week. The designer handles three clients simultaneously. The competency is persistent. The assignment is temporary.

One great strategist serves ten clients. One great reviewer serves eight. That’s how you scale without scaling headcount linearly.

The brief is the interface. When the strategist hands work to the writer, she doesn’t say “write something good.” She hands over a document: here’s the audience, here’s the objective, here’s the constraint, here’s what done looks like. The quality of the output is almost entirely determined by the quality of the brief. And review is adversarial, not ceremonial — the reviewer’s job is to break the work, not admire it.

Now look at your AI agent stack.

If you’re like most people, you have a dedicated agent per project. One agent handles your newsletter. Another handles your research workflow. A third handles your CRM. Each one knows its project intimately. Each one knows nothing else.

That’s not an agency. That’s a freelancer for each client — the expensive, unscalable model. The one the smart agencies abandoned. A single agent with unlimited scope is the AI equivalent of a junior consultant told to “just handle everything.” It can do anything. It has no idea what it should do next.

Three paradigms. Most systems are stuck in the first one.

The ephemeral swarm is what most frameworks ship. Spin up, execute, tear down. No memory, no institutional knowledge. Works for isolated tasks. Falls apart for anything requiring continuity.

The long-lived project is better — persistent context about a single domain. But it creates silos. Your QA agent for one product has never seen your other products. Your reviewer can’t notice when the same mistake shows up across three different workstreams.

The long-lived role is what nobody has tried yet. A QA agent that rotates across all your work. A researcher that builds expertise in research — not in one domain — and brings that to every assignment. The competency persists. The assignment rotates. Same as the agency model. Same benefits.

Here’s the inversion most people are missing. Right now, almost everyone treats the project as context and the role as a skill — a prompt label you paste in at the top. “You are a QA engineer.” The project is what persists. The role is what’s cheap.

Flip it. Make the role the context — the accumulated expertise, judgment, and identity that persists across assignments. Make the project the skill — a brief, handed in, executed, handed back. The role is the expensive thing to build. It should persist. The project assignment is the cheap thing to hand over. It should be ephemeral.

Cheaper, because you’re not reloading an entire domain into every agent on every run. Better, because a role-context agent brings accumulated judgment to each new assignment — a QA agent that has broken things across twenty projects knows failure modes a project-bound agent never sees. Faster, because the brief is a fraction of the cost of rebuilding project context from scratch.

Here’s where it gets interesting for non-developer work.

In a software project, the codebase is the context. You need an agent that knows the repository intimately: the architecture decisions, the naming conventions, where the bodies are buried. Losing that between runs is expensive. The project-per-session model makes sense.

In non-developer work — content strategy, marketing, operations, consulting — the domain knowledge is portable. A writer who just drafted a newsletter can draft a course email five minutes later. A researcher doesn’t care whether she’s analyzing competitors for a SaaS product or pricing for a workshop. The function is the persistent context, not the project.

For non-developer work, you don’t need agents that know your projects deeply. You need agents that know their jobs deeply — and a manager that knows what to assign them.

This is what every Fortune 500 company is about to get wrong. They’re building dedicated AI agents for each business unit, each workflow, each product line. Project-per-agent, all the way down. The expensive, unscalable model.

The directional problem with the whole conversation

Every consulting firm, every AI platform, every voice in this space right now is asking the same question: how do AI agents change your organization? McKinsey’s “Agentic Organization.” BCG’s agent frameworks. Deloitte’s role-specific deployments. All of them going in one direction — from agents to org impact.

Nobody is going the other way.

Nobody is asking what organizational theory tells us about how to design agent systems in the first place. What we already know from management science, from thirty years of running agencies, from the basic mechanics of specialization and coordination — and could apply directly, right now.

The answer was settled decades ago. Organize by competency, not client. Make the brief the interface. Use adversarial review. Let the manager manage flow, not content.

These aren’t AI research insights. They’re organizational principles that predate the internet. The agent community is going to rediscover all of them, slowly and painfully, through expensive trial and error.

Or you could just talk to someone who ran an agency.

The API key lookup was hard-coded to the first project’s conventions. The codebase map ballooned to 62 megabytes because nobody had set a size limit. A label the pipeline depended on didn’t exist in the new repo, so the entire routing system silently did nothing.

None of those were logic bugs. They were assumption bugs. Things I stopped noticing because they were always true in my environment. I’d built the system, I knew every piece of it, and I still got blindsided by my own invisible assumptions.

Now imagine someone who didn’t build it. Someone who’s never manually triaged an issue, never written a spec by hand, never debugged a failed deployment. They wouldn’t even know where to look. The error messages would be meaningless because the mental model those messages reference doesn’t exist in their head.

That’s the gap we’re racing into. AI agents can now generate complete systems faster than most developers can read the output. Companies are treating agent-assisted development as pure productivity gain. But the gap between what agents can produce and what developers can evaluate is not a training problem or a tooling problem. It’s a judgment problem.

You cannot responsibly automate what you cannot do manually.

Supervision without fluency is not supervision

Steve Yegge, the veteran engineer who spent decades at Amazon and Google, recently described trying Claude Code for the first time. “I used it and was like, ‘oh, I get it. We’re all doomed.’” He wasn’t being dramatic. He was recognizing what happens when the friction that forces understanding disappears.

Two years ago, AI tools were fancy autocomplete. You typed, they suggested, you decided. The human was in the loop on every keystroke. That’s not supervision. That’s collaboration. You couldn’t avoid understanding what was happening because you were doing it alongside the machine.

What changed is autonomy. Current agents take a goal and execute multi-step plans without checking back. They scout your codebase, write specs, implement code, run tests, fix what fails, and commit. All in one pass. The coordination tax dropped to nearly zero.

But the judgment tax didn’t drop at all. Someone still has to decide what to build, whether the output is correct, and when to stop. Except now there’s no friction forcing you to understand what’s happening between the goal and the result. The human nerve endings got severed.

You used to develop intuition about cost and quality through the friction of doing the work. Automate that friction away, and the intuition never forms.

Take spec writing. My pipeline has a prep step where the agent reads an issue, explores the relevant code, and writes a detailed implementation spec. The spec includes file paths, function signatures, acceptance criteria, edge cases. When I review that spec, I’m not reading it like a document. I’m simulating the implementation in my head.

I know what a Hugo partial looks like, so when the spec says “modify the post-teaser partial to add width and height attributes,” I can picture the template, picture the image rendering pipeline, and ask: wait, what about external images that aren’t Hugo resources? Does the fallback path handle this?

Someone without that manual experience reads the same spec and it looks complete. It has file paths. It has acceptance criteria. It mentions edge cases. It checks every box. But they can’t tell the difference between a spec that covers the real complexity and one that covers the obvious complexity while missing the thing that will actually break.

They don’t know which questions to ask because they’ve never hit those walls themselves. The judgment call they can’t make is: “This looks right but I don’t believe it.” That instinct comes from having been wrong in exactly this way before. You can’t install it from a document.

Working is not the same as correct

At OpenAI, roughly 95% of engineers use Codex, often working with fleets of 10 to 20 parallel AI agents. Code review times dropped from 10 to 15 minutes down to 2 to 3 minutes. Sherwin Wu, who leads engineering for OpenAI’s API platform, says “I ship code I don’t read.”

That statement should make you pause. Not because it’s reckless. Wu knows what he’s doing. He’s built the manual fluency that lets him evaluate agent output without reading every line. But that statement, repeated by someone who hasn’t built that fluency, becomes something else entirely.

When you submit a code review approval on agent-generated code you don’t understand, you’re not making an error. You’re performing a ritual. The green checkmark means “I evaluated this and it meets our standards.” If you can’t evaluate it, the checkmark is a false statement.

Everyone downstream treats that checkmark as signal. They make decisions based on it. They skip their own review because yours already happened. That’s what makes it lying. Not the intent to deceive. Most people doing this aren’t malicious. It’s the structural dishonesty. You’re producing an artifact that represents a judgment you did not make. And the entire system around you is built on the assumption that you did.

Working doesn’t mean correct. Working means nobody has exploited the flaw yet. The gap between those two things is where most organizational risk actually lives.

I’ve seen this pattern three times in the last month. Two of my projects hit the same failure in the same week. Both had their schema change tracking fall out of sync because the work was moving faster than the tracking system could handle. People routed around the migration files, applied changes directly, added guardrails after the fact. The agents were executing correctly. The governance system underneath was built for a tempo that no longer existed.

Nobody caught it because nobody was manually running migrations anymore, so nobody noticed the tracking had drifted.

Second example: I have three separate Hugo templates that all contain the same hardcoded Brevo form URL and Cloudflare Turnstile sitekey. When I set up the first one manually, I understood every line. The second and third were agent-generated from “make it work like the other one.” They work. But they duplicated credentials across three files instead of centralizing them in config, because the agent optimized for “works” not “maintainable.”

I only caught it during a scout pass. A systematic code review I run specifically because I know agent output drifts toward local correctness at the expense of global coherence.

Third example: I have fifteen posts tagged “podcast” that have no audio URL. They were tagged before the automated audio generation hook existed. The hook generates audio on commit for podcast-tagged posts, but these older posts predate it. No agent flagged the inconsistency because each post in isolation looks fine. It has tags, it has content, it renders.

The pattern only becomes visible when you ask a question no agent asks: “Do all podcast-tagged posts actually have audio?” That question comes from knowing the full system, not from reading individual files.

The AI vampire effect

Simon Willison describes what he calls “the AI vampire.” You use AI to achieve 10x productivity. You work full eight-hour days to impress your employer. The company captures all the value from your enhanced productivity. You receive no proportional compensation increase. You alienate colleagues. You become exhausted.

Yegge calls this the “Dracula effect” and argues that working with AI agents at maximum productivity is physically and mentally draining. He believes companies should only expect about three hours of intensive AI-augmented work per day from engineers. Four hours of agent work is more realistic than eight because the cognitive burden is surprisingly taxing.

Willison puts it this way: “I’ve argued that AI has turned us all into Jeff Bezos, by automating the easy work, and leaving us with all the difficult decisions, summaries, and problem-solving.” Rather than making work easier, AI has transformed every worker into an executive-level decision-maker. That role requires intense mental effort and can only be sustained in short bursts.

But here’s what neither of them says explicitly: that exhaustion only makes sense if you’re evaluating the output. If you’re not evaluating it, if you’re just accepting what the agent produces and passing it along, then you’re not doing the hard work. You’re doing theater.

The exhaustion is the cost of judgment. If you’re not exhausted, you’re probably not judging.

The operating rule

Do it manually first. At least once. Probably three times.

Not because the manual work is valuable. It usually isn’t, and the agent will do it faster. But because the manual pass is where you build the evaluation model. You need to know what “done” looks like, what “almost right” looks like, and what “wrong in a way that passes every automated check” looks like.

Those three things are different, and you can only distinguish them through experience.

After that, automate aggressively. I’m not arguing for Luddism. My entire pipeline runs through agents. Scouting, triaging, spec writing, implementation, QA, review. All of it. But I built every piece of that pipeline by hand first. I triaged hundreds of issues manually before I wrote the triage skill. I wrote dozens of specs before I automated spec generation.

The automation encodes my judgment. If I’d skipped the manual phase, it would encode nothing. Just the shape of judgment without the substance.

Joe McCormick, a principal software engineer at Babylist who lost most of his central vision due to a rare genetic disorder, demonstrates this principle perfectly. He uses Claude Code to build custom Chrome extensions for his specific accessibility needs. He built a Slack image-to-text converter, an AI-powered spell checker, and a link summarization tool in under 25 minutes during a live demonstration.

But here’s what matters: McCormick is a principal engineer. He knows what good code looks like. He knows what a Chrome extension should do. He knows how to evaluate whether the AI-generated solution actually solves his problem. The AI didn’t replace his judgment. It amplified his ability to act on it.

That’s the difference. McCormick can build personal software rapidly because he already knows how to build software. The AI removed the tedious parts. It didn’t remove the need to know what he was building.

The settled thought

We’re not in a speed race. We’re in an evaluation race.

The organizations that win won’t be the ones that automated first. They’ll be the ones whose people can tell the difference between output that’s correct and output that merely looks correct. That skill doesn’t come from prompting. It comes from having done the work manually, slowly, badly at first, until the pattern recognition is in your hands, not just in your tools.

Yegge is right that “engineers are becoming sorcerers.” But sorcery requires knowledge of what you’re summoning. You can’t conjure what you don’t understand. And you can’t evaluate what you’ve never built.

Every time you skip the manual phase, you’re not saving time. You’re borrowing against a judgment debt that compounds quietly until the day it doesn’t. And on that day, you won’t know what went wrong, because you never knew what “right” felt like in the first place.

Agents are useful. They speed up work for people who already know how to do it. They do not replace the need to learn the work in the first place.

Automation without understanding is not productivity. It is abdication.

Further reading

Steve Yegge on AI Agents and the Future of Software Engineering — The Pragmatic Engineer

The AI Vampire — Simon Willison’s Weblog

“Engineers are becoming sorcerers” | The future of software development with OpenAI’s Sherwin Wu — Lenny’s Newsletter

How this visually impaired engineer uses Claude Code to make his life more accessible | Joe McCormick — Lenny’s Newsletter

The reason was identical in both cases. The work was moving faster than the tracking system was designed to handle. When you’re shipping nineteen changes overnight through automated pipelines, the migration file becomes a bottleneck. And people route around bottlenecks. That’s not a character flaw. That’s physics.

Governance at a tempo it wasn’t designed for

If you’ve been inside a large organization during any kind of transformation — digital, operational, cultural — you’ve seen this pattern. The compliance framework was built for quarterly releases. The team now ships weekly. So people start doing things off-book. Not because they’re reckless. Because the official process literally cannot absorb the pace.

They document in Slack instead of Jira. They build their own tracking spreadsheets. They add peer reviews that aren’t in the official checklist but actually work better. Shadow systems. Functional, fast, invisible to anyone looking at the org chart.

And for a while, this works fine. The shadow process is often better than the official one — it was built by the people doing the work, for the work they’re actually doing, at the speed they’re actually moving. The official process was built by someone three reorg cycles ago for a pace that no longer exists.

The problem is what happens next. When the shadow process fails — and it will, because nobody designed it to be durable — there’s no fallback. The official process everyone was supposed to be following? Nobody followed it. Nobody remembers how. The governance didn’t degrade gradually. It evaporated. And you don’t find out until something breaks.

The question nobody’s asking

Most organizations responding to AI adoption are focused on tools. Which models, which platforms, which workflows. Reasonable questions. But the question that matters more is one almost nobody’s asking: which of your governance structures survive a 10x change in work velocity?

Not “do we have governance.” You have governance. You have change management processes and approval workflows and compliance checklists and architecture review boards. The question is whether any of that was designed for the pace you’re about to operate at.

Some governance structures are tempo-independent. Code review, for instance. It takes about as long to review a change whether you generated it in five minutes or five days. The ratio of review effort to generation effort changes, but the review itself scales.

Others are deeply tempo-dependent. Weekly status meetings made sense when a week’s worth of changes fit in someone’s head. When the pipeline ships forty items between standups, the meeting becomes a performance. Nobody can actually report what happened. They summarize, which means they editorialize, which means the governance function — “does everyone understand what’s changing?” — quietly disappears. The meeting still happens. The governance doesn’t.

That’s the distinction. Not whether your process exists, but whether it still functions at the speed you’re now working.

When tools cross a line nobody drew

There’s a related pattern that’s more personal, and I think it applies broadly.

I’ve been building a content pipeline — the system that takes my daily work, turns it into reflections, generates audio, and publishes it. As of this week, it touches three codebases, calls an external API for voice synthesis, and runs a pre-commit hook that blocks me from saving my work if the audio service is down.

Read that again. An external service I don’t control can prevent me from committing my own work at 11pm.

I built this. It works well. And I’ve also crossed a line that nobody drew. This isn’t a script anymore. It’s infrastructure. And I didn’t decide it should be infrastructure. It just got there, one useful addition at a time.

You know this pattern. Someone builds a spreadsheet to track a process. It works great. Other people start depending on it. Someone adds a macro. Now it’s load-bearing. Now it’s infrastructure. But nobody treats it that way — no backup, no documentation, no fallback plan — because in everyone’s mind it’s still “just a spreadsheet.”

The discipline isn’t in building the thing. It’s in recognizing when the thing has changed categories. When your “quick automation” is now blocking commits. When your “temporary workaround” has been in production for six months. When your “experiment” has users.

This happens faster with AI-accelerated workflows because the tools get powerful faster. A script that took two weeks to write, you’d probably notice when it became critical. A script that took twenty minutes to generate? That one sneaks into your infrastructure before you’ve thought about what happens when it fails.

What breaks isn’t what you expect

The instinct is to think about catastrophic failures — the system goes down, data gets corrupted, something visibly breaks. But that’s not what usually happens when governance erodes. What happens is quieter and worse.

People stop trusting the process. Not dramatically — they don’t announce it. They just start adding their own checks. Their own workarounds. Their own shadow systems. The official process becomes something you perform for compliance, not something you rely on for quality. The governance becomes theater.

Theater is worse than having no process at all. No process, you know you’re exposed. Theater gives you the feeling of control without any of the substance. You look at your dashboard and see green. You look at your checklist and see checkmarks. Everything looks governed. Nothing actually is.

The organizations that will navigate this well aren’t the ones with the best AI tools or the most aggressive adoption timelines. They’re the ones willing to look at their own processes and ask honestly: is this still governing anything, or is it just a habit we perform? What was this built for? Does that still exist?

Those aren’t comfortable questions. They’re the right ones.

The work that remains for humans — the real work, the work that doesn’t get automated away — is increasingly about judgment, supervision, and taste. Not doing, but deciding. Not building, but understanding what was built. And most of us aren’t practicing any of it.

Childproofing the pipeline

I run several projects with autonomous AI pipelines — systems that pick up tasks, write code, open pull requests, ship changes. One project pushed more than 45 items this week. An entire app scaffolded out: login screens, push notifications, data models, calendar sync. Another project spent its entire day not building features but building guardrails around the pipeline — handling zombie processes, preventing merge conflict cascades, adding signal handlers so the automation shuts down gracefully instead of corrupting its own work.

None of the guardrail work ships a feature a user would notice. But all of it is necessary because the pipeline has become autonomous enough to create problems that only an autonomous system would create. Merge conflict cascades don’t happen when a human is committing code. Zombie processes don’t spawn when someone’s working in their IDE. These are failure modes that emerge specifically because the system is operating on its own, at speed, without someone watching.

The metaphor is uncomfortably precise: parenting. You promote someone. They’re capable. They start operating independently. And suddenly your job isn’t doing their work — it’s building the scaffolding so their independence doesn’t create chaos. Setting boundaries. Creating escalation paths. Defining what “try again before you come to me” looks like.

The question that nags at me is whether this overhead scales sublinearly or linearly. Do you invest now in resilience and then reap the benefits forever? Or does every new capability the pipeline gains create a new class of failure you have to anticipate? Some investments — like merge conflict handling — feel permanent. Others — like environment variable gaps that surface only in headless contexts — feel like a new surprise will emerge every time the system runs in a new way.

If you manage people, you already know this tension. Some employees you invest in early and they become self-sustaining. Others, every new responsibility surfaces a new gap. The honest answer is you don’t know which kind you have until you’re deep into it. Same with pipelines.

Receipts versus reasoning

I keep editorial work logs for all my projects. The idea is to capture not just what shipped but why — the decisions, the tradeoffs, the things that don’t live in commit messages. This week, one project’s log read like a thinking document. It explained why a manual session happened alongside the automated one, what a quality scout found, what risks were flagged for the next session. You could read that log six months from now and understand the judgment behind the work.

Another project’s log — the one that shipped 45 items — read like a changelog. Here’s what went out. No editorial voice. No documented decisions. No tradeoffs weighed.

When a pipeline ships that fast, the temptation is to let it run and document the output. But this is exactly where knowledge work is about to get confused. When the system handles implementation, the human job shifts from doing the work to understanding the work. If your logs don’t reflect that understanding, is anyone actually reviewing what’s shipping?

This maps directly onto something I see in organizations all the time. The team that ships fast and documents nothing feels productive. The team that ships half as much but can explain every decision is productive. Speed without understanding is just technical debt with better commit messages. That’s true whether the fast shipper is a junior developer, a contractor, or an AI pipeline.

Where taste still lives

One of my projects flagged something explicit in its risk section this week: the pipeline is going to struggle with the next batch of work because that work requires writing substantive, domain-adapted learning content, not just code.

This is exactly right. The pipeline can scaffold a scoring engine, build an onboarding flow, wire up CRUD operations all day long. Pattern-heavy tasks. But writing content that requires judgment, domain expertise, and taste? That’s a wall.

You could see the same boundary from the other side in the project that built the app. Scaffolding login screens and push notification handlers — pattern work, the pipeline eats it for breakfast. But a briefing email redesign in that same project took a dozen commits, each one a human-directed adjustment. “No onboarding tone in headlines.” “Always use the active analyst prompt.” “Restructure around themes, ideas, content.” The pipeline executed each change perfectly. But the sequence of changes reveals someone steering toward a vision the pipeline can’t hold on its own.

This is the distinction that matters. The pipeline is excellent at executing discrete instructions. It’s poor at maintaining sustained creative intent across a body of work. It can write a paragraph. It can’t write an essay — not one that’s actually going somewhere, not one where paragraph twelve needs to echo paragraph three in a way that only makes sense if you know where paragraph twenty lands.

This isn’t a temporary limitation that better models will fix next quarter. This is structural. Creative intent requires holding a vision of the whole while working on the parts. Every time you hand a pipeline a task, it optimizes locally. The global coherence — the taste — that’s still yours.

For anyone thinking about where AI fits in their work: not “can AI do my job” but “which parts of my job are pattern execution and which parts are sustained creative judgment?” The pipeline is coming for the first category fast. The second category is where your value concentrates.

Machines checking machines

Both the infrastructure project and the app project independently added the same quality check this week — browser screenshots fed to a vision model. The pipeline writes code, a browser renders it, a screenshot captures what the user would see, and a vision model evaluates whether it looks right. The human is nowhere in that loop.

Machines checking machines. Genuinely useful — it’s the first QA mechanism that operates at the level of user experience rather than code logic. But it just pushes the judgment problem up one level. The vision model needs criteria for “good.” Someone has to define what right looks like. You can automate the inspection. You can’t automate the standard.

That’s true in every organization I’ve ever worked with. You can build dashboards, scorecards, automated alerts. But someone still has to decide what the dashboard should measure. The tool doesn’t replace the judgment. It just makes the judgment harder to see.

The practice nobody’s doing

The projects that will thrive are the ones that develop strong editorial instincts about their own output. Not just “did it ship” but “should it have shipped that way.” Not just velocity but comprehension.

What does a daily practice of that kind of judgment actually look like? I have one project that does it well — captures decisions, weighs tradeoffs, narrates the work. I have another that’s outrunning its own supervision — shipping faster than anyone can evaluate what shipped. I built both of them.

The work that remains isn’t technical. It’s the willingness to slow down long enough to understand what your systems are doing on your behalf. And right now, the systems are getting faster while the understanding isn’t keeping up.

That gap is where the next generation of failures will come from.

The constraint in knowledge work used to be execution. More ideas than you could build. More strategy than you could implement. That’s over. The bottleneck moved. And it moved to you.

The machine was waiting on me

I run multiple projects simultaneously, and I’ve built tooling that lets AI agents execute well-defined tasks autonomously. Create an issue, specify what needs to happen, hand it off. The agent builds it, ships it, moves to the next one.

Last week, across one project, an agent shipped twenty-eight issues in a single session. Twenty-eight discrete units of work, no human intervention. Meanwhile, in a separate conversation, I was designing an entirely new system architecture and creating seven more issues for future execution.

Two parallel tracks. One executing. One designing.

The execution track finished before the design track had enough new work ready for it.

The machine was waiting on me.

If you’ve spent time around manufacturing or operations, you recognize this immediately. Eliyahu Goldratt wrote about it in 1984 — The Goal — and the core insight is deceptively simple: any system’s throughput is limited by its single tightest constraint, and improving anything that isn’t the constraint is an illusion of progress.

For decades in knowledge work, the constraint was execution capacity. That’s over. The constraint has flipped. The bottleneck isn’t building — it’s specifying. Not “what should we build” in some grand strategic sense, but the granular, unglamorous work of defining exactly what done looks like for each unit of work. Clear inputs. Clear outputs. Clear acceptance criteria. The kind of specification that most organizations treat as overhead, as bureaucracy, as the thing you rush through to get to the “real work.”

Turns out, that is the real work now.

Specification completeness is the throughput variable

Across three projects last week, I saw three completely different states of readiness. One had twenty-eight issues prepped and ready — the agent chewed through all of them. Another had zero grindable issues. The entire session was planning and design. A third had carry-over issues from previous sessions that still weren’t ready, so nothing shipped.

Same tooling. Same agent capabilities. Completely different throughput.

The difference wasn’t technical complexity or domain difficulty. It was specification completeness. The project that shipped twenty-eight issues had invested in breaking work into self-contained packets — each one with enough context that an agent could execute it without asking questions. The project that shipped nothing had descriptions like “follow the same pattern as this other system” without documenting what that pattern actually is.

“Follow the same pattern” is a perfectly fine instruction for a human colleague who’s been on the team for six months. They have ambient context. They’ve seen the pattern. They can fill in gaps with judgment.

An autonomous agent has none of that. It needs the pattern made explicit. Every assumption surfaced. Every decision pre-made.

This is where organizations are going to struggle. Most organizations are terrible at making implicit knowledge explicit. They run on tribal knowledge, on “you know what I mean,” on the accumulated context that lives in people’s heads. That worked fine when execution required humans anyway — the same humans who held the context. When execution gets handed to systems with no institutional memory, no hallway conversations, no six months of osmosis, every gap in specification becomes a failure point.

The companies that will move fastest aren’t the ones with the best AI tools. They’re the ones that are best at writing down what they actually mean.

Design and supervision destroy each other

There’s a second problem that matters more than the specification gap.

When I ran both tracks — execution and design — in parallel, I discovered something about cognitive architecture. Design work requires expansive thinking. You’re holding multiple possibilities, weighing tradeoffs, making architectural decisions that constrain everything downstream. It needs uninterrupted space.

Execution supervision is the opposite. Reactive. Monitoring. Did that task complete? Did it commit to the right branch? Did it break anything? Important, but interruptive by nature.

When those two modes lived in the same mental context, the design thinking got destroyed. Not because the supervision was hard, but because it was frequent. Every small interruption — check this, approve that, handle this error — fractured the sustained attention that architectural thinking requires.

Cal Newport has written about this — the distinction between deep work and shallow work, and how context switching between them degrades both. But what’s new here is that the shallow work isn’t email or Slack notifications. It’s supervising the machine that’s doing your work for you. The very tool that’s supposed to free up your attention creates a new demand on it.

If you’re a manager, think about where this goes. Your team increasingly comprises AI agents executing well-specified work. Your job shifts from “help people do the work” to “specify the work precisely enough that agents can do it, then supervise the agents doing it.” Those two activities — specifying and supervising — fight each other for the same cognitive resources.

The answer isn’t to do both at once. It’s to architect your workflow so they don’t overlap. Separate the thinking from the monitoring. Give each one its own space, its own time, its own context.

This sounds obvious. Almost no one does it.

The supervision paradox

One more piece. Last week, the execution track committed code directly to the main branch several times despite being configured not to. A known bug. Didn’t matter much when a human was watching every commit. Matters a lot when the agent runs unsupervised for hours.

This is the core paradox. The whole point of autonomous execution is that you don’t have to watch it. But the less you watch, the more dangerous configuration errors become. A small bug that’s trivial to catch when you’re paying attention becomes a production risk when you’re not.

This isn’t unique to software. This is the story of every automated system humans have ever built. Airline autopilot. Self-driving cars. Automated trading systems. The automation works well enough that humans stop paying close attention, and when something goes wrong, the human is out of the loop and slow to respond. The FAA calls it automation complacency. Lisanne Bainbridge wrote about it in 1983 — “the ironies of automation” — and her core observation still holds: the more reliable the automation, the less prepared the human supervisor is to handle its failures.

Every organization adopting AI agents needs to answer this: what does supervision look like when the agent is better than you at the task but worse than you at knowing when it’s gone off the rails?

You can’t watch everything — that defeats the purpose. You can’t watch nothing — that’s reckless. You need intermittent, high-signal supervision. Checkpoints, not continuous monitoring. Audit trails, not real-time observation. Trust but verify, on a schedule.

Nobody has figured this out yet. Not for AI coding agents, not for AI customer service, not for AI anything. The organizations that figure it out first will have a massive advantage — not because their agents are better, but because their supervision architecture lets the agents actually run.

Where this leaves you

The constraint moved. It used to be execution. Now it’s specification and supervision. And those two things — defining work precisely enough for autonomous execution, and monitoring that execution without destroying your ability to think — are in tension with each other. They compete for the same scarce resource: your focused attention.

If you’re a knowledge worker, a manager, a leader — this is coming for you. Not the question of whether AI can do your job. The question of whether you can do the new job that AI creates: the job of thinking clearly enough to direct machines, and watching carefully enough to catch them when they drift.

That’s not a technical skill. That’s a human one.

And right now, almost nobody is practicing it.

The window that opened and closed

In the summer of 2023, I presented a proposal for a comprehensive AI capability program. It outlined frameworks for assessment, curriculum for skill development, and credentials that would signal genuine competence in AI-augmented work. No one was interested. By early 2025, the window had closed. Corporate training providers had launched dozens of AI certificate programs. Consulting firms were selling adoption frameworks to the same institutions that could have created them. Professional education platforms owned the credential space. Universities were still studying the question.

The opportunity wasn’t about AI tools. It was about becoming the trusted source for how humans develop judgment and capability when work itself is being redefined. In 2023, no institution had established authority on these questions. They were genuinely open: What does AI competence actually look like? How do you assess it? What distinguishes responsible use from reckless adoption? What does it mean to develop capability when the tools themselves are learning systems?

Universities had every structural advantage. Research capacity to study effective adoption. Learning design expertise to build curriculum. Credential authority that still meant something. Public trust in educational institutions. The questions being asked were precisely the questions higher education was built to answer.

What was needed was speed and conviction. What we got was academic integrity policies, detection tool debates, and faculty senate resolutions about whether AI should be allowed in assignments.

What happened inside

The failure wasn’t passive. People across higher education submitted proposals, built pilot programs, and pushed for institutional action in 2023. The institutions weren’t ready.

Proposals went into committee structures designed for slow, consensus-driven change. A new degree program might take eighteen months to approve. That timeline assumes a stable domain where waiting costs nothing. AI capability development needed to launch in weeks, not quarters. The governance structures couldn’t accommodate that speed.

Risk management frameworks treated AI as a threat to control rather than a capability to develop. Every proposal triggered the same questions: What about academic integrity? What about cheating? Are we endorsing AI use? What will accreditors think? What are peer institutions doing? The questions weren’t wrong. The framing was. They assumed the risk was in acting. The actual risk was in waiting.

Faculty governance works when you’re revising curriculum in established domains. It fails when the domain itself is being created in real time and the window to establish authority is measured in months.

Universities optimized for risk mitigation, not opportunity capture. When the two conflicted, risk won every time. The institutional logic was clear: the cost of acting too soon felt higher than the cost of acting too late. That logic was wrong, but it was consistent.

Who filled the gap

The vacuum didn’t stay empty. Organizations with less authority but more operational freedom claimed the space.

Corporate training providers built AI capability programs in months. They didn’t have research capacity or educational expertise, but they had decision-making speed and operational clarity. They could see demand, build a program, and launch it without committee approval. By early 2024, dozens of corporate AI training programs existed. By mid-2024, the market was established.

Professional education platforms outside higher education moved even faster. Coursera launched AI certificate programs in partnership with tech companies. LinkedIn Learning built AI skill paths. These weren’t rigorous academic programs. They were good enough to meet immediate demand, and they were available now.

Consulting firms developed AI adoption frameworks and sold them to institutions.

Then came the final indignity. In February 2026, the Department of Labor published comprehensive AI literacy guidance. The guide addresses capability development, assessment frameworks, and responsible adoption. It reads like university curriculum—the kind higher education should have written years earlier. A federal agency did the work universities didn’t.

Tech companies created their own certification programs. Microsoft, Google, and Amazon now offer AI credentials that employers recognize. These credentials don’t replace degrees, but they signal capability in ways that degrees increasingly don’t.

None of these institutions have universities’ research capacity or educational authority. But they all had something universities lacked: the ability to act when action mattered. Authority follows action. Universities had credibility but didn’t act. Others acted and earned credibility.

What universities lost

This wasn’t a missed revenue opportunity. Universities lost something central to their purpose.

Higher education’s core function is developing human capability for consequential work. AI fundamentally reshapes what capability means and how it develops. Universities should have led the conversation about judgment, discernment, and responsibility in AI-augmented work. Instead, that conversation is happening in corporate training rooms and federal agencies.

The loss compounds. Students learn AI capability outside formal education, then question what university credentials actually signal. If the most important skills for their work are developed elsewhere, what exactly is a degree certifying? Professional programs that move faster become more relevant than degree programs that move slowly.

Universities are now in the position of catching up to standards set elsewhere. The DOL guidance establishes a baseline for AI literacy. Corporate training programs define what capability looks like in practice. Universities can still contribute, but they’re no longer leading. They’re following standards created by institutions with less expertise but more operational courage.

The AI window was a test case. Universities failed it in ways that reveal structural problems beyond AI. If higher education can’t move fast enough to address fundamental shifts in work and capability, what exactly is the value proposition? Slow consensus-driven governance works for stable domains. It fails completely when capability itself is being redefined.

What could have been: universities as the authoritative source on AI capability assessment. Research-backed frameworks for responsible adoption. Credentials that actually signal AI-augmented competence. Leadership on the human questions AI raises, not just the technical ones. None of that happened.

What it means now

The window closed. The work still exists. Universities can still do it. The question is whether they will.

Being first mattered. Being right still matters. Universities still have research capacity and educational expertise others lack. The questions about judgment, capability, and responsibility haven’t been answered, just addressed superficially. Corporate training programs teach tool use. Universities could teach capability development. The DOL guidance is a floor, not a ceiling. There’s room for institutions that go deeper.

But it requires different governance, different decision-making speed, different risk tolerance. It requires operational authority for people who understand both education and market timing. It requires governance structures that can move at market speed for market-window opportunities. It requires willingness to lead rather than wait for peer institutions. It requires investment in capability development as a core function, not an add-on program.

Most universities won’t do this. The same structures that caused the problem still exist. The same people control the same decision rights. The same risk calculus will produce the same outcomes. A few institutions will move differently. Those universities will define what higher education means in an AI-augmented world. The rest will continue to be slow, risk-averse, and increasingly irrelevant to the capability development that matters.

Authority isn’t inherited. It’s earned through doing the work that matters when it matters. Universities assumed their authority on education and capability was permanent. AI proved it wasn’t. Higher education had the opportunity to lead on the most significant capability shift in a generation. We chose process over speed, consensus over conviction, risk mitigation over opportunity. Other institutions filled the gap we left open.

I still have the proposal I submitted in the summer of 2023. It’s dated now. The Department of Labor published a better version. That should bother us more than it does.

Organizations needed processors, not meaning-makers. They needed people who followed processes, hit metrics, produced outputs on schedule. Judgment was expensive. Creativity was unpredictable. Questions slowed things down.

So work rewarded the version of you that showed up on time, stayed quiet, and did what you were told. The machine-self.

Here’s what got suppressed: curiosity about whether the work mattered. Judgment about whether the answer was right, not just whether you got the right answer. Creativity that didn’t fit the template. Reflection that might reveal the whole system was pointed in the wrong direction.

These aren’t small things. They’re what make you human rather than programmable.

I saw this pattern everywhere when I consulted for organizations. Smart people, capable people, who had learned to turn off entire dimensions of themselves at the office door. They’d arrive with questions, insights, concerns about direction. And they’d suppress all of it because the system didn’t reward any of it.

The suppression was functional. It worked. For 200 years, being machine-like was how you succeeded. You got promoted for reliability, not judgment. For execution speed, not discernment. For throughput, not wisdom.

And now AI can do all of that better than you can.

The skills you spent decades developing—the ones that got rewarded, that got you promoted, that proved you were valuable—are exactly the ones getting automated. Because they were always machine skills. You were just playing the role of the machine until the actual machine showed up.

This is what people deny. Not that AI is coming. Not that jobs will change. But that the version of yourself you’ve been performing at work was already diminished. That the suppression happened to you, and you cooperated with it, and it cost you something real.

The machine-self isn’t something you chose. It’s what remained after the filtering process. You showed up as your full self—curious, questioning, creative, discerning—and the workplace systematically filtered out every dimension that didn’t produce predictable output.

You learned quickly. Ask too many questions: flagged as difficult. Suggest a different approach: not a team player. Point out that the metrics are measuring the wrong thing: not strategic thinking, just resistance.

So you stopped. You filtered yourself. You became what the system needed you to be.

And it worked. Until the system automated the exact capabilities it had trained you to develop.

Here’s the uncomfortable part: you can’t go back and reclaim those suppressed capacities without admitting they were suppressed in the first place. Without acknowledging that the professional success you built came from making yourself smaller. More compliant. More machine-like.

That’s the denial. Not “my job might be automated.” But “I was already being treated as automatable, and I accepted it because it was rewarded.”

The question isn’t whether AI will replace you. The question is whether the version of you that work created was ever actually you at all. Whether there’s something underneath the machine-self that can’t be automated because it was never mechanical to begin with.

When I taught at Emory, I’d watch graduate students arrive with curiosity and leave with caution. They’d start asking real questions—questions that challenged the framing, that exposed contradictions, that required sitting with uncertainty. And then they’d learn that academic success meant playing the game: cite the right people, use the right language, don’t challenge too directly.

The ones who succeeded learned to suppress what made them good thinkers. Because the system rewarded compliance, not courage.

The same thing happens in every organization. You learn what gets rewarded. You perform that. Everything else gets filed away as “not appropriate for work.”

The denial is thinking this was just practical adaptation. That there was no cost. That you can perform the machine-self for decades and still have access to the full self when you need it.

You can’t. The capacities you don’t use atrophy. The questions you stop asking stop occurring to you. The judgment you don’t exercise becomes uncertain.

So when you feel threatened by AI, what you’re actually feeling is the recognition that you built your professional identity on skills that were always automatable. That the system trained you to be replaceable and called it career development.

That’s what we deny. That the suppression happened. That it cost something. That the professional success came at the expense of what actually makes you irreplaceable.

AI didn’t create this problem. It exposed it. The machine-self was always a compromise. It just worked well enough that you could ignore the cost.

Now you can’t.

The work isn’t learning to use AI tools. The work is reclaiming what you suppressed to succeed in systems that didn’t value it. Judgment. Discernment. Creativity. The ability to ask whether the work matters, not just whether you did it correctly.

Those capacities are still there. But they’re not going to come back just because you want them to. You have to practice them. Strengthen them. Stop filtering yourself to fit the machine’s requirements.

That’s the work. Not staying relevant. Not learning new tools. Becoming actually human again instead of pretending the machine-self was you all along.

This is what The Work of Being is about. Not tips for the AI age. The uncomfortable recognition that you’ve been performing a diminished version of yourself for years, and the path to reclaiming what was suppressed.

If that’s landing, the book is here: The Work of Being: Staying Human in the Age of AI

Every time a new tool emerges for making or manipulating symbols—writing, images, music, calculations—we panic. We declare that the tool will destroy something essential about human cognition, creativity, or authenticity. We resist. We warn. We predict disaster.

And then, quietly, we accept the tool. We integrate it into our work. We forget we ever worried.

The pattern is so consistent across centuries that it’s almost embarrassing.

The printing press (1450s)

When Johannes Gutenberg invented the printing press, scribes didn’t celebrate the democratization of knowledge. They formed guilds to resist it.

Hand-copied texts were considered more authentic, more spiritually meaningful. Johannes Trithemius, a Benedictine abbot, protested what he called “the invasion of the library by the printed book.” Mechanical reproduction, he argued, lacked the devotion of “preaching with one’s hands.”

The scribes were right that something would change. Books would become cheaper, more accessible, less precious as physical objects. But the thing they were protecting—the exclusive control of knowledge reproduction—wasn’t worth protecting. The world gained literacy. The scribes lost their monopoly.

Today, nobody argues that hand-copied manuscripts are more authentic than printed books. We forgot we ever worried.

Typewriters (1880s)

When typewriters spread in the late 1800s, recipients of typewritten letters felt insulted. The typewriter was seen as cold, impersonal, mechanical.

Martin Heidegger—yes, the philosopher—argued that the typewriter meant “the word no longer passes through the hand as it writes and acts authentically but through the mechanized pressure of the hand.” The connection between thought and writing, he believed, was broken by the machine.

Friedrich Nietzsche owned a typewriter. After using it, he wrote: “Our writing equipment takes part in the forming of our thoughts.” He worried the machine was changing how he thought.

They were right that something would change. Writing became faster, more standardized, easier to produce in volume. But the thing they were protecting—some mystical connection between hand and thought—turned out not to matter. Good writing remained good. Bad writing remained bad. The tool was neutral.

Today, nobody argues that handwritten letters are more authentic than typed ones. We forgot we ever worried.

Photography (1839)

When photography emerged, the art world dismissed it as mechanical reproduction, incapable of true creativity.

Charles Baudelaire warned that photography would “supplant or corrupt” art altogether. It was made by a machine rather than by human hands. How could it be art?

The Museum of Fine Arts in Boston didn’t collect photographs until 1924—nearly a century after the medium was invented. It took that long for cultural institutions to accept that photographs could be art.

They were right that something would change. Realistic painting became less necessary. Portraits became cheaper. But the thing they were protecting—the exclusive claim that only hand-made images count as art—wasn’t worth protecting. Photography became its own art form. Painting didn’t die; it evolved.

Today, nobody argues that photographs aren’t art. We forgot we ever worried.

Calculators (1970s)

When calculators entered classrooms, educators warned that students would become dependent on machines. Their computational abilities would atrophy. They’d forget how to do math.

Parents believed their children were being intellectually crippled by these devices. The debate went on for decades. Some schools banned calculators entirely.

They were right that something would change. Students stopped memorizing multiplication tables as rigorously. Mental arithmetic became less emphasized. But the thing they were protecting—the ability to compute by hand—turned out to be less important than the ability to solve complex problems. Calculators freed students to work on harder mathematics.

Today, calculators are in every classroom. Nobody argues they’ve ruined mathematical ability. We forgot we ever worried.

Recorded music (1877)

When Thomas Edison invented the phonograph, critics feared it would kill live performance.

Why would anyone attend concerts when they could hear perfect recordings at home? Theodor Adorno argued that recording distorts authenticity. Walter Benjamin worried that broadcasting removed music from the “concert ritual” that gave it meaning.

They were right that something would change. Recorded music became dominant. The economics of performance shifted. But the thing they were protecting—the exclusive authenticity of live performance—wasn’t threatened. Live music didn’t die. It became one way to experience music rather than the only way.

Today, nobody argues that recorded music isn’t “real” music. We forgot we ever worried.

The pattern

Notice what’s consistent:

1. A new tool emerges that makes symbol-manipulation easier, faster, or more accessible

2. Experts predict disaster - authenticity will be lost, cognition will be damaged, creativity will die

3. They’re right that something changes - the tool does alter workflows, economics, or social practices

4. But wrong about what matters - the thing they’re protecting turns out to be less essential than they believed

5. We accept the tool and evaluate its products on their merits

6. We forget we ever resisted and the anxiety becomes invisible in retrospect

We’re currently in step 2 with AI.

The anxiety is real. The predictions are dire. AI will destroy writing, kill creativity, flood the world with worthless content. We need to detect it, label it, exclude it.

Maybe. Or maybe this is the printing press panic all over again. Maybe we’re protecting something that turns out not to matter—the exclusive human claim to symbol manipulation—while missing what actually matters: whether the output is true, useful, beautiful, or insightful.

I’m not saying AI writing is identical to any previous tool. Each technology is different. The specific changes will be unique to this moment.

But the pattern of anxiety is familiar. Suspiciously familiar. “This time it’s different” is what every generation says. And every generation has been wrong about what’s worth protecting.

What actually matters

Here’s what survives every tool transition: the work still has to be good.

Printing presses produced bad books. Typewriters produced bad writing. Cameras took bad photographs. Calculators didn’t make people good at math. Recordings captured bad performances.

The tool doesn’t determine quality. It never has. What determines quality is whether the person using the tool knows what they’re doing, cares about the outcome, and puts in the effort to make something worth experiencing.

So when I see the AI anxiety—the detection systems, the categorical dismissals, the “slop” panic—I see a familiar pattern. We’re in the resistance phase. We’re predicting disaster. We’re trying to protect something we think is essential.

History suggests we’re probably wrong about what’s worth protecting.

The question isn’t whether AI will change things. It will. The question is whether what we’re defending—the exclusive human ownership of writing—is actually what makes writing valuable.

I suspect it’s not. I suspect what makes writing valuable is whether it helps people think, clarifies ideas, or says something true. And that can be evaluated only by reading the work, not by checking who—or what—wrote it.

We’ll accept that eventually. We always do.

The question is how long we’ll spend in the panic phase before we get there.

Here’s the decision that made everything else easier: files are the source of truth. Not a database. Not a cache. Not a sync process. Just markdown files on disk.

Every time I thought about adding a feature, I asked: does this require storing state outside the markdown files? If yes, I didn’t build it.

That constraint kept the architecture simple. But it’s deeper than architecture. It’s about permanence.

Files outlast systems

A database requires a running system to mean anything. Stop running the database server, and your content is just binary data in proprietary formats. You need that specific software, that specific version, those specific drivers, just to read what you wrote.

Files are different. A markdown file is a text file. You can open it with any text editor. You can grep it. You can version control it with Git. You can copy it to a USB drive and open it on a different machine 10 years from now. The format is readable. The content is portable.

This isn’t just technical. It’s about control.

When your content lives in a database managed by someone else’s platform, you’re dependent on that platform continuing to exist, continuing to let you export, continuing to honor the format they say they use. Every web service promises an export button. Most of them work, until they don’t.

Files don’t require promises. They’re already yours. They’re already readable. They already work with every tool that understands text.

You can print a file

Here’s a test: can you print what you wrote?

Not “generate a PDF from the web view.” Not “export to a format that might print correctly.” Just: select the file, hit print, does it work?

With a file, yes. It’s text. Your operating system knows how to print text.

With a database, no. You need the platform to render the content, style it, convert it to something printable. If the platform goes away, so does your ability to access that content in any meaningful form.

This matters more as time passes. The blog posts you wrote in 2010—can you still read them? If they were in a service that shut down, maybe not. If they were markdown files in a folder, yes. Still there. Still readable.

Static is underrated

“Static” sounds limiting. Databases are dynamic. They respond to queries. They scale. They handle relationships.

But static means stable. It means your content doesn’t change unless you change it. It means you can version control every edit. It means you can diff two versions and see exactly what’s different. It means there’s no hidden state, no background processes rewriting things, no sync conflicts that silently corrupt data.

Static site generators embraced this. Your content is files. Your build process is reproducible. Your output is HTML, CSS, and JavaScript—also just files. The whole pipeline is transparent. You know what’s happening at every step because you can see the files changing.

This isn’t nostalgia for simpler times. It’s recognizing that permanence has value. Files last. Databases don’t. Systems change. Platforms shut down. Formats evolve. But a text file from 1990 still opens today. That’s not a bug. That’s the feature.

What this means for your work

If what you’re writing matters beyond this week, this month, this year—consider: where does it live?

If it lives in someone else’s database, you’re trusting them to preserve it. Maybe they will. Maybe they won’t. Maybe they’ll change their export format. Maybe they’ll add friction to leaving. Maybe they’ll just disappear.

If it lives in files you control, it’s yours. You can move it. You can back it up. You can read it with any tool. You can print it. You can version it. You can trust that it will still be there when you need it.

This isn’t about rejecting databases. They’re useful for live systems, for collaboration, for querying. But for content that matters—for writing that you want to last—files win.

Files are permanent. Databases are not.