AWS AI/ML skill joins Agent Toolkit: setup and resource costs

A unified skill entry point with broader SageMaker coverage

On October 13, 2026, AWS announced that aws-ai-ml is a core skill in Agent Toolkit for AWS, alongside skills for services such as EC2 and Bedrock. A skill is a package of task instructions and reference material an agent can load as needed. It helps an existing coding agent work with cloud services; it is not another model release.

The announcement lists inference optimization, model customization, serverful training for traditional machine learning and generative AI, MLflow tracking, JumpStart model deployment and recommendations, and data preparation or ETL processing on managed compute. Available actions still depend on tools, account permissions and the target resources.

The October 5 official blog already described installing the inference-optimization skill and using benchmark workflows. The October 13 announcement establishes the unified entry point and expanded coverage. Performance examples in the earlier blog are not newly measured gains from this announcement.

AWS Labs tools do not need to be stopped immediately

The announcement describes the toolkit as the single supported integration point replacing previous AWS Labs skills and plugins. The current official README also states that AWS Labs MCP servers, skills and plugins will continue working and accepting contributions, with capabilities moving into the toolkit over time.

Use the toolkit as the recommended entry point for a new setup without treating the announcement as a shutdown or same-day migration requirement. Review your existing tools and required capabilities before replacing them. The sources provide no common cutoff date or automatic migration promise.

Local setup: provide the skill, then check permission

First, prepare AWS CLI 2.35+ and uv for the CLI route described in the October 5 blog, then read the current README for your agent. It lists Claude Code, Codex, Cursor, Kiro and fx without guaranteeing every client version, operating system or Region.

Next, the blog’s toolkit setup command is aws configure agent-toolkit. This route detects agents, installs skills and configures the AWS MCP Server. Follow the README’s client-specific setup rather than applying one plugin installation method to every agent.

Then add the targeted skill using the explicit blog command: npx skills add aws/agent-toolkit-for-aws/skills/aws-ai-ml. Ask your agent which skills are available and confirm it can discover aws-ai-ml before beginning a specific task. These are source instructions; no command or account was tested for this article.

MCP is an interface between an agent and external tools; local skills are task guidance read from files by the client. The current README separates them: skills do not require the MCP server, and the server does not serve locally installed skill files. AWS API calls and cloud script execution still require configured credentials authorized for the intended resources and actions.

Studio preinstallation requires the right private space and image

The October 13 announcement says the skill is preinstalled in SageMaker Studio JupyterLab. The more specific October 5 instructions say to enter Studio in the target account and AWS Region, create a fresh JupyterLab space, retain the Private sharing setting, and select the preconfigured image containing the inference-optimization skill.

The blog warns that a reused space with a locally modified skill may not pick up the preconfigured image, and skill synchronization requires a Private space. Preinstallation is not proof that every existing or shared space, or every image, has automatically updated.

Once the space starts, authorize the coding agent you use and check available skills. Kiro is the official example; its sample login parameters and Region do not define eligibility for every customer. Match your existing identity provider, account policies and target Region.

The skill is free; execution and retained resources can cost money

AWS says the skill carries no additional charge while resources used by agents remain billable. The inference blog also explains that a benchmark sends real traffic to a live endpoint. Before running one, confirm that the target may receive that load and review the generated SageMaker Python SDK v3 code, budget and resource scope.

Hypothetical, unexecuted example: a team wants to compare two instance configurations. First ask the agent to organize required inputs and candidate test code, then decide whether to authorize execution against the specified endpoint. Keep the model and workload fixed and compare latency, throughput and cost. Generated code or a faster result does not by itself establish production improvement or lower spending.

Afterward, clean up only resources created for the task that are confirmed to be no longer needed. The official blog lists test endpoints, the JupyterLab space and S3 benchmark or recommendation objects. Check ownership and retention needs before stopping or deleting anything, so active work is not mistaken for a test leftover.

Skill discovery and successful execution are separate checks

Check three layers: whether the agent reads aws-ai-ml, whether required tools are configured, and whether the account permits the planned actions on the specified resources. Installation addresses only the first part; it does not replace API permissions, quota, capacity or output checks.

The sources do not provide an exhaustive Region list, account-plan matrix, minimum version for every client, or a universal skill update command. Use the current official README and your chosen setup route, then verify missing conditions individually. A sample Region, an older Studio interface’s availability list or a single plugin install does not establish complete availability.