The most underrated product surface in AI is the setup script.
Not the dashboard.
Not the chat window.
Not the landing page where every company says agents will transform work.
The setup script.
That is where the promise either becomes infrastructure or dies as a demo.
Every serious builder has felt this. You install the tool. You add the MCP server. You paste a config into Claude. Then Cursor needs a different shape. Codex has its own file. VS Code wants another location. Windsurf and Zed are close, but not close enough. ChatGPT needs a connector flow. Auth works in one client and fails in another. The docs are technically correct. Your night is still gone.
Then the product asks you to believe it can coordinate your company.
That is a hard sell.
The First Five Minutes Are the Real Demo
Most AI products demo the happy path.
A prompt turns into a plan. A plan turns into tasks. An agent writes a thing. A dashboard updates. Everybody nods.
But the first real user experience happens before any of that.
Can this system get into the tools I already use?
Can Claude, Cursor, Codex, VS Code, Windsurf, Zed, and ChatGPT reach the same company memory?
Can auth complete without a treasure hunt?
Can the setup tell me what is actually broken?
Can I remove it cleanly if I need to?
If the answer is no, the product has already taught the user something dangerous: this is another fragile AI integration that will create more operational drag than it removes.
That is why we built OrgX Wizard.
The Problem Is Not Configuration
Configuration is the symptom.
Continuity is the problem.
An AI-native company now has work happening across multiple surfaces. Claude for judgment. Cursor for code. Codex for implementation. ChatGPT for reasoning. VS Code for local work. Browser-based tools for docs, support, and memory.
Each surface is useful on its own. The failure starts when each one becomes a separate room.
One room knows the strategy. Another knows the repo. Another knows the task. Another knows the decision. Another knows nothing, because the MCP config never actually loaded.
The founder becomes the router again.
"Let me catch you up."
"Here is the workspace."
"Here is what we decided."
"Here is the initiative."
"Here is why that previous artifact matters."
That is the continuity tax in its most boring form: setup friction that becomes organizational amnesia.
A Setup Script Is a Trust Contract
The bar is not "write a config file."
The bar is: make the system legible.
OrgX Wizard does a few practical things:
- detects supported local AI surfaces
- writes OrgX MCP entries into the right client configs
- opens browser pairing for OrgX auth when a key is not already present
- resolves API keys from environment, wizard auth storage, or OpenClaw config
- guides workspace selection or creation
- installs the right companion plugins, rules, and skill packs without duplicating assets each tool already owns
- persists continuity defaults like workspace, review surface, and execution mode
- runs
doctorso setup does not end with vibes - removes OrgX-managed entries cleanly when you uninstall
That list sounds tactical.
It is not.
It is the difference between "we have an AI orchestration product" and "your existing tools now have the same path into company memory."
The Opinion Is the Feature
Most setup flows are polite wrappers around uncertainty.
They ask where your config lives. They ask which client you use. They hand you a snippet. If something fails, they leave you in a GitHub issue thread or a Discord search.
OrgX Wizard is more opinionated.
It knows the surfaces it supports. Claude, Cursor, Codex, OpenClaw, VS Code, Windsurf, Zed, and the manual ChatGPT connector path are not treated as one generic bucket. They have different rules, different config locations, and different failure modes.
It knows local and hosted MCP are different surfaces.
It knows Cursor often needs the local OpenClaw bridge while Claude and Codex can use hosted OrgX MCP when the client supports it.
It knows a companion plugin should own certain skills so the wizard does not install duplicate assets.
It knows hosted MCP tool calls are OAuth-scoped inside the client, so the wizard should not pretend it can preflight every hosted tool with an oxk_ API key.
That last point matters.
A weak setup script hides the boundary.
A good one tells you exactly where verification stops.
What doctor Changes
The most important command may not be setup.
It may be this:
npx @useorgx/wizard@latest doctorBecause "installed" is not the same as "usable."
doctor checks local config, hosted MCP reachability, npm readiness, current-workspace connectivity, local OpenClaw health when present, and blocking setup problems. It exits non-zero when something actually prevents work from happening.
That is a different product posture.
Not "the config file exists."
Not "try restarting the client."
Not "it should work."
It tells you whether the path from your tool to OrgX is alive enough to trust.
For developer tools, that is the line between novelty and adoption.
Why This Belongs in the Product Story
It is tempting to bury a CLI in the docs.
That would be a mistake.
The wizard is not an implementation detail. It is the product story compressed into a terminal session.
OrgX is not trying to become another place where work happens.
OrgX is trying to make the tools you already use coherent.
That promise has to start with onboarding.
If a founder or developer can run one command, pair auth, select a workspace, wire the local tools, and run a doctor check, the category starts to feel different.
Not another dashboard to babysit.
Not another chat wrapper.
Not another SaaS login with a demo video.
Infrastructure that attaches continuity to the tools already open.
The Quiet Product Decision
There is a small design decision in OrgX Wizard that says a lot about how we think.
It changes local tool configuration.
It does not pretend to own your repo.
It does not hide what it writes.
It does not erase non-OrgX config.
It can remove the entries it manages.
That restraint matters because the buyer is not asking for magic. The buyer is asking for leverage they can inspect.
AI products love to talk about autonomy.
Developers trust reversibility.
Try It
If you want the shortest path from "I keep re-explaining context to every AI tool" to "my tools can reach the same operating graph," start here:
npx @useorgx/wizard@latest setup
npx @useorgx/wizard@latest doctorIf setup fails, that is signal.
If doctor fails, that is even better signal.
It means the system is telling you what still blocks continuity instead of letting the failure appear three hours later as a dead agent run, a missing tool call, or another founder typing "let me catch you up" into a fresh session.
That is the point.
The company should remember.
The tools should connect.
The first five minutes should prove both.