Why I Am Firing My AI Specialists

I am firing my AI specialists. Not because they failed, and not because I have decided that one generic chatbot is better. I am doing it because the team I built became useful enough to expose its own next constraint: I was starting to manage the organization around the AI instead of simply benefiting from the capabilities inside what should be an AI Operating System.

That is a strange problem to have because the specialist model solved something real. A single general-purpose assistant was too broad for the range of work I wanted to run through it. Career decisions, editorial strategy, writing, analytics, website architecture, venture development and opportunity scouting all required different context, different guardrails and different definitions of a good result. I needed separation of concerns before I needed more autonomy.

So I gave the capabilities names. Richard handled executive-career judgment. Steve shaped content strategy. Frank turned an approved brief into production-ready editorial work. Guddy thought about the website as a product. Don challenged distribution and growth. My Quant challenged evidence. Richi searched for opportunities. Lord Business orchestrated the bigger picture. In AI Agent Roles: Why I Gave Mine Ridiculous Names, I described those names as cognitive handles: memorable interfaces to explicit operating contracts rather than an attempt to pretend software had become a human colleague.

The names worked. The role boundaries worked. The system became easier to reason about because it resembled something I already understood: a company.

The specialist model did not fail. It became successful enough for its coordination cost to become visible.

The AI team solved the problem I had at the time

Human-style specialization gave me five things that a generic assistant did not reliably provide. It separated responsibilities. It created a mental switch between different kinds of work. It forced clearer handoffs. It made authority boundaries explicit. And it gave the overall system a shape I could understand without carrying a detailed capability map in my head.

The improvement was not theatrical. Richard was not useful because I could imagine a synthetic executive adviser sitting behind a desk. Richard was useful because career decisions had a defined remit, canonical sources, explicit criteria and a clear point at which my own judgment took over. Steve and Frank were useful because strategy and production were not allowed to collapse into one vague request to “help with content.” My Quant was useful because evidence had a role designed to challenge enthusiasm rather than reinforce it.

This is consistent with the reason custom GPTs remain useful in ChatGPT today. OpenAI describes GPTs as versions of ChatGPT configured for a specific purpose, combining instructions, knowledge and selected capabilities. That is almost exactly what I wanted when I created the first generation of my system: distinct purpose, tailored context and bounded behavior.

The same discipline also improved governance. Some capabilities could recommend. Some could draft. Some could inspect live systems. Very few could make consequential changes without approval. My earlier argument that AI agent decision quality improves when repeated corrections become durable operating rules still holds. The point of specialization was not just better output; it was a system that could become more reliable over time.

I still believe all of that. What changed is where I now think the boundaries should live.

Then the handoffs started becoming the work

As the system became more capable, every specialist accumulated more of its own operating reality. It had instructions. It had assumptions about other specialists. It had preferred sources. It had rules about handoffs. It had a partial representation of objectives, priorities and standards that also existed elsewhere. The organization became more sophisticated, but the amount of coordination required to keep it coherent increased with it.

I began to notice a familiar pattern. I would finish work in one context and then decide which specialist should receive the next step. I would transfer the relevant state. I would explain what had already changed. I would discover that one role still carried an older interpretation of the operating model. A correction that should have been a single policy change sometimes became a small retraining exercise across several synthetic employees.

None of those frictions was catastrophic. That is precisely why they were easy to tolerate. They looked like the normal cost of running a team. But that explanation became less satisfying once I remembered that this was not actually a team of people. I had imported the coordination pattern along with the useful metaphor.

I had recreated functional silos, duplicated knowledge, stale instructions, handoff overhead, role ambiguity and organizational memory trapped inside individuals. I was using AI to simulate an organization, including some of the problems organizations already have.

There was also a product-surface trigger. For months, I found it frustrating that the specialist GPT I wanted was not always naturally callable from the project or context where I was already working. My first reaction was to treat that as a missing feature. Last week I started asking a different question: what if the limitation was exposing a weakness in my architecture? If I needed one synthetic employee to summon another synthetic employee so that work could continue, perhaps I had designed the wrong primitive.

I do not read product intent into that observation. OpenAI still supports existing GPTs, while its current product architecture also gives more explicit roles to other primitives. Projects are described as persistent context hubs for long-running work, while Skills are described as reusable workflows that ChatGPT can invoke when helpful. That does not prove a universal architecture. It does make the distinction between context and capability much more concrete.

The context should stop moving

The migration I am making now starts with one architectural inversion:

The context does not move anymore. The capability moves to the context.

That sounds like a small technical distinction. It changes almost everything about how I think about the system.

In the old model, Richard effectively “knew” how my career worked. His instructions carried career semantics, decision rules and expectations about what counted as a good opportunity. The new model makes Executive Career the owner of that truth. Applications, stages, compensation policy, contacts, networking relationships and career-specific guardrails live in the domain where they belong. A Career Opportunity Assessment capability can then operate on that canonical state whenever needed.

Richard can survive, but as an interface. I can still ask Richard because the name is useful to me. The difference is that Richard no longer needs to own a private copy of the career system in order to be useful. If the compensation policy changes, I should change the policy once. The next compliant capability should retrieve the new rule when it runs.

