Infrastructure for AI Agents: Migrate in Hours, Not Months (Live Replay)

On October 20, I joined a live session hosted by TPC, a recruiting firm for tech, product, design and data roles in France. Emma, an engineer at Alan, ran the session and asked the questions. It was 3 a.m. in San Francisco for me, so thank you to everyone who stayed until the end.

The topic was infrastructure in the age of AI agents: what breaks when agents write the code, how migrations change, and how to keep control. This page has the replay, the chapters and the takes I think matter most.

Watch the replay

The live is in French. YouTube can show translated subtitles.

Watch on YouTube

Chapters

Key takeaways

• Day Two is about 80% of infrastructure work. Building the infrastructure happens once. Running it, upgrading it and keeping it compliant never stops.
• Infrastructure built for humans breaks at machine speed. Agents produce more code, so they need more builds, tests and deployments. A single shared staging environment cannot serve many agents working in parallel.
• Agents need one environment per branch. Each pull request needs its own isolated environment, created in seconds and deleted after. Few companies build this themselves because the wiring is expensive.
• Migrations can take hours. Agents can do the discovery, mapping, validation and tests that used to take a team months.
• Control comes from the platform. Scope each agent with a policy token, log every action, allowed or denied, and test the policy before you give the token.

Day One builds it, Day Two runs it

Watch at 12:30

Day One is the build. You create the target infrastructure once: compute (ECS, Beanstalk or Kubernetes), network (VPC and network segregation) and security (security groups). Day Two is everything after: running, maintenance, upgrades, cost optimization and compliance.

I like to compare it to a house. You build it once. Then you maintain it for 15, 20 or 30 years. Most people think Day One takes the most time. In my experience, Day Two takes about 80% of the time of the people who do infrastructure work: DevOps engineers, SREs and platform engineers. We wrote more about the difference between Day 0, Day 1 and Day 2.

Emma asked where compliance fits (watch at 16:00). It is Day Two work. With SOC 2 Type II, an auditor checks you continuously. DORA, a European framework, comes up often with our customers in Germany. The work is to find and fix drift: log retention that is too short, or an internal service whose port is open to the internet. Tools like Drata and Vanta run that analysis all the time.

Infrastructure was built for human speed

Watch at 19:30

For 20 years, people used the infrastructure: developers, engineers, ops teams. A new project could take weeks to get its infrastructure, and that was fine. A DevOps engineer set up production, staging and development, and those environments stayed simple and static.

Agents moved us to machine speed. I opened the talk with GitHub's public numbers: commits in 2026 are on track for many times the 2025 total. More code means more builds, more tests and more deployments. Everything that was semi-automated, with a Terraform script someone runs by hand, starts to break. An agent needs infrastructure to finish its task, and if part of that infrastructure was designed for a human to click through, the agent gets stuck.

Shared staging does not survive agents

Watch at 22:30

Staging is the classic example. Many teams already hate it. It is static and shared, so people wait for each other. Emma knew the pain well: someone runs a long database migration and her tests stop for five minutes.

What was already under pressure with humans is destroyed with agents. One Claude Code session can run several agents and sub-agents on the same project at the same time. They cannot all test on one staging environment. Some of our customers have very small teams and open thousands, close to tens of thousands, of pull requests per week with agents. Each pull request has to be tested in real conditions before it reaches the main branch.

The answer is simple to describe. Each branch gets its own environment. The agent creates the branch, gets isolated resources, tests, and deletes the environment when the branch is gone. These are often called ephemeral environments.

Why one environment per branch is hard to build

Watch at 29:00

Few companies build this themselves, because the investment is hard to justify. Every environment needs several things wired at creation time:

• environment variables, copied and changed for that environment
• network segregation, so only the right services can talk to each other
• TLS certificates and URLs, attached dynamically
• builds, logs and build cache, so the same application is not built again for every environment

Speed matters too. An agent writes code and iterates very fast. If it waits tens of minutes for an environment, it loses most of that speed, the same way a human would. And even a simple app is a front end, an API, a worker, a database, a cache and storage. Emma pointed out that this is a very common setup, and it already means a lot of resources to create for each pull request.

What changes, layer by layer

Watch at 32:00

The CI/CD line is very real for us. At Qovery, each team now has its own internal app: one for customer success, one for sales, one for product, each with its own KPIs. Writing a pipeline by hand for each of them would not scale.

Incidents are one of the first places teams use AI. The agent reads the data sources and explains what happened. The team then chooses to act by hand or let the agent act.

Migrations: from months to hours

Watch at 36:00

Migrations scare CTOs and CIOs, and for a good reason. The platform is already running and customers use it every day. I compared it to a dentist who moves to a new office. The calendar is full, and every patient has to find the new address without missing an appointment. In infrastructure, the patients are the requests.

With AI, we can now run migrations in a few hours. A team of agents analyzes the current setup and the target setup, asks questions, runs the migration and runs the tests. Discovery, mapping and validation are no longer done by hand.

This changes who does the work. I quoted Sequoia's thesis that services are the new software: for every dollar spent on software, about six are spent on services around it. Companies often paid IT consulting firms like Capgemini, Devoteam or Theodo to run migrations. Now a migration can be specific to one company and fully automated.

Emma remembered a migration from Heroku to an AWS service at Alan. It took four people full time for at least four months, maybe six (watch at 40:30). Today Alan runs on Qovery. Emma said that in three years she has not had a single problem deploying anything, in a company where engineers push code all day. You can read Alan's case study.

For the people side of a migration, see the replay of our session on why deciding to migrate takes longer than the migration.

Demo: deploy a project from one prompt

Watch at 42:00

I started from a small app I had vibe-coded: a simple clone of a medical appointment booking app. In Claude Code, with the Qovery CLI already signed in, I typed one sentence: "Can you deploy this project with Qovery?"

Here is what happened:

1. The agent loaded the qovery-deploy skill. A skill is a runbook. The agent could find the steps on its own, but the skill saves tokens and makes it ask the right questions.
2. It scanned the project and found that the app needs PostgreSQL and Redis.
3. It asked me to choose between containers and managed cloud services (watch at 52:00).
4. It created the project, the production environment, the full deployment pipeline with the right order, and all the variables and secrets. Then it deployed everything.
5. I asked it to clone production into 10 test environments, each on its own branch with a different background color, to test changes in parallel (watch at 58:30).

For production, I often recommend a mix. Use managed PostgreSQL (RDS on AWS) for backups, point-in-time recovery and security. Run Redis as a container for the cache: cache data does not live long, and a container costs much less than managed Redis.

Even in auto mode, the agent asked me to confirm before it created infrastructure. We force that on purpose. It is infrastructure, so a human confirms.

You can try the same product without signing up in the Qovery Console demo. There is no cluster and no account to create. If you build with Claude Code, this guide shows the full flow.

A question from the chat

Someone asked: if copying an app is this easy, why does a company like that need so many employees? My answer: the code is only part of the equation. The value is in the network, the trust, and the compliance and certifications you need to work in healthcare. Many businesses are like that.

Day Two with Agent Tasks

Watch at 55:30

Day Two is 80% of the work, so it is also where agents help most. In Qovery, Agent Tasks are agents that live in your environments and see both the applications and the infrastructure. They run on a schedule or continuously. Two examples: an agent that keeps build and deployment time low, and an agent that watches for security drift. You bring your own model key (Anthropic, Bedrock or another), and every run is kept in the history.

From operator to orchestrator

Watch at 41:00

Application developers are moving closer to the product and the business. Infrastructure people are making the same move. A DevOps engineer, SRE or platform engineer used to be an operator. Now they direct agents that do the operations. The human still owns performance, security, compliance and cost, and still makes the decisions.

How to keep control of agents

Watch at 61:30

In the demo, the agent used my own account and all my permissions. Qovery still records that these actions came from an agent acting for me. For anything serious, three controls matter:

• Audit logs that show which agent did what, and for which user.
• Policy tokens: API tokens limited to specific actions, written as policy as code with Open Policy Agent and its Rego language.
• Denied actions in the audit log too, so you can see what the agent tried and could not do.

In the Q&A, a viewer asked how to balance agent autonomy with security in a regulated environment (watch at 65:30). Give agents the least access possible, scoped to the operations they need. A policy is code: you know who wrote it, you can version it, and you can hand it to an auditor. Qovery has a skill that writes the policy for you and tests it in a dedicated environment before you give the token to the agent, so you can check the agent cannot run destructive actions you did not allow.

Some companies, like Rippletide, work on dynamic guardrails that detect and block risky actions as they happen. They give agents more freedom with a safety net. When you need maximum security, I still prefer tested policies with a procedural way of running things.

Next: Agent ID

Watch at 63:30

Today an agent uses a CLI and an API designed for humans, and it acts as a human. The product cannot tell a person from an agent, so it cannot adapt. Agent ID is a way to give agents their own identity. Microsoft wrote a first paper on it. It is not a standard yet, and it is something we will explore at Qovery.

Checklist: is your infrastructure ready for agents?

• Measure how much of your infrastructure team's time goes to Day One and how much to Day Two.
• List what is still manual: capacity tickets, Terraform run by hand, YAML copied between projects.
• Check that every branch or pull request can get its own isolated environment and delete it after.
• Automate variables, network segregation, certificates and URLs for each environment.
• Measure the time from a push to an environment ready to test.
• Connect an agent to your logs and metrics to correlate incidents.
• Record every agent action in an audit log.
• Give agents scoped tokens, described as policy as code.
• Before a migration, automate discovery, mapping, validation and tests.

What's next

Thank you to Emma, Juliette and the TPC team for the invitation, and to everyone in the chat for the questions. TPC also published its own recap in French.

On November 12, we host Agents in production: beyond the demo in Paris with Alan, as part of their Second Opinion series. Doors open at 6 p.m. Questions before then? Talk with us.