What happened
On October 29, 2026, Cloudflare announced that Agent Skills in its Agents SDK are now files. The basic workflow is deliberately simple: place a folder containing SKILL.md in a Cloudflare Computer Workspace at /workspace/.agents/skills/, and the agent can use that skill on its next turn. Cloudflare says this requires neither a build step nor a deployment. The announcement also explicitly says an agent can write its own skills, so the workspace is not merely a read-only delivery location for procedures prepared elsewhere.
The release supports three skill sources: a Computer Workspace, an R2 bucket, and code. In an example using @cloudflare/think, an agent’s getSkills() returns both skills.workspace(this.workspace) and skills.r2(this.env.SKILLS_BUCKET, { prefix: "skills/" }). Think lists every source again before each turn. That repeated discovery is consequential: a changed workspace file can enter the agent’s available skill catalog during an ongoing interaction rather than waiting for a conventional packaging cycle.
Cloudflare positions the format as open. Each SKILL.md is checked against the Agent Skills specification. A skill that breaks a rule still loads, following the specification guide’s recommendation, but a warning is logged. For callers that need to validate a skill before writing it, the release points to parseSkill(). Skill scripts live as Workspace files and the model runs them through the Workspace exec tool. Cloudflare also says the same activate_skill and read_skill_resource tools can be used in Think, Pi Durable, or the AI SDK, rather than being exclusive to one harness.
The changes arrive in Agents SDK v0.32.0 and Think v0.23.0 or later. They include warm prompt-cache behavior: when a skill changes mid-conversation, Think sends the new catalog as a reminder instead of rebuilding the cached system prompt. An overridden getSystemPrompt() now remains above context blocks in the system prompt. There is migration work: agents:skills, agents/skills/compile, SkillRegistry, and Think’s skillWorkspace are removed, while runner() has moved to agents/skills/runner.
What the archive adds
This is a new fact on a related Cloudflare Computer story. The earlier Field Note on Cloudflare Computer’s recovery and approval features described replay-based recovery for interrupted runs and application-controlled approval pauses. This release adds a mutable skill layer inside that same workspace-oriented environment: recovery and approval govern a run, while workspace files can now alter the procedures available on a subsequent turn.
Trend signal
The release supports the pattern Skills become a portable capability layer. Cloudflare exposes a SKILL.md format, validates it against the Agent Skills specification, and makes comparable skill tools available across Think, Pi Durable, and the AI SDK. But portability is only part of the operational question: a skill that fails a rule can still load with a warning, and agents can write skills, so provenance and review remain central.
Why now
Cloudflare’s warm-cache design explains part of the timing value. A workspace skill can change during a conversation without forcing Think to rebuild the cached system prompt; it sends a new catalog reminder instead. That makes file-based skills useful for long-running or iterative agent work, where packaging a new release for every procedural adjustment would be slower than the work itself.
Connections to other events
An earlier archive item described Anthropic combining Computer Use, a Skills API, and a Files API for production agents. Cloudflare’s change reaches a similar intersection from the runtime side: a computer-like workspace becomes the place where an agent can act, retain files, and now discover procedural skills. The distinction in the supplied material is that Cloudflare specifies three loading sources and cross-harness tools, not a claim of equivalence between the products.
Why it matters
For a team building on Cloudflare’s agent stack, skills can now be operated as workspace content rather than only as code bundled at deployment. That may shorten the path from an observed failure to a revised procedure: write or update a skill folder, let the next turn rediscover it, and avoid a build-and-deploy cycle. R2 provides a separate distribution option when teams want a bucket-backed skill source.
The same capability changes the control surface. A skill may include scripts that run through Workspace exec, and the agent itself may write skills. Teams should therefore decide who can write to /workspace/.agents/skills/, which changes require review, whether parseSkill() is mandatory before writes, and how warnings are monitored. The release makes procedural adaptation easier; it does not establish that every resulting skill is safe or correct.
What happens next
- Teams using the removed skill APIs will migrate to the new imports and runner path. (3 months, 75%). Watch for: migration guides or issue reports around
agents/skills/runner. - Workspace-level skill governance will become a practical concern for deployments that let agents write skills. (6 months, 65%). Watch for: examples of write validation, approval gates, or restricted workspace permissions.
Limits and uncertainty
The changelog establishes the SDK behavior and names the versions, but it does not provide benchmarks for latency, reliability, or task success after skills change mid-conversation. It does not describe default permissions for writing skills, an approval mechanism for agent-authored skills, or how a team should review scripts before exec runs them. Specification checking is not a safety guarantee: the source says nonconforming skills can still load with a logged warning. Nor does the announcement compare this implementation with other skills systems or state which deployment plans include the relevant services.
Skill to build now
Create a small, versioned skill-writing gate this week. Restrict writes to the workspace skill directory, run parseSkill() before accepting a new SKILL.md, record the writer and change reason, and require a human or policy check before allowing scripts to be executed. Then test a controlled edit during a multi-turn run to confirm that the next-turn catalog update behaves as expected in your harness.
Reader takeaway
Cloudflare has made skills live workspace files: an agent can discover a changed SKILL.md on its next turn without a build or deploy. That can make procedural updates much faster, but it also turns skill authorship, validation, and workspace write permissions into production controls rather than repository hygiene.
Open question
What permission and review model will teams adopt when the same agent that consumes a skill can also write the next version of it?