AI
The Scale That Made Manual Migration Impossible
Adobe’s gateway team handles 13 petabytes of traffic per month and 40 billion requests per day. The old gateway ran on NGINX with Lua business logic. The replacement runs on Envoy and Argo CD. Between them sit 2,600 services spread across more than 500 clusters, each with multiple environments. An optimistic manual estimate put the migration at four and a half years. A pessimistic one put it at 15. Neither was acceptable, so the team designed an autonomous pipeline instead.
Why the LLM Translation Approach Failed
The first idea was to feed old YAML configurations directly to an LLM and have it produce the new values files. The schemas differed enough that the model got confused about where to move fields. When one translation improved, another broke. The process was not deterministic: the same input could produce different outputs on different runs. Fixing it would have required large volumes of manually translated examples, which was exactly the work the team wanted to avoid.
Code Generation as a Deterministic Translation Layer
The team replaced direct LLM translation with a coding agent that writes and refines a translation tool. The tool, not the model, does the actual conversion. Code is deterministic: the same input always produces the same output. A human engineer reviews the translation output and logs, tells the agent what went wrong, and the agent patches the tool. Previous correct translations are stored as golden files in a monorepo and checked on every subsequent run to prevent regressions. The loop converges toward zero errors over time.
The Cutover Agent: Progressive DNS Shifting with Automatic Rollback
Once the translation tool produces a new configuration, a testing agent discovers all endpoint paths, sends synthetic HTTP requests, and confirms the new gateway responds correctly. Then a cutover agent, built with LangGraph, connects to DNS and shifts traffic in small increments. It reads Splunk logs and RED metrics and compares the new gateway’s error rate to the old one. If the rates diverge, the agent rolls back and notifies the engineer. This intervention happens in 10% of migrations. The other 90% complete without human involvement.
Agent Architecture and Safety Constraints
The cutover agent sits on top of LangGraph, with LangChain as the LLM abstraction and Anthropic or OpenAI models underneath. Tools connect the agent to Splunk, GitHub, Kubernetes, and Argo CD. Security enforcement lives in the tools, not the agent. The agent issues a request; the tool applies hardcoded security constraints before acting. The agent has no direct access to critical actions. The pipeline is also intentionally linear: a fixed rail of steps. The agent is not given room to improvise, which prevents unexpected behavior.
Lessons: Code Over Configuration, Agents Over Engineers for Repetitive Work
Three lessons came out of the project. LLMs write code well but struggle with niche configuration formats, so asking for source code beats asking for Envoy YAML. Code gives deterministic behavior where LLM output does not. Monitoring migrations is time-consuming but mostly uneventful, so agents do the watching and engineers get called only when something breaks, reducing engineer time to roughly 10% of what full-time monitoring required. Running hundreds of migrations in parallel becomes manageable when humans only intervene on failures.
Q&A
How long does a single migration take? Translation runs in seconds; the cutover phase runs for minutes on high-traffic services and potentially overnight for services with only a few requests per hour. ▶ 20:52
How do agents trigger deployments safely without direct cluster access? Each tool, sometimes an MCP server and sometimes a CLI, enforces security constraints before executing any action, so the agent only requests, never acts directly. ▶ 23:12
Did the team encounter tool-bypass behavior from the agent? No, because the pipeline is a fixed linear rail with no creative freedom given to the agent. ▶ 24:01
Notable Quotes
if things went south it could take 15 years. Alvaro Saurin · ▶ 03:00
we don’t give that much flexibility to the agent. is just a rail. It’s a fixed rail of actions, a sequence of actions. So the agents move forward in that rail. Jose M Navarro · ▶ 24:23
The agent doesn’t have the real power. The agent is just tries to do things. Jose M Navarro · ▶ 23:56
with code we produce deterministic behaviors. Uh with agents or with LLMs you have undeterministic uh behaviors. With code you have what you want every single time. Jose M Navarro · ▶ 18:42
Key Takeaways
- Manual migration of 2,600 services across 500 clusters would have taken up to 15 years.
- Asking a coding agent to write a translation tool beats asking an LLM to translate configuration directly.
- Agents handle 90% of migrations autonomously; engineers intervene only on detected failures.
About the Speaker(s)
Alvaro Saurin is a Senior Platform Engineer at Adobe, contributing to API and service mesh solutions within Adobe’s Cloud Platform Engineering team. He has previously worked at SUSE and Telefonica R&D.
Jose M Navarro is a Software Engineer at Adobe. He has worked as a software engineer, architect, and CTO at startups over several decades, with the last ten years focused on data and machine learning before moving to platform engineering at Adobe.