--- title: "Pattern: Agent-Owned Accounts (Deploy Environments)" type: post url: "https://robotpaper.ai/agent-owned-accounts-deploy-environments/" canonical: "https://robotpaper.ai/agent-owned-accounts-deploy-environments/" markdown_url: "https://robotpaper.ai/agent-owned-accounts-deploy-environments.md" published: "2026-07-01T19:43:33.000+00:00" updated: "2026-10-22T21:58:01.000+00:00" tags: ["Pattern", "AWS"] author: "Roy Osherove" author_links: ["https://robotpaper.ai", "https://x.com/royosherove", "https://www.linkedin.com/in/osherove/", "https://forms.gle/jQSx5KoXvrVA1JCK7", "https://robotpaper.ai/about-roy.md"] description: "Give an agent a VM and it submits PRs. Give it its own cloud account and it codes, deploys, debugs and monitors apps. The Agent-Owned Accounts pattern." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original post)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Pattern: Agent-Owned Accounts (Deploy Environments) Give an agent a VM, it will submit PRs. Give an agent a deployment environment and an admin ability, and it will code, deploy, debug and monitor your apps. I believe [LowKey](https://github.com/inceptionstack/lowkey) was the first I to have its own AWS account to do with as it pleases. Lately I've also heard of [Cloudflare Temporary accounts](https://blog.cloudflare.com/temporary-accounts/) for agents. These ideas solve for the next problem down the chain: After coding friction is solved, deployment & configuration friction becomes the next bottleneck. Just like "[Markdown is the new Installer](https://robotpaper.ai/markdown-is-the-new-installer/)" , solving the friction of deploying something onto a user's machine, so can we, the developers, solve the deployment problem by giving agents an [account that they own](https://robotpaper.ai/i-gave-my-agent-its-own-aws-account-and-now-it-codes-deploys-and-debugs-full-stack-apps/). In an internal experiment (~100 participants) Agent-owned accounts have been very impactful for internal solutions architects I've worked with over the past few months - it has sped up prototyping (turned prodo-typing) from weeks/days to mere hours of the most complex proofs of concepts and prototypes you can imagine on an AWS infrastructure with amazing scale. We're slowly showing this to customers (it's [open source](https://github.com/inceptionstack/lowkey) they can try it now) and getting feedback - but it makes a huge difference. Mobile support is a killer feature. 24/7 live event-based notifications, checks and monitoring a killer feature. Being able to think about something and just try it in a few minutes from your phone while on the train is a killer feature. removing the friction of configuration and "glue" work is a killer feature. For now I believe it is pretty risky to give an agent full production account deploy abilities (yet), but how about a sandbox account - one where the agent can utilize the ability to deploy and then fully test a full application end to end, replicating production fully, and then tearing it down if needed, or keeping it and providing access to internal or external beta users using a login? This would take days or weeks in many companies today, and breaks the product-market-fit cycle of feedback-change-deploy. Now it can happen in minutes. Today, base44 , lovable and friends provide just the basics of what you could deploy on, for anything else (graph databases, workflows, storage etc) they rely on you connecting to 3rd parties and giving them your APIs. With a full cloud provider such as AWS, Azure, GCP - these abilities become much more powerful - and there is zero friction to deploy almost anything of any complexity or scale (only wallet depth). Graduating to production will be the brainstorm of a future post. --- ## About the author **Roy Osherove** - Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: [https://x.com/royosherove](https://x.com/royosherove) - LinkedIn: [https://www.linkedin.com/in/osherove/](https://www.linkedin.com/in/osherove/) ### Contact - Contact form: [https://forms.gle/jQSx5KoXvrVA1JCK7](https://forms.gle/jQSx5KoXvrVA1JCK7) ### License Content on robotpaper.ai is licensed under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/): reuse, quote and adapt with attribution (Roy Osherove, link to the original post). More about Roy and his other sites and projects: [https://robotpaper.ai/about-roy.md](https://robotpaper.ai/about-roy.md)