When a table starts doing two jobs, Backenly moves the second into a table of its own. It rehearses the move on a copy, waits for your approval, and your apps keep working throughout.
You: Why is Backenly asking about
orders?
Agent: autonomy evolution
Move refund data out of orders
into its own table. The refund
columns are set later in an
order's life, and changing them
has been locking orders.
Rehearsed on a copy. Waiting
for your approval.
You: (approves it in the dashboard)
Later: is it done?
Agent: autonomy evolution
order_refunds is open. Apps that
use orders keep working, and undo
puts orders back as it was.Columns that are filled in on the same rows, or set later in a row's life, often form a job of their own, like refunds on an orders table. Backenly proposes moving them only when keeping them costs something it measured, such as changes that lock the whole table.
Every move is rehearsed on a copy first, including who can read and write each row. You approve the exact plan on the Autonomy page; if the table changes before it runs, Backenly rehearses it again and asks again.
The new table is kept in step with the old one in both directions while the existing data is copied across, so code that uses the old table keeps working and new code can move when it is ready. Who can read or change the data stays the same.
Undo removes the new table and leaves the original exactly as it was, with no data lost, and is refused if it would lose a write. Dropping the old columns is in the plan for you to see; Backenly never runs it.
One kind of change: moving a group of columns that has become a job of its own out of a table and into a new one, such as refund_amount, refund_reason and refunded_at out of orders into order_refunds. It never changes what the data means, how many rows there are or who can see them; a redesign like that is suggested at most, never run. Auth, storage and functions are not restructured.
No. A restructuring runs only after an admin of your organization approves the exact plan on the project's Autonomy page. Your coding agent can read what Backenly proposes over MCP, but it cannot approve it. Most of the time the answer is that no change is needed: a table being large, busy or still changing is not a reason on its own.
Apps that use the original table keep working unchanged. The new table is kept in step with it in both directions, the existing data is copied across in batches and checked to match before the new table opens to your apps, and nothing is removed from the original table.
From the Architecture changes card on the project's Autonomy page. Undo removes the new table and leaves the original exactly as it was, with no data lost. Backenly refuses to undo if that would lose a write and says why, and code that already uses the new table stops working once it is gone.
It uses no AI model: finding, rehearsing and carrying out a restructuring are rule-based, so they draw no credits. On Backenly Cloud it is on for every project, on every plan. When you self-host, it runs once you turn on ENABLE_EVOLUTION_MUTATIONS and ENABLE_EVOLUTION_SCHEDULER.