An AI agent can sound convincing and still fail at the job it was hired to do. Teaching it to select the right tool, follow a company’s workflow and recognize a successful outcome requires more than access to a capable model. For teams customizing models themselves, it can also mean managing the expensive computing infrastructure behind every experiment.
Amazon Web Services (AWS) is targeting that second problem with training sessions, a new capability in Amazon SageMaker AI, its platform for developing and deploying machine learning models.
The company announced general availability on October 22, letting developers control how an existing model learns while AWS operates the GPUs.
Developer teams/users write the training procedure and define how to measure success; SageMaker allocates computing resources, coordinates work across processors, recovers from failures and saves training progress.
For enterprises developing specialized agents, the appeal is a combination of flexibility and reduced operational work. A team can experiment with its own feedback mechanisms without also building the infrastructure to run them. Whether that produces a better or cheaper model still depends on the task, training data and evaluation.
What changes from existing SageMaker customization
SageMaker has supported fine-tuning for years. AWS documented Llama 2 customization through JumpStart in September 2023, using either a visual interface or its Python SDK.
Developers could also bring their own training scripts to SageMaker Training Jobs. That provided extensive flexibility, with AWS provisioning and managing the machines, but left customers responsible for choices such as instance types, training environments and distributed-training configuration. Custom training logic itself is therefore not new to SageMaker.
AWS added serverless customization in December 2025. Teams could select supported models and training techniques while AWS chose the computing resources. The company says managed multi-turn reinforcement learning also predates today’s release.
Training sessions combine more granular programming control with that serverless approach. Developers direct individual operations—generating responses, calculating updates and applying them—through API calls, while AWS manages the GPU execution. Their code can change the sequence, define custom learning objectives and combine training stages.
The advance is a new way to run customized post-training with less infrastructure configuration. It expands the flexibility of AWS’s serverless offering; it does not introduce fine-tuning or reinforcement learning to SageMaker for the first time.
That flexibility matters for agents whose success depends on several actions. An internal support agent, for example, might consult documentation, inspect an account and choose an escalation path. Its training could reward successful resolution while penalizing unauthorized actions.
AWS’s announcement describes both Low-Rank Adaptation (LoRA), which trains relatively small additions to a model, and full fine-tuning, which updates all its parameters, within the broader serverless offering. The current sessions cookbook demonstrates LoRA, and the blog does not map both approaches to every model. Both adapt pretrained models.
How the training loop works
AWS divides the work between the customer’s code and its managed service.
The customer’s software directs the experiment, connects the agent to tools or simulated environments, and scores its behavior. SageMaker performs the intensive computations needed to generate responses and update the model.
AWS illustrates this with Group Relative Policy Optimization (GRPO): the model produces several answers to a prompt, the customer’s scoring function evaluates them, and the training service uses their relative scores to guide an update. The process repeats with the revised model.
AWS’s training cookbook explains that the model remains in GPU memory between operations. Developers can pause to inspect results and adjust the procedure, while reinforcement-learning experiments can generate responses without requiring a separately deployed inference endpoint.
The cookbook supplies examples for chat fine-tuning, mathematics, programming and preference learning. AWS also says it provides agent skills to help coding assistants handle tasks across preparation, training, evaluation and deployment, with support for Kiro, Claude Code, Codex and GitHub Copilot.
Those aids do not remove the need for technical judgment. The customer still needs to decide what the model should learn, whether its rewards encourage the intended behavior, and whether improvements survive testing on unfamiliar examples.
Early customers target claims and tool use
AWS identifies ImagineSoftware and Karini AI as early adopters.
ImagineSoftware used the service to develop a model for triaging healthcare claim denials with reinforcement learning. Rob Gontarek, its senior vice president of data science, highlights the ability to control individual training operations.
“Training Sessions gives us the right primitives to push toward production-grade performance,” Gontarek said in AWS’s announcement.
Karini AI used the service to customize gpt-oss-20b for an agent that interacts with an Amazon Neptune knowledge graph over multiple steps. CEO Nitin Wagh emphasizes reduced setup work and the ability to resume training from a saved point.
“It gave our developers the flexibility they wanted while taking the operational burden off their plate,” Wagh said in the post.
These examples indicate the kinds of specialized workflows AWS is pursuing. They do not establish a quantified return on investment: the published announcement includes no comparative customer figures for accuracy, overall cost or deployment speed.
Token billing changes the cost calculation
AWS says customers pay according to processed tokens, the units of text handled by the model, rather than reserving GPU capacity. The training-session meter pauses while the customer’s own scoring code evaluates a batch.
That could matter when evaluating results takes substantial time between model updates. However, an idle training-session meter does not make the surrounding application free: teams still need to budget for any separately used computing, storage, evaluation services and production inference.
AWS’s technical documentation separates billing into input processing, response generation and training. A meaningful comparison therefore requires estimating all three across repeated experiments.
The launch post does not disclose dollar rates or a representative total training bill. AWS directs customers to its SageMaker pricing page. Token billing alone does not establish that the service costs less than running equivalent work on dedicated infrastructure.
Four launch models, with regional differences
AWS’s published announcement confirms support for gpt-oss-20b, gemma-4-31B-it, Qwen3.6-27B and Qwen3.8-27B.
The public model table reviewed by VentureBeat maps regions for the first three but does not yet specify where Qwen3.8-27B is available.
AWS’s cookbook identifies Northern Virginia, Oregon and Mumbai as supported regions. The model table lists GPT-OSS-20B in all three, with Gemma-4-31B-it and Qwen-3.6-27B in Oregon and Mumbai.
The documentation also sets an adjustable default quota of two simultaneous fine-tuning sessions.
Developers can start from their own development environment using the SageMaker Python SDK and cookbook, or work in SageMaker Studio. AWS lists Linux and macOS with Python versions 3.10 through 3.12 for the SDK route.
AWS brings its enterprise infrastructure into a competitive market
AWS is entering an established market for training services that separate algorithm design from GPU management. Thinking Machines Lab’s Tinker offers a closely related approach, with interfaces for generating responses, updating models and saving progress. Its published pricing similarly distinguishes input processing, sampling and training.
For an enterprise already using AWS, the potential advantage is how training fits into existing infrastructure and controls.
AWS says sessions use customer-defined access roles and can incorporate customer-managed encryption keys and private-network configurations. Training data and saved model checkpoints reside in customers’ S3 storage in their selected region. The company says it does not use either customers’ data or their customized weights to train another model.
The post also points to evaluation before deployment and guardrails and CloudWatch monitoring afterward. These are controls teams can apply, rather than evidence that a customized model automatically meets their accuracy or safety requirements.
AWS also says customized models can run on SageMaker for inference, while selected models can be imported into Amazon Bedrock. That qualification matters: the announcement does not establish that every supported model has the same deployment options.
For buyers, the practical test is whether the additional training control solves a measurable business problem. A useful pilot would compare the customized model against the existing approach on task completion, failures and total operating cost.
Training sessions can reduce the infrastructure work involved in that experiment. The harder responsibility remains with the enterprise: defining what successful behavior looks like and proving that the model has learned it.
Smarter agents need more memory. The best teams will use less. Find out how at VentureBeat’s Agentic Infrastructure Stack Summit, October 28 in San Francisco. Attendance is by application.