Using an agent fleet to clean and migrate 400 messy legacy tables in 2 days.

We recently had to migrate about 400 messy legacy tables after a company acquisition and if you have ever done post-merger database work, you know it is usually a month of miserable manual script writing. Instead of writing custom ETL scripts for weeks, we put together a simple team of autonomous agents to inspect the old schemas, infer field mappings, flag unindexed PII and run test queries in isolated database copies. The biggest mistake we made early on was trying to let one big prompt do everything. It kept choking on weird nested JSON fields and hallucinating column types. Things only started working when we broke it into tiny single-purpose agents that check each other's work. One agent maps the fields, another acts like an annoying reviewer that tries to break the query and if it fails, it sends the raw SQL error back to the mapper to fix it. State management across retries was a total pain until we plugged Lyzr into our orchestration backend to keep memory isolated and stop unmasked data from leaking outside our private setup. We got the human review queue down to under four percent of the tables and what usually takes a quarter took us about two days. If you are building data agents, the main lesson is simple: never let the agent doing the work also be the agent that verifies it. Adversarial loops save you from breaking production every single time.