The "CLI first, then Skills, then MCP" rule of thumb has been floating around agent communities long enough to calcify into conventional wisdom. jngiam's post from yesterday pushes back, and the pushback is hard to argue with.
The argument isn't that one primitive is better. It's that ranking them at all misframes what each one does. Skills are process knowledge — the domain quirks, validation logic, and judgment calls that no vendor ships pre-configured. CLIs are for developers in build mode, where Unix composability and piping matter. MCPs are for authenticated SaaS access, background agents, and anywhere OAuth, audit trails, and scoped permissions are non-negotiable.
The author's own configurations are the most concrete thing in the piece. Personal setup: 12 skills, a few CLIs, 4 MCPs. Work setup: 16 skills, 10+ MCPs with OS-level sandboxes, barely any CLIs. The inversion isn't accidental — enterprise environments have non-developer users, compliance requirements, and agents running on cron schedules that nobody is watching.
That last point is where the case for MCPs gets sharpest. The post describes three named background agents — Max, Charlie, and Dan — each scoped to exactly the tools they need across Attio, LinkedIn, Outlook, and GitHub. When an agent runs unsupervised overnight, access control isn't optional. MCP's OAuth support and its uniform list_tools/run_tool interface make per-session scoping tractable in a way that stitching CLIs together never could. MCP gateways are already extending this with fleet-level control planes and fine-grained permission management — none of which has a CLI equivalent.
The point that gets the least attention is Skills and who can actually use them. A CLI hits a wall the moment someone without a terminal needs it. Skills are a text file — no installation, no PowerShell, no package manager. For mixed teams where only half the room is technical, Skills are the only primitive that works without an engineering background.
That distinction is about to matter more. Enterprise agent deployments are moving past the developer-native phase — the first wave of teams that built agents for themselves, by themselves. The next wave is org-wide, and the primitives that survive that transition are the ones that don't require a terminal session to configure. jngiam's framework gives a clear answer: Skills scale to the whole org, MCPs handle the security layer, CLIs stay in the hands of the developers who still want them. That's not a hierarchy — it's a division of labor.