An AI plugin can be useful and still be the wrong place for an important decision.
I added an orchestration setup to one of my projects. Its job was to decide when the main agent should work alone, when it should delegate, and which kind of model should handle each task.
It worked.
Routine searches could go to a faster model. Architecture and security decisions stayed with the stronger one. Independent audits could run in parallel. The main agent kept the final review.
That was exactly why the problem was easy to miss.
The orchestration was useful, but too much of the project's workflow had started to belong to the tool providing it.
Capability is not policy
A plugin can provide capabilities.
It can create subagents, select models, run tasks in parallel, record outcomes, and expose useful commands.
Those are valuable features.
But the plugin should not decide what the project considers risky, who owns the final review, when a release is allowed, or which checks must pass before something is called complete.
Those are project decisions.
The difference matters because capabilities can change quickly. A model gets renamed. An extension adds subagents. Another tool handles parallel work differently. A local memory format disappears.
The project's standards should survive all of that.
The dependency was deeper than it looked
At first, the orchestration setup only seemed like a convenient layer around the work.
Then we looked closer.
The canonical instructions named specific models. Local outcome data lived under a tool-specific directory. Some validation checks required OpenAI metadata to exist. Parts of the documentation described Codex as if it owned ongoing project responsibilities.
Removing the tool would not only remove a convenience.
It could change how the project was managed.
That is too much authority for an integration.
A project should not forget its review standards because someone opened it in a different editor or used another agent.
The repository should remember
We moved the real orchestration rules into the repository.
The project now defines its own principles:
When is delegation useful?
Which decisions must stay with the accountable lead?
Which risks require stronger review?
What can run in parallel?
Which operations must remain sequential?
What evidence is required before work is accepted?
These rules are version-controlled beside the code and documentation they protect.
They can be reviewed in a pull request. They travel with the repository. A human can read them. An agent in a desktop app can follow them. The same agent in VS Code can follow them. Another compatible tool can implement them without having to reconstruct the project from old conversations.
The repository becomes the source.
The AI becomes a participant.
Project-specific does not mean vendor-specific
A generic orchestration plugin cannot know the shape of every project.
In this project, the application, marketing website, and shared documentation live in separate repositories. Push, release, and deployment are separate operations. Some workflows may run in parallel. Others must remain sequential because they touch shared state.
Those constraints are not generic AI behavior.
They are part of the project.
A project-specific skill gives the agent an entry point into that context. It tells the agent where the canonical policy lives, when to use it, and which deterministic commands remain authoritative.
But it does not need to belong to one vendor.
The skill can describe risk, responsibility, independence, and evidence without naming a particular model.
That is the useful boundary.
The adapter can stay
We did not remove the Codex integration.
We made it optional.
The project policy now describes work in tool-neutral terms. The Codex adapter translates those terms into the models and subagent features currently available.
Another tool could provide another adapter.
If an adapter is missing, the project still works. The main agent performs the task itself and follows the same review rules. The work may be less parallel, but it is not less governed.
The adapter improves execution.
It does not own the workflow.
Portability should be tested
It is easy to call something tool-independent in documentation.
That is not enough.
We added a simple test: remove the OpenAI adapter and verify that the core project workflow still passes.
It does.
We also test the opposite case. If the adapter exists but is malformed, validation fails.
That proves the boundary from both directions.
The adapter is optional.
The project rules are not.
The tool can change
AI tooling is moving too quickly to make one integration the permanent home of a project's operating model.
Plugins will improve. Models will change. Editors will add new capabilities. Some tools will disappear.
That is normal.
The mistake is letting those changes carry the project's memory away with them.
A good integration should make the workflow faster while it is present.
A good project should still know how to work when it is gone.
The tool can change.
The project should not forget how it works.