Building and running your custom agents on AWS Transform
AWS Transform runs your custom agent in managed infrastructure with job lifecycle, artifact delivery, and composition with platform-native agents.
Series: Stop Being The Runtime - Custom Agents on AWS Transform (3 articles)
- 1Building and running your custom agents on AWS Transform This article
You've built a script you run from the CLI, or a skill you run from your agentic IDE, and fine-tuned it for a migration or modernization task. It works: it assesses, exports, scans, or modernizes something useful.
But it stops the moment your session ends, your connection drops, or you hand it to a teammate without your setup. AWS Transform gives that same logic a managed runtime, an agent the rest of your team can run, and infrastructure that outlives your laptop.
Prerequisites
- Familiarity with AWS Transform at a conceptual level
- An IDE skill, CLI tool, or script you already use for a migration or modernization task: assessment, code scanning, migration planning
No AWS Transform agent required yet. This post is about deciding whether you need one.
When a skill is the right tool
A skill earns its place before it earns a deployment. When you're exploring a new migration or modernization pattern, prototyping against a customer's actual codebase, or checking whether an approach even works, you want fast iteration and a tight feedback loop. You change a line, run it again, see the result in seconds.
That loop is the point. A CLI or IDE skill lets you test an idea without provisioning anything, without a build step, without waiting on infrastructure. It's the right tool for proving a concept, and most agents should start their life this way.
When the workload outgrows local execution
The moment a task needs to survive without you watching it, the requirements change:
- The run needs to survive a lost connection or a restarted machine
- Duration stretches to hours, not minutes
- More than one developer needs to run the same logic
- Output needs to persist somewhere downloadable and auditable
- A failure at step 47 of 200 needs to get caught without someone watching the terminal
None of that is a mark against the skill. It's what unattended, durable, team-scale execution requires, a different set of guarantees than what local execution provides.
What AWS Transform gives you
Once you're past that line, AWS Transform gives you three layers of value, and each one raises the ceiling on what the same logic can do.
Platform services
AWS Transform wraps your agent in infrastructure you'd otherwise build yourself:
- A job lifecycle that starts, checkpoints, resumes, and completes runs, so a multi-hour job survives a dropped connection
- A console that lets teammates start and monitor runs, not just the person who built the agent
- Artifact storage that makes output downloadable and durable after the run ends
- Workspace isolation that separates tenant data by default
- Human-in-the-loop checkpoints built into the protocol, not bolted on after the fact
I wrote more about how workspace isolation and human-in-the-loop checkpoints fit into the platform's broader security model in a post on the layered trust model behind AWS Transform agents .
Composition with platform-native agents
Your agent doesn't have to stand alone. You can build an orchestrator that calls existing Transform agents and combines their output with your own logic. The .NET modernizer and SQL Server assessor , for example, already handle full-stack Windows modernization up to 5x faster than the manual path. That's a different shape than deploying a container in isolation: you're plugging into an ecosystem.
When composed agents hand work to each other, Amazon S3 is often the surface they use to do it. I walked through that pattern in a post on using S3 as a living data layer between agents .
Marketplace
The ceiling on all of this is distribution. When you're ready to put an agent in front of customers, not just your own team, you register it with AWS Transform and publish to the Marketplace.
Partners including Wavicle, Caylent, SoftServe, Accenture, and Infosys have already registered and published their own agents on the AWS Transform partner ecosystem . That path is open to a solo builder with one good idea, not just a consulting firm with 200 developers.
A skill solves your problem. A Marketplace agent solves the industry's problem.
Get started
If you're ready to move a script or skill onto AWS Transform, start with the developer tools guide to see what's available. The Agent Builder Toolkit in Kiro is the fastest path I've found from existing logic to a deployed agent.
Conclusion
The logic in your script or skill doesn't change when it becomes an agent. What changes is its operating posture: it runs unattended now, and it reaches people who never touch your CLI or your IDE.
In the next post, I'll cover what your agent spec needs to include so the build, deploy, and register cycle works on the first try. After that, I'm building one agent a week, each one solving a different modernization problem, end to end.
Further reading
- AWS Transform agent security: a layered trust model - workspace isolation, human-in-the-loop, and the rest of the platform's security layers
- Amazon S3 as a living data layer for your AWS Transform agent - patterns for using S3 as the handoff point between composed agents
- AWS Transform partner ecosystem - see who's already building and publishing agents on the platform
- What is AWS Transform? - the developer guide's overview of the service
This information is accurate as of July 2026. AWS Transform is an actively evolving service. Consult the reference documents linked above for the most current guidance.
Building agents on Transform? I'd like to hear about it. Find me on LinkedIn .
Series: Stop Being The Runtime - Custom Agents on AWS Transform (3 articles)
- 1Building and running your custom agents on AWS Transform This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article