Where skills don't run at all: Bedrock and Vertex

Why you'd careThe problem it solves

You built a document-generation path on skills. It works: one request, a container, a .pptx back. Then an enterprise customer says their security posture requires everything to run in their AWS account, and could you repoint it at Bedrock. You start looking for the equivalent parameter and find nothing — no container, no code-execution tool version that works there, and no Files API to fetch the output with even if the first two existed. This does not read like a feature you have not enabled yet, because it is not. Three things your path depends on are all missing, and they are missing for one shared reason. Understanding that reason is what tells you whether to wait, work around it, or point the customer at a different AWS product they have probably not heard of.

ConceptWhat it is

There is a dependency chain, and it is short. A skill's instructions load into context, but its scripts and assets need somewhere to live and something to run them. That somewhere is the sandboxed container Anthropic provisions for the code-execution tool. No code execution means no container; no container means nowhere to stage skill files. Skills are therefore not an independent capability that a platform could ship on its own — they sit on top of one that Bedrock and Vertex do not carry.

The reason those two do not carry it is operational, not technical. Both are partner-operated: AWS and Google run the service, on their own release schedules, exposing a subset of Anthropic's API. Core inference, streaming, tool use, thinking, caching, and PDF input are all there. The server-side tools that need Anthropic-hosted infrastructure — code execution, web fetch, and on Bedrock also web search — are not, and the Files API is absent on both, which removes the retrieval half of any document pipeline as well.

The distinction that matters most here is that Amazon Bedrock is not the only way to run Claude on AWS. Claude Platform on AWS is a separate, Anthropic-operated product reached through AWS infrastructure, with same-day API parity. It is the same cloud and a different product, and it carries skills.

How it worksThe mechanics

Each layer of the path fails on Bedrock and Vertex for the same root reason:

• SkillsAgent Skills on the Messages API is unavailable on both.
• Code executionunavailable on both, which is why the layer above cannot exist.
• Files APIunavailable on both, so even a container that produced a file would leave you no documented way to download it.
• Managed Agentsunavailable on both, closing the other route to skills.

Telling the two AWS products apart is a code-level check, not a documentation question. The client class and the model ID both differ:

# Amazon Bedrock -- partner-operated. Prefixed model IDs. No skills.
from anthropic import AnthropicBedrockMantle
client = AnthropicBedrockMantle(aws_region="us-east-1")
client.messages.create(model="anthropic.claude-opus-5", ...)

# Claude Platform on AWS -- Anthropic-operated. Bare model IDs. Skills at beta.
from anthropic import AnthropicAWS
client = AnthropicAWS()   # needs AWS_REGION and ANTHROPIC_AWS_WORKSPACE_ID
client.messages.create(model="claude-opus-5", ...)

Three markers, any one of which identifies the surface: the client class name, the anthropic. prefix on the model ID, and the endpoint host — bedrock-mantle for Bedrock, aws-external-anthropic for Claude Platform on AWS. If someone hands you a codebase and says "it runs on AWS", check the model string before you conclude anything about feature availability.

Microsoft Foundry sits between the two extremes and is the case most likely to be mis-summarised. Agent Skills on the Messages API and the Files API are listed as beta there and code execution as available, all three on a Hosted on Anthropic deployment only, so the stateless skills path works. Managed Agents is not available, so the Agent path does not — and that is documented outright: “Claude Managed Agents” is named in Foundry's own list of features not supported, so it is a confirmed "no" rather than an inference.

At a glanceSee it

Skills depend on code execution, so they exist exactly where the container does and nowhere else.

Where it runsSurfaces and availability

The practical read: “runs on AWS” and “runs on Bedrock” are different requirements, and customers usually mean the first. If the ask is AWS-native IAM and Marketplace billing, Claude Platform on AWS satisfies it with the skills path intact. Bedrock is a genuine dead end for the API-side feature — not a beta you can be allowlisted into, since it does not accept the beta header at all — so plan around it rather than waiting. But the page's title oversells the conclusion in one direction worth naming: skills are not absent from Bedrock and Vertex, only the container-based ones are. Claude Code and the Agent SDK read local SKILL.md folders on every provider, which means a team blocked from container.skills on Vertex can still ship skill-driven workflows through the harness. Choose by which mechanism the work needs — a server-side document pipeline is genuinely blocked; a developer-facing agent is not.

ExampleIn the real world

A vendor sells a reporting product. Its export path is one Messages API call with the xlsx skill, the code-execution tool, and a Files API download at the end. A bank signs, and procurement requires that inference run under the bank's AWS account.

The first attempt is a Bedrock client swap. It fails at the first request: container is not accepted, and even removing it leaves no code-execution tool version that works, and no Files API to retrieve an output with. Nothing here is a permissions problem, so there is no ticket to file with AWS.

The engineer checks what the requirement actually was. Procurement wants AWS IAM controlling access and AWS Marketplace handling billing — it never said Bedrock. Claude Platform on AWS delivers both, is Anthropic-operated with same-day parity, and carries Agent Skills, code execution, and the Files API. The migration is a client class change from AnthropicBedrockMantle to AnthropicAWS, setting AWS_REGION and ANTHROPIC_AWS_WORKSPACE_ID, and dropping the anthropic. prefix from the model ID. The export path itself is untouched.

Had procurement genuinely required Bedrock specifically, the honest answer would have been different: build the workbook with a library on the vendor's own infrastructure and use the model for content only — accepting that the model no longer verifies its own output by running code.

Not thisWhat it is often confused with

• Not a quota or an allowlistthere is no beta programme to join, no header to add, and no rate limit to raise. The parameters do not exist on those endpoints.
• Not a model capabilitythe same model ID that generates decks on the first-party API cannot on Bedrock. This is a platform feature boundary, not something the weights do or do not know how to do.
• Not the same as Claude Platform on AWSBedrock is partner-operated with anthropic.-prefixed model IDs and a reduced feature set; Claude Platform on AWS is Anthropic-operated with bare model IDs and parity. Same cloud, two products, opposite answers to this question.
• Not "coming soon"treat it as absent for planning purposes. Anything about a partner platform's roadmap is a point-in-time claim, and building a delivery date on one is how a launch slips.
• Not a Foundry storyFoundry is a genuinely mixed case and does not belong in the same bucket. The Messages API skills path works there; the Managed Agents path does not.

LimitsWhen not to reach for it

• Do not try to emulate the container.Sending the skill's SKILL.md text as a system prompt gets you the instructions without the execution environment or the bundled scripts — the model will describe building a workbook rather than building one. If you go this route, own the file generation yourself with a library.
• Do not accept "it must be Bedrock" without checking.The underlying requirement is usually AWS IAM and Marketplace billing, which Claude Platform on AWS satisfies with skills intact. Ask which of the two the contract actually names.
• Do not port a Managed Agents design to Foundry.Foundry carries the stateless skills path only. If the design depends on persisted Agents and sessions, Foundry is not a target.
• Do not treat Vertex's bare model IDs as a parity signal.Vertex uses first-party-looking IDs with no prefix, which makes it easy to assume first-party features. Check the availability table, not the model string.
• Do not build a multi-cloud abstraction over this gap.A shim that silently degrades from skills to prompting on Bedrock produces two very different output qualities behind one interface. Fail loudly at configuration time instead.

RelatedGo deeper