Tag: organization

  • The AI-native worker: the atomic unit of an AI-native organisation

    The AI-native worker: the atomic unit of an AI-native organisation

    In the last piece I looked at what actually separates AI-native firms from everyone else, and one finding has been nagging at me since. The study behind it found these firms were flatter as well as leaner: more senior people, fewer managers, matched like-for-like against their peers. I reported that without really explaining it. Economists have held since Coase in 1937 that a firm’s shape follows its coordination costs, and AI is plainly moving those. But that finding is about the inside of the firm. And the inside only makes sense one level below the org chart, at the smallest unit a company is assembled from: the worker, and what one worker can now carry.

    The worker, renamed

    Nearly seventy years ago, Peter Drucker renamed the atomic unit of work. The knowledge worker was his label for people whose output is thinking, and the renaming mattered because everything eventually reorganised around it: the office, the KPI, the annual review, the one-on-one. It took decades, but the way we run companies today is the machinery we built to manage the unit Drucker named.

    We’re due another renaming, and my working label is the AI-native worker: a person, a knowledge worker who runs their patch of the organisation through a set of AI tools and agents, and who owns the outcome the way a manager once owned a team’s. The durable thing is the worker, and the discipline they run; the agents themselves are mostly ephemeral, spun up for a task and discarded after (my research setup, for instance, assembles the evidence on a named prospect, reads anything public, sends nothing, and might be rebuilt from scratch next month).

    The deeper change is in what the role contains. For a century we ran a deliberate split: managers decided what to do and how it should be done, and the front line did it — scientific management made that split official policy. The AI-native worker compresses the stack back together. They set the direction, decide the how, and orchestrate agents that do the doing. Drucker saw the first half of this coming when he argued that knowledge workers can’t be supervised in the old way and must manage themselves; the tools have now supplied the second half. Judgment and execution end up in the same hands again, which is where they sat before the split.

    Process automation with better branding, then? Not quite, and the reason takes the rest of this piece.

    The dial and the span

    Last time, I described running my own go-to-market on two modes: either nothing leaves the building until I’ve looked at it, or the work runs on its own and shows me samples. That was a simplification. The fuller picture is a dial with positions along it: approve every step; watch and sample while the work runs; set direction and audit the record afterwards. Think of it as a dimmer, not a switch. Each task a worker hands to their tools sits somewhere on that dial, and the worker sets the position — moving a task down the dial is something a tool earns, on track record it can point to.

    In my own pipeline the same work has moved along the dial as the tools proved themselves: the research loop once ran with me approving each output, and now runs ahead of me with spot-checks. The call on whether a prospect is qualified hasn’t moved at all, and likely won’t (some decisions I simply want to make myself). Both sit inside one person’s remit. The dial only says how much of the doing gets handed off, and for some of it the honest answer is none.

    The old rule of thumb was that a manager could handle five or six direct reports (a number honoured mostly in the breach), because supervising people means conversations, meetings, and reading a room, and those relationships multiply faster than headcount. Most organisational pyramids are simply that arithmetic made visible. But supervising tool-work is different: you read a work record, sample outputs, and handle what gets handed up. One worker can run far more of it than anyone ever could direct reports, and the ceiling that produced the pyramid stops binding.

    There is a deeper reason the pyramid thins. Strip management to its core function and much of it is answering questions: the front line handles the routine, and whatever it can’t answer moves up to someone with broader knowledge. A layer exists because those questions exist. Put the answer at the point where the problem occurs, which is much of what AI does, and the questions stop travelling upward. The layer that lived on them has nothing left to do. (Nicolai Foss walks through the economics of this, for anyone who wants the theory.) The same logic runs sideways: a worker who covers a workflow end to end leaves no handoffs to manage. Software had a preview of this long before AI — some engineers were worth ten, and famously couldn’t be replaced by ten. Leverage concentrates in the people who wield their tools well, and that pattern is no longer confined to software.

    Which is, I suspect, exactly what that flatter-firms finding was measuring. The coordination work that fills much of middle management (collecting status, relaying context, scheduling the work of others) is the part that compresses first. If that work is the bulk of what you do, it can feel like there will soon be nothing left to do. What remains, though, is more hands-on than the job it replaces: direction, judgment, exceptions, and the running of the work itself.

    This is no longer speculation about the headlines, either: Oracle, Meta and a growing list of large employers have explicitly cited AI in this year’s job cuts, though few of them describe what changed in span-of-control terms. Microsoft’s Work Trend Index calls the destination human-agent teams with every employee expected to direct agents rather than do all the doing themselves. Wherever the labels settle, the shape is consistent: fewer people, each carrying more, each closer to the actual work.

    Lean around what you’re best at

    If one worker can carry more, the question becomes what they should carry. C.K. Prahalad and Gary Hamel answered this more than thirty years ago: organise around your core competence, the few things you’re distinctively good at. AI sharpens that old advice, because once the routine frictions fall away, the constraint that remains is judgment, and your judgment is only worth a premium where your competence is. The same holds one level down: an AI-native worker leans out the way an AI-native firm does, concentrating on the work where their judgment is differentiated and pushing everything else to tools, or to whoever already does it better. Which cuts against the current fashion for pulling everything in-house because building got cheap. Build where your judgment is the ingredient: the thin layer shaped around work only you do that way. Improvise your own version of everything, though, and you end up with a portfolio of systems nobody truly owns, and the governance bill arrives later. Cheap building sharpens the buy-versus-build question rather than settling it.

    One record everyone reads

    None of this survives contact with reality without one more piece, and it’s the one traditional organisations never managed to build. When an experienced colleague resigns, what walks out with them is rarely written anywhere: which client dislikes calls before ten, why the pricing was structured that way, what was tried in 2023 and quietly abandoned. Drucker saw this coming too; knowledge work runs on know-how that is hard to write down, which is precisely what makes an organisation fragile when people leave. We preached the single source of truth for decades and never had one, because keeping it current was rote work, and it was nobody’s real job.

    An AI-native worker can’t run any other way, so the fix gets forced. All the work runs out of a shared, plain-language record: decisions, drafts, handovers, and the reasoning behind them land there as a by-product of doing the work, with no documentation step bolted on afterwards. The agents remember nothing between tasks; the record is the memory. And plain language is the interface: the same written brief that would bring a new colleague up to speed is what briefs an agent, and the record an agent leaves behind reads like a colleague’s notes. So the know-how that used to live in heads finally has somewhere to sit, and it stays current because everyone, human or tool, works from it daily.

    The record earns its keep twice over. It is what keeps coordination cheap as one worker’s reach grows; without it, the savings leak back out as interruptions, and the old coordination bill walks straight back in. It is also where this series goes next: software shaped around the exact work, and handoffs someone actually designed.

    Not the automation you remember

    The automation wave most businesses remember automated keystrokes: scripts that clicked through screens, brittle the moment an invoice format changed, readable only by the IT department. It could only ever hold work you could spell out step by step, which is why it stayed at the edges of the organisation. This is a different proposition, and the difference is the package: a worker who owns outcomes across both the step-by-step work and the judgment calls, a dial that sets how much oversight each task gets, and one plain-language record that people and tools alike read and write. Take away any one of the three and you’re back to a slightly better version of the old automation. Together they form a new operating layer for the organisation, which is a different ambition from building software faster.

    One question stays open, and it’s the one Drucker spent his career on: how do you measure this kind of worker’s productivity? The full work record makes quantity temptingly easy to count, and the corporate world just ran that experiment. The “tokenmaxxing” fad, measuring people by how much AI they used, in one case running an internal competition to reward it, rose in spring and was being walked back by summer, as costs climbed without the productivity to show for them. One CTO compared it to grading programmers on lines of code. Outcomes per role are the honest measure, and defining the role is the harder half.

    The workers exist, the dial is in daily use, and the pitch from the providers themselves has been shifting from assistants you chat with toward agents you delegate to and oversee. What’s still forming is the discipline around it, and that part, pleasingly, is management work: deciding what a role owns, what its tools may touch, where on the dial each task starts, and what counts as doing well. Somewhere in your own week there’s a stretch of work defined tightly enough to hand to the dial tomorrow. Assume the tools could do it; the question worth sitting with is where on the dial you’d be willing to start, and what it would take to earn the next notch.

  • What “AI-native” actually means for a founder-led firm

    What “AI-native” actually means for a founder-led firm

    A recent paper from INSEAD and Harvard looked at close to 3,000 startups and found something that should interest anyone running a small firm. Matched like-for-like, same industry, same age, the ones built around AI ran about a quarter smaller than the ones that weren’t. In services, the gap reached roughly 70%. Fewer people, the same kind of work, and not because they were starving themselves of staff.

    A smaller firm that is worth more

    Across eleven startup batches from 2020 to 2024, the AI-native firms ran leaner and flatter, carried more senior people and fewer managers, and still raised more money and held higher valuations per head than their peers. The smaller size was buying more output per person, not papering over weaker companies. The effect was largest, near 70%, in services firms, the advisory-and-delivery work many of us sell. If your firm sells judgment rather than a shipped product, that number is aimed at you.

    One example makes the shape concrete. An AI slide-deck company reached around $50M of annual revenue in about two years with a team of roughly 30, because making a deck became something the customer does inside the product instead of a job that lands in someone’s queue. A small team, a lot of output, because the work itself moved.

    A fair caveat, which the paper makes and most write-ups drop: a leaner firm need not mean fewer jobs overall. Cheaper output tends to pull in more demand for it (the Jevons paradox: make something cheaper and we usually use far more of it), so the economy can end up with more firms and more total work even as each one shrinks.

    The most telling result is one that didn’t show up the way you might expect. The AI-native firms in the study were about 2.6 times more likely than the rest to name worker-facing tools (ChatGPT, coding assistants, and the like) in their job ads, yet that heavier tool use predicted none of the structural differences: not the smaller size, not the flatter hierarchy. As the authors put it, “equipping workers with ChatGPT, Copilot, or Cursor does not, on its own, predict smaller firms.”

    A large MIT study in 2025 found the mirror image: around 95% of corporate AI pilots delivered no measurable impact, with the failures traced to organisations bolting AI onto existing workflows rather than to the technology itself. Both point the same way. The gains come from redesigning the work, and the licence count barely matters.

    What did track with firm size was where the AI sat. Used inside the firm to speed up work people already do, it moved the structure very little. Built into what the firm sells, so the customer generates the output directly, it tracked with the shrinkage. It is the same move Ben Thompson called an unbundling: the firms that pull ahead fold the act of making something real into the product, rather than keeping it a step their staff perform.

    Governed delegation

    What makes a firm AI-native, then, is how far it has rebuilt its work around what AI can do reliably and what still needs a person watching. Call it governed delegation: you hand the work to AI while keeping your hands on the rules, the boundaries, and the checking. Think of a restaurant that buys a dishwasher but keeps everyone rinsing each plate by hand first. It has added a machine and kept the old routine, so all it has really bought is cost. The gain shows up only when the workflow is rebuilt around what the machine does well.

    Most of this conversation stays inside software teams, which is why the wider point gets missed. The same logic runs straight into sales, marketing, and operations, which is where I have spent the past several months testing it. I run most of OrchestratorAI’s own go-to-market this way: agents handle well-defined pieces of work, and my job is to set the rules and check the output rather than produce each piece by hand. Each group of agents runs in one of two modes, either nothing leaves the building until I have looked at it, or it runs on its own, shows me a sample, and escalates the exceptions. A task earns its way from the first mode to the second only after it stops throwing up things to fix, and some never do. Drafting a note to a high-value prospect stays under review; filling in a basic company profile from public sources does not need me hovering.

    Running it this way taught me something the paper doesn’t quite reach: almost none of the governance had to be invented. We have spent decades building ways to govern people at work: audit trails and compliance checks, standard operating procedures, the maker-and-checker split in finance, code review and the ceremonies of Agile. In a human-only firm a lot of this sits heavy. It adds layers and breeds box-ticking, because people dislike being audited and tire of the checklist, so the control gets watered down to what the organisation or regulators will tolerate.

    Point the same practices at AI agents and the weight largely lifts. An LLM is trained on how people work, so it takes direction roughly the way a person does, and the structure of the playbook carries over. The agent doesn’t resent the audit log or cut the SOP short when it’s busy, so a check that was costly to run on people is cheap to run on an agent. The procedures that were overhead in a human firm become the guardrails of an AI-native one. The autonomous SDLC (the software build-and-ship cycle, increasingly run by agents) is the clearest case I’ve come across: code review, the test gate, the staged rollout that always slowed teams down are exactly what lets an agent ship without a human reading every line.

    The one catch here is that agents fail differently from people. They don’t commit fraud or get bored; they fabricate confidently and come apart on inputs a person would laugh off. So the controls transfer in shape, not in detail: you keep the independent check and the earned trust, but you point them at hallucination and weak grounding rather than at fatigue and dishonesty. Those rough edges are being ironed out quickly. Coding is the clearest case, where agents have grown markedly more reliable over the past year, and making AI broadly more dependable and harder to misuse is a major focus at the frontier labs, still some way from solved. The upshot is that there is already plenty an agent can be trusted to do well today, and the list keeps growing.

    What it means if you run a small firm

    The paper names the real bottleneck, and it isn’t access to AI, which everyone now has at much the same price. It is the mapping problem: working out where, in your particular business, AI actually pays off. That has no generic answer, and finding it is the work that’s left.

    For a founder, the practical shift is that your scarce time moves from production toward direction and judgment, deciding where AI-handled work ends and where human review is non-negotiable. The closer you sit to pure services, the sharper that shift, which is presumably why the services number ran to 70%. Autonomy has to be earned, too: moving a task from supervised to self-running is a track record you build through logging and spot-checks, not a switch you flip. So the key question to put to your own firm is not which AI tools to buy, but which parts of the work can be governed at the boundary, and which still need a person on every output.

    None of this is settled, and the unsettled part is the interesting one: deciding when a piece of work has earned its autonomy, and building the checks so you aren’t flying blind once it runs alone. Strikingly few firms in the data had actually managed it, which makes “AI-native” more aspiration than description for now, even among the companies wearing the label. That is the encouraging part. The tools are here and roughly evenly spread, so the advantage goes to whoever does the slow, unglamorous work of deciding what to hand over and what to keep a hand on.

  • The Task Changed, The Job Didn’t — But Your Org Hasn’t Noticed Yet

    There’s a conversation happening quietly in engineering teams, product orgs, and design studios. It surfaces in Slack DMs and whispered break-room conversations. The question underneath is always the same: If AI can do what I do, what am I for?

    That fear makes sense. Engineers who built their identity around writing clean code watch AI generate entire modules in seconds. Product managers who prided themselves on writing crisp specs see AI agents do the same work overnight. Designers watch their Figma files get autocompleted before they’ve finished thinking through the problem.

    But here’s what’s being missed: the task is changing, the job isn’t.

    Writing code was always a means to an end. The job was shipping features that solve problems. Writing specs was always a means to an end. The job was understanding user needs and deciding what to build. AI automates the means, not the end. The bottleneck was never typing speed — it was clarity of thinking, problem definition, and judgment about what to build.

    Those bottlenecks are still ours.

    The Identity Trap

    Most people in technology define themselves by the task they perform, not the outcome they produce. “I’m a backend engineer” means I write backend code. “I’m a PM” means I write specs and manage tickets. When AI starts doing those tasks faster and arguably better, the identity feels threatened.

    The first response is usually denial: “AI can’t really do what I do — it doesn’t understand context, it makes mistakes, it needs constant supervision.” The second is panic: “I’m about to be replaced by a model that costs pennies per thousand tokens.”

    But the real shift isn’t about automation replacing roles. It’s about what happens when execution becomes nearly free and the entire competitive advantage moves to knowing what to build in the first place.

    From Tasks to Judgment

    When people ask what humans will do in this new world, the answer is usually “taste and judgment.” But that’s abstract. What does judgment actually mean?

    It means knowing what to build, when to say no, and how to spot when AI is heading in the wrong direction. It’s defining the guardrails before you let agents run — test suites, design patterns, architectural constraints. It’s understanding that every line of code is future maintenance burden, which makes the discipline to not build more valuable than the ability to build fast.

    In 2014, Melissa Perri warned about “The Build Trap” — companies stuck measuring success by what they shipped rather than what they learned. “Building is the easy part,” she wrote. “Figuring out what to build and how we are going to build it is the hard part.”

    Most companies ignored that. Now AI makes building trivially easy, and those companies are about to drown in features that solve nothing. The agents don’t get tired. They don’t push back. They’ll happily build everything you point them at, whether or not it should exist.

    The Multi-Hat Convergence

    The expectation is shifting: one person who can think about the problem, design the solution, and use AI to build it. This doesn’t mean everyone becomes a shallow generalist. It means the boundaries between roles blur significantly.

    PMs without a hard skill — design or code — and engineers without product sense are both increasingly vulnerable. The trifecta of product thinking, design sense, and technical execution is becoming the baseline, not the exception.

    For experienced professionals considering independence, this convergence changes the economics dramatically. A single person with AI tools can now deliver what used to require a small team.

    The Org Structure Problem

    Most organizations are still structured around tasks, not outcomes. Teams are organized by function — frontend team, backend team, QA team, design team. Performance is measured by task completion: PRs merged, tickets closed, specs written.

    AI makes task completion trivially fast, which breaks these measurement systems completely. The real metric should be business outcomes, but most orgs aren’t wired to measure or incentivize that way.

    Companies are starting to notice. Last year, the Shopify CEO asked employees to prove why they “cannot get what they want done using AI” before asking for more headcount. Last week, Block laid off 40% of its workforce — more than 4,000 people. Co-founder Jack Dorsey was direct: “A significantly smaller team, using the tools we’re building, can do more and do it better.”

    A startup with great direction and AI agents beats a startup with mediocre direction and the same agents. A company with 10 people who know exactly what to build beats one with 100 people building everything they can think of.

    The companies still hiring for “more hands” are optimizing for the wrong bottleneck.

    What This Means for You

    If you’re an engineer, invest in product sense and domain expertise. Understand why you’re building, not just how. Study the business side of your domain — unit economics, customer behavior, market dynamics.

    If you’re a PM, get your hands dirty with at least one hard skill. Design or code, even at a basic level. The ability to prototype your own ideas or understand technical tradeoffs without waiting for a meeting makes you more effective than you’d expect.

    If you’re a leader, start restructuring teams around outcomes, not functions. Measure business impact, not tickets closed. Reward people for solving problems and learning, not for producing code.

    Stop identifying with your task. Start identifying with the outcomes you produce.

    The people making this shift now are building a compounding advantage. The gap widens every month. Domain expertise becomes your moat. The deeper you understand a specific business problem space, the better you can direct agents toward solving it.

    The execution bottleneck is being solved. The judgment bottleneck requires human capacity, and it’s where the real value lives now.

  • The Dark Factory: Engineering Teams That Run With the Lights Off

    A few engineering organisations are already operating a model most companies haven’t begun to consider. While the typical software team debates whether to adopt AI coding assistants, companies like StrongDM are running fully automated development pipelines where agents handle implementation, testing, review, and deployment. Humans set direction and define constraints. The mechanical work happens without them.

    This isn’t speculative. It’s operational. And the gap between companies working this way and those that aren’t is widening fast.

    What “lights off” actually means

    The term comes from manufacturing — factories that run autonomously, with minimal human presence. In software, it describes engineering organisations where AI agents do the bulk of execution work while humans focus on architecture, constraints, and outcomes.

    StrongDM’s approach is instructive: their benchmark is that if you haven’t spent at least $1,000 on tokens per human engineer per day, your software factory has room for improvement. Agents work in parallel on isolated tasks. Code is written, tested, and reviewed without manual intervention. Tasks assigned Friday evening return results Monday morning.

    The ratio of agents to humans is high and growing. But this isn’t about replacing engineers — it’s about fundamentally changing what engineers do.

    The guardrails are the system

    Dark factories aren’t ungoverned. They’re heavily governed in a different way.

    Linters, formatters, comprehensive test suites, design pattern enforcement — these become pre-conditions rather than suggestions. Agents are configured to seek completion only when all guardrails pass. Code review shifts from line-by-line human inspection to AI review with human spot-checks on critical paths.

    The discipline moves from “write good code” to “design good systems for code to be written in.” That’s a different skill. It requires thinking about constraints, validation, and feedback loops rather than syntax and implementation details.

    Anthropic’s experiment building a C compiler with parallel Claude instances demonstrates this principle. Sixteen agents worked simultaneously on a shared codebase, coordinating through git locks and comprehensive test harnesses. The result: a 100,000-line compiler capable of building the Linux kernel, produced over nearly 2,000 sessions across two weeks for just under $20,000. The project worked because the test infrastructure was rigorous enough to guide autonomous agents toward correctness without human review of every change.

    Cursor’s experiments with scaling agents ran into a different problem. They tried flat coordination first — agents self-organising through a shared file, claiming tasks, updating status. It broke down. Agents held locks too long, became risk-averse, made small safe changes, and nobody took responsibility for hard problems. The fix was introducing hierarchy: planners that explore the codebase and create tasks, workers that grind on assigned work until it’s done. No single agent tries to do everything. The system ran for weeks, writing over a million lines of code. One project improved video rendering performance by 25x and shipped to production. Their takeaway: many of the gains came from removing complexity rather than adding it.

    Digital twins as the enabler

    The biggest blocker to agent autonomy has been the fear of breaking production. Digital twins remove that constraint.

    StrongDM built behavioural replicas of third-party services their software depends on — Okta, Jira, Slack, Google Docs, Google Drive, and Google Sheets. These twins replicate APIs, edge cases, and observable behaviours with sufficient fidelity that agents can test against realistic conditions at volume, without rate limits or production risk.

    Simon Willison’s write-up of StrongDM’s approach highlights how this changed what was economically feasible: “Creating a high fidelity clone of a significant SaaS application was always possible, but never economically feasible. Generations of engineers may have wanted a full in-memory replica of their CRM to test against, but self-censored the proposal to build it.”

    What makes this rigorous rather than just better staging is how they handle validation. Test scenarios are stored outside the codebase — separate from where the coding agents can see them — functioning like holdout sets in machine learning. Agents can’t overfit to the tests because they don’t have access to them. The QA team is also agents, running thousands of scenarios per hour without hitting rate limits or accumulating API costs.

    The structural advantage of starting fresh

    Startups and SMBs have a material advantage here. No legacy organisational structure to dismantle. No 500-person engineering floor with stakeholders defending headcount. No 18-month procurement cycles.

    Capital efficiency becomes native. A three-person team with agents can produce output that previously required twenty people. The cost of compute is a fraction of equivalent human labour and falling rapidly.

    This creates an asymmetric advantage. If your competitor ships in days what takes you months, no amount of talent closes that gap. And the competitive pressure isn’t just on speed — it’s on the ability to attract talent that wants to work this way. Senior engineers who’ve experienced agent-driven development don’t want to go back to manual workflows.

    The gap between adopters and laggards

    Companies operating this way are shipping at a fundamentally different pace. The difference isn’t incremental — it’s orders of magnitude in output per person.

    Block’s recent announcement of a near-50% reduction in headcount offers a data point. The company is reducing its organization from over 10,000 people to just under 6,000. Jack Dorsey stated “we’re not making this decision because we’re in trouble. our business is strong” but noted that “the intelligence tools we’re creating and using, paired with smaller and flatter teams, are enabling a new way of working which fundamentally changes what it means to build and run a company.”

    Cursor’s data shows the same pattern. 35% of pull requests merged internally at Cursor are now created by agents operating autonomously in cloud VMs. The developers adopting this approach write almost no code themselves. They spend their time breaking down problems, reviewing artifacts, and giving feedback. They spin up multiple agents simultaneously instead of guiding one to completion.

    The laggards aren’t just slower. They’re increasingly unable to compete for talent, capital, or market position against organisations that have made this transition.

    You don’t need a corporate budget to start

    The dark factory model scales down. A single developer with a Claude Code subscription and well-structured GitHub workflows can run a lightweight version of the same approach.

    Start with one workflow. Pick a repetitive part of your development or business process, establish the guardrails, and let agents handle it. The key investment isn’t in compute — it’s in guardrails and context. Linters, test suites, good documentation, and clear specifications matter more than token budget.

    For SMBs and founders, this is the most asymmetric advantage available. You can operate at a scale that was previously only accessible with significant headcount. The learning curve is steep but short. Within 30 days of serious experimentation, most people develop the intuition for what agents can and can’t handle.

    Projects like OpenClaw — an open-source autonomous agent that executes tasks across messaging platforms and services — demonstrate that the tooling for this approach is increasingly accessible. The software runs locally, integrates with multiple LLM providers, and requires no enterprise licensing. The barrier isn’t access to technology. It’s willingness to change how work gets done.

    What this means beyond software

    Software is where this pattern is playing out first, but the model applies wherever knowledge work is structured and repeatable.

    Audit processes. Compliance checks. Report generation. Data analysis. Document review. These are all candidates for the same approach: clear specifications, comprehensive validation, and autonomous execution within defined guardrails.

    Most traditional industries haven’t started thinking about this. They’re still debating whether to use ChatGPT for email drafts. The firms that figure out how to apply dark factory principles to their domain will have an enormous advantage over those still operating with manual workflows.

    The lights are already off in some factories. The question isn’t whether this approach will spread. It’s how quickly your organisation recognises that the game has changed.