Will Dots Replace Claude Code Skills, or Just Sit Beside Them?

Whenever a major lab ships a more capable, more autonomous agent, the reflexive question in developer circles is whether it makes some smaller, more composable tool obsolete. OpenAI's dots — an agent with its own cloud computer, standing access to 4,000+ connected apps, and the ability to keep working after you close the chat window — is exactly the kind of launch that invites that question about Claude Code Agent Skills, the composable, git-versioned capabilities you install into an agent you already run.

The honest answer is that they're not the same layer of the stack, and treating them as competitors misreads what each one actually is.

What a dot is, structurally

A dot is an agent, not a capability. It has its own identity, its own credentials, its own cloud computer, and — per OpenAI's own description, also noted in PYMNTS' coverage of the launch — the ability to keep operating after the human who tasked it walks away. You don't inspect a dot's source the way you'd inspect a file; you configure it through Custom Rules, watch it through an Activity View, and trust the review layer OpenAI built around it, covered in an earlier article in this series. It's a product you subscribe to and grant access, in the same category as hiring a very fast, very literal contractor.

What a skill is, structurally

A Claude Code Agent Skill is the opposite kind of object. It's not an agent — it's a scoped, inspectable set of instructions and tools that you install into an agent you're already running, one you already trust at the base level because you chose the model and you're the one invoking it. A skill doesn't get its own cloud computer or standing background access; it activates when its description matches what you're doing, does one job, and stops. You can read its source before you install it, because it's a file, not a subscription. You can version it, fork it, or delete it with a single command, because it lives in your repo, not in a vendor's cloud account.

That's the structural gap: a dot is a standing grant of autonomy to a system you don't fully see inside. A skill is a narrow, revocable capability added to a system you already control. They answer different questions. "Who do I trust enough to let it act on my behalf, continuously, across my tools, while I'm not watching?" is dots' question. "What does this specific task need that my agent doesn't already know how to do?" is Claude Code skills' question.

Where they'd actually compete — and where they don't

There is a narrow band of overlap worth naming honestly. OpenAI's own use-case examples — a developer's dot watching customer feedback and returning pull requests, or a content team turning a transcript into a week of posts — sound, on the surface, like things a well-built skill could also help a human-directed agent accomplish, just without the "always-on, unsupervised" part. If your actual need is "run this specific workflow every time I invoke it," a skill can do that job today, invoked deliberately, inspectable end to end, at zero incremental subscription cost beyond the model you're already paying for.

Where they diverge sharply is autonomy without invocation. No skill runs itself while you're asleep. No skill decides, on its own initiative, that something changed and a task needs doing. That's dots' actual differentiator, and it's not something the skills model is trying to replicate — by design, not by limitation. Claude Code's whole trust model rests on the human deciding when the agent acts; dots' whole pitch rests on the agent deciding that for itself, within the boundaries Custom Rules allow.

A dot replaces a decision about when to act. A skill replaces a decision about how to act. Those aren't the same decision, and a product built around one doesn't obsolete a product built around the other.

The honest case for both existing

Someone running a small engineering team could plausibly want both, doing different jobs. A dot watching customer feedback around the clock, flagging patterns a human should look at — genuinely useful, genuinely something a periodically-invoked tool can't do. And, separately, a set of Claude Code skills doing the deliberate, inspectable, versioned work of the actual engineering — code review conventions, deployment checklists, domain-specific analysis — where the value is precision and auditability, not standing autonomy.

The failure mode to watch for isn't dots replacing skills. It's the opposite temptation: treating an always-on agent's convenience as a reason to stop caring whether the specific capabilities it exercises are inspectable at all. A dot that's cleared to touch your CRM, your codebase, and your Slack is exercising a lot of capability continuously, and "trust the vendor's Custom Rules" is a coarser unit of oversight than "read the skill before you install it." The two products aren't in a zero-sum fight for the same budget line — but they represent two very different philosophies about how much of an agent's behavior you should be able to see before it happens, and that's worth thinking through deliberately rather than defaulting to whichever one shipped the flashier keynote.

For anyone deciding where to draw that line for their own team, the practical test is simple: if you can name exactly what you want done and when, a skill gets it done with full visibility. If what you actually want is a standing watch over something that changes unpredictably, that's the job dots — or Grok Bot, or Muse — is built for. Most real teams will end up wanting both, for different halves of their work, rather than picking a side.

Part 26 of 30 in the ChatGPT Dots series. Previously: The dot.com Troll: What xAI's Stunt Reveals About the Agent Land Grab. Next: Pricing the Unpriced: What Additional Dots Probably Cost. Browse more builder insights or explore AI skills at aiskill.market.