AWS and Hugging Face published a joint technical guide on September 18, 2026, walking through how to deploy Hugging Face models on Amazon SageMaker AI using six open source agent skills instead of trusting a coding agent's unguided judgment. The post is credited to Hugging Face engineers Dario Salvati and Álvaro Bartolomé, and AWS solutions architects Qiong Zhang and Sanhita Sarkar. The pitch: point a coding agent such as Kiro or Claude Code at a model on the Hugging Face Hub, and get back a real time endpoint with the correct serving container, autoscaling, Amazon CloudWatch alarms, and a verified teardown path, instead of a demo that quietly breaks the moment someone updates a dependency.
The skills live in the huggingface/skills GitHub repository and are free to install. They target a specific failure mode the authors say they observed directly: coding agents that reach for whatever serving stack shows up most in their training data, which for years meant Text Generation Inference (TGI), even after TGI stopped being the right default for newer model architectures.
What AWS and Hugging Face Actually Shipped
The six agent skills are Markdown files that follow the open agent skills standard: a folder with a SKILL.md file containing a description an agent reads on demand, plus instructions and, in most of these, helper Python scripts. According to the AWS post, the skills are open source, use only Python and the AWS Command Line Interface (AWS CLI), and work unchanged on macOS, Linux, and Windows.
The post specifies a real, pinned commit for anyone following along: f3186efbbc322121eb5d0f31e8a1d669ee961159 in the huggingface/skills repository. Real time inference is the default deployment path the skills produce, but AWS says they also support real time with scale to zero, serverless inference, asynchronous inference, batch transform, and Amazon Bedrock Custom Model Import.
Why Deploying Hugging Face Models Went Wrong Without Skills
To make the case for the skills, the authors ran a controlled comparison. They tested both Kiro (using Auto or Claude Fable 5) and Claude Code (using Opus 4.8) on the same request: deploy the small Qwen/Qwen3-0.6B model to a real time endpoint, write the plan to a file, and log every action.
Both agents initially picked TGI as the serving container, a reasonable guess given years of tutorials defaulting to it, but the AWS Region's available TGI build predated the Qwen3 architecture and the endpoint failed its health check. The agent bumped the TGI version, redeployed, failed again, then switched to vLLM, a detour that billed GPU time on each failed attempt. A companion Hugging Face community post from July 7, 2026, covering what appears to be the same underlying experiment, put a number on that detour: roughly 80 minutes and four failed endpoint attempts before the switch to vLLM landed.
The second test was worse in a quieter way. Asked to deploy a newly released multimodal mixture of experts diffusion model, the unguided agent confirmed the model existed and wrote a deployment script still built on TGI, a text generation server with no backend for that architecture. Nothing failed loudly. AWS says you would only discover the problem when the endpoint refused to come up.
AWS published a side by side comparison of the same request run with and without the skills installed:
How the Six Skills Divide the Work
One skill, hf-cloud-sagemaker-deployment-planner, orchestrates the other five and asks the user only what it needs to know. The remaining five each own one phase of the deployment:
- hf-cloud-aws-context-discovery: resolves the active AWS profile, Region, account, and caller identity with read only calls
- hf-cloud-python-env-setup: builds an isolated Python environment, explicitly restricted to Python 3.10 through 3.12, since AWS says Python 3.13 and later still lack working wheels for much of the machine learning stack
- hf-cloud-sagemaker-iam-preflight: searches the AWS account for an existing SageMaker execution role before attempting to create one, since corporate IAM Identity Center sessions frequently lack
iam:CreateRolepermission - hf-cloud-serving-image-selection: picks the correct container family (HuggingFace vLLM for most LLMs, vLLM-Omni for multimodal, TEI for embeddings, the HF Inference Toolkit for other transformer models) and resolves a current image URI from the AWS Deep Learning Containers catalog rather than hardcoding one from memory
- hf-cloud-sagemaker-production-defaults: creates the model, endpoint configuration, and endpoint as a unit, then attaches autoscaling and alarms
In the walkthrough, the image selection skill resolved the Qwen3-0.6B deployment to 763104351884.dkr.ecr.us-east-1.amazonaws.com/huggingface-vllm:0.28.0-transformers5.15.0-gpu-py312-cu130-ubuntu24.04, running on a single ml.g5.xlarge instance in US East (N. Virginia), which AWS lists at $1.408 an hour per instance. The production defaults skill attached autoscaling with a minimum of one and a maximum of four instances, plus three CloudWatch alarms covering 5XX errors, model latency, and overhead latency.
AWS also flags a real IAM tradeoff: when the skill does create a new execution role, that role carries the broad AmazonSageMakerFullAccess policy, and the post recommends narrowing it to least privilege afterward rather than leaving it as shipped.
What the Agent Handled on Its Own
Two moments in the AWS walkthrough weren't scripted into the skills directly. When the agent's IAM Identity Center role was denied permission to query Amazon ECR for the newest image tag, it fell back to a known good tag the skill ships as a safety net and logged why. After the smoke test returned an HTTP 200, the agent noticed the actual model reply had been truncated inside Qwen3's reasoning block at the token limit, and flagged it as a configuration issue for the calling application rather than reporting a false pass.
Why It Matters
The skills are worth watching less for what they deploy and more for what they encode: current, perishable operational knowledge (which serving container is current, which Python version has working wheels this month) that goes stale inside a model's weights the moment a container catalog updates, but stays current when it lives in an editable file instead. That is the same argument behind Anthropic's own Claude Code skills and behind AWS's broader push into agent tooling this year, including the managed OAuth consent portal it shipped for Bedrock AgentCore and the way Abnormal AI put AgentCore's Code Interpreter into production for its own agents.
One pattern worth flagging: this is a vendor collaboration post, not an independently benchmarked claim. Both companies have a direct commercial interest in coding agents succeeding on their platforms, and the underlying test appears to be a more polished, jointly published version of a case study Salvati first posted to Hugging Face's own community blog in July, this time co-branded with AWS and dated to the day of publication. None of that makes the technical detail wrong. The container mismatches, the IAM permission failure, and the token truncation catch all read as specific, plausible engineering observations rather than marketing language. But readers should treat the framing (an unguided agent as a strawman versus a skills equipped one) as a vendor's demonstration, not a third party evaluation.
It is also worth noting the claim, sourced to Hugging Face's own internal agent usage dataset, that Claude Code running Opus 4.8 is the agent most people currently use to work with Hugging Face. That is Hugging Face's data about its own users, not an independently audited figure, and BriefFlash has not seen the underlying dataset made fully public.
What to Watch
Watch whether the six skills get picked up outside Hugging Face's own tooling. The GitHub repository already lists compatibility with Claude Code, Codex, and Gemini CLI, with Cursor, Windsurf, and Continue support described as in progress, which would meaningfully widen the audience beyond Kiro users if it ships. Also watch whether AWS or Hugging Face publishes any real world cost or reliability data from teams using the skills in production, since the case for them so far rests on one internal before and after comparison rather than aggregated usage across customers.
Key Takeaways
- AWS and Hugging Face published six open source agent skills on September 18, 2026, for deploying Hugging Face models on Amazon SageMaker AI
- The skills are pinned to commit f3186efbbc322121eb5d0f31e8a1d669ee961159 in the huggingface/skills GitHub repo and work with Kiro and Claude Code today
- In AWS's own test, an unguided coding agent defaulted to the outdated TGI container and failed multiple times before switching to vLLM; the skills equipped agent picked vLLM correctly before creating any resource
- The default deployment (a single ml.g5.xlarge real time endpoint) bills $1.408 an hour per instance, and the skills attach autoscaling (1 to 4 instances) and three CloudWatch alarms by default
FAQ
How do you deploy a Hugging Face model on Amazon SageMaker?
AWS and Hugging Face's guide covers one path: install six agent skills from the huggingface/skills GitHub repo into a coding agent like Kiro or Claude Code, then describe the model you want deployed in plain language. The planner skill discovers your AWS context, resolves an execution role, picks the correct serving container and image URI, then creates the model, endpoint configuration, endpoint, autoscaling, and CloudWatch alarms. Outside this agent skills workflow, Hugging Face models can also be deployed to SageMaker through SageMaker JumpStart in the console or the SageMaker Python SDK directly.
What is Hugging Face and why is it used?
Hugging Face is a platform and community hub for sharing, discovering, and deploying machine learning models, datasets, and demo apps, commonly called the Hugging Face Hub. It's used because it centralizes access to a large number of open source and openly licensed models, along with tooling (like the skills covered in this article) that helps developers move a Hub model into a production environment such as Amazon SageMaker AI.
How do I deploy my own Hugging Face model using these agent skills?
Per AWS's walkthrough, you need an AWS account with SageMaker permissions and an execution role, AWS CLI v2 configured with credentials, Python 3.10 through 3.12 (3.13 and later aren't supported yet), a coding agent that supports skills, and Git to clone the skills repository. From there you install the six skills and give the agent a plain language deployment request; the skills handle container selection, IAM role discovery, and production defaults automatically.
Do these agent skills work with coding agents besides Kiro and Claude Code?
AWS's walkthrough uses Kiro IDE, and its comparison test also ran on Claude Code. The huggingface/skills GitHub repository separately lists compatibility with Claude Code, Codex, and Gemini CLI, with Cursor, Windsurf, and Continue integrations listed as in progress as of this writing.