The same change applies to editorial work. Frank does not need to contain the editorial system. Open Source Consulting owns the editorial standards, publication state, article inventory, positioning constraints and production requirements. Editorial Production is a capability that operates against those sources. If the production standard changes, the canonical standard changes. Frank should not need a separate retraining event.

I am not replacing specialists with one giant assistant

This distinction matters because “firing the specialists” can easily sound like I have gone full circle and decided that one general model should do everything. That would recreate the problem that caused me to build specialists in the first place.

I still want specialization. I want different methods for career assessment, editorial production, evidence analysis, strategic review and product architecture. I still want explicit source boundaries. I still want different authority levels. I still want some capabilities to challenge others. I still want human judgment to remain the validation gate for consequential decisions.

What I no longer want is to make the fictional employee the place where all of those things have to live.

This is close to the architectural principle Anthropic describes in its guidance on building effective agents: successful implementations often rely on simple, composable patterns rather than unnecessary framework complexity. My experiment is not evidence for a universal agent design, but it reinforces the practical value of composition. The more capabilities can be reused against shared state, the less reason I have to preserve organizational boundaries merely because they are familiar.

So the migration separates four things I previously bundled together: context and state, capability, interface, and execution trigger.

The specialist capability survives. The fictional employee boundary does not necessarily survive.

The migration is already changing how I work

The first step has not been deleting GPTs. It has been cleaning up where truth lives.

The operating system now has one planning cycle, one global Objective and Key Result structure, one shared Jira capacity model, one source registry and one capability registry. Open Source Consulting now separates venture strategy, commercial validation, engagements, editorial standards, website infrastructure, publishing operations and analytics instead of allowing all of them to accumulate inside one giant context.

That work is not glamorous. It is also the part that makes the architectural change real. A capability cannot reliably retrieve canonical context if “canonical” is only a word and five slightly different versions of the truth still exist.

This is why I do not see the migration as a prompt-engineering exercise. It is operating-model work. The AI layer can only become simpler when the underlying information ownership becomes clearer.

The direction also connects to a broader principle I have been testing in Redesigning Work With AI Starts When I Stop Trying to Use AI: technology becomes more valuable when I stop asking where to insert it and start asking what the work should become. In this case, I had been optimizing the synthetic team instead of questioning why a synthetic team was required.

The test is whether Frank still works without Frank

I do not yet know whether the new architecture is better. I know why I am changing it. That is not the same thing.

The migration still has to pass practical tests. Can Steve shape content strategy from current canonical sources without carrying a private representation of the week? Can Frank produce reliably against live editorial standards? Can My Quant interpret evidence without a separately curated analytical worldview? Can Lord Business orchestrate from the current planning cycle and source registry rather than from a giant hard-coded prompt?

There is an even simpler reliability test: when I change one canonical policy, does downstream behavior change without me finding and updating several specialists? If the answer is no, I have only moved the complexity.

That is why I am preserving the old interfaces until the replacement has proved itself. The new architecture should earn deletion of the old one. Otherwise “AI-native” becomes another aesthetic preference rather than an operating improvement.

I also expect some personas to survive. The names are still useful cognitive handles. They create a mode switch. They make an abstract capability easier to remember. They can make the system more enjoyable to use. None of that disappears simply because the architecture underneath becomes less anthropomorphic.

Personification was not the mistake. Confusing the interface with the architecture would be.

The uncomfortable question behind the joke

There is something recursive about laying off a team of AI specialists because automation has made their jobs unnecessary. The joke works because I have spent months deliberately treating these roles as if they were a small operating cast. Now some of the first “employees” I am making redundant are synthetic employees I invented myself.

But the reason I find the experiment interesting is not the joke. It is the possibility that the human-team metaphor helped me begin precisely because it concealed how much human organizational logic I was importing.

Human organizations need specialists for good reasons. Expertise is distributed. Context sits in different heads. People cannot instantly switch disciplines. Knowledge moves through documents, meetings and handoffs because the people receiving the work were not present for everything that came before. Management and coordination exist partly because human cognition is scarce, local and difficult to synchronize.

AI has its own constraints, and some are severe. But they are not identical. A capability can retrieve a shared source at runtime. Several methods can operate against the same state. A policy can potentially be changed once and become available to every compliant workflow. Specialized reasoning does not necessarily require a persistent specialist identity.

I developed the enterprise version of this concern earlier in AI Agents Are Not Digital Employees. The personal experiment has now caught up with that argument in an uncomfortable way: my own supposedly AI-native system had started reproducing the organization it was meant to transcend.

That does not tell me what the company of the future looks like. A personal workflow cannot prove an enterprise operating model. It does give me a better question to test.

Take one workflow where you use several GPTs, agents or specialist assistants. Ignore their names for a moment. Look at every handoff between them and ask why that boundary exists.

Does the work genuinely require a different capability, permission or judgment model? Or did you create the boundary because a team of synthetic people was the easiest architecture to imagine?

I built an AI team because it was the easiest way for me to understand AI at work. Now I am testing whether the specialization survives when I remove parts of the synthetic organization around it.

If it does, I will not really have fired my AI specialists. I will have promoted their capabilities out of the org chart.