Airbuild 1.6: Dynamic Agentic Mode

Version 1.5 was about the decisions around the work: which model you are spending on, which endpoints are open on purpose, what a project knows about your standards. Version 1.6 is about the work itself — who does it, and who is allowed to say it is done.

Until now one conversation did everything, in order. A detailed plan with twenty steps was twenty steps one after the other, even where half of them had nothing to do with each other. Dynamic Agentic Mode changes that, and it changes who signs off.

First the plan. Then the agents build in parallel.

The lead agent breaks the work into the number of phases it actually needs, with real dependencies between them. What everything else builds on — the data model with its migrations, the shared types and API contracts, the shell of the app — stays with the lead and goes first. Only then do the independent parts get their own agents.

Each agent is named in the plan with its job, the area it owns, the model it runs on and how hard it should think. Up to five work at the same time in one conversation. No two of them share a task or an area, so there is no silent overlap to discover later.

Every agent works in its own environment

Parallel work on one shared working tree is how you get four agents pulling the same files out from under each other. So each agent gets its own copy of the project and its own running copy of the app, with its own backend, its own tests and its own logs. It can run the app it is building and watch it fail.

Work reaches the project only when it is applied, and applying merges it in line by line. A file that cannot be merged goes back to the agent that wrote it, with the conflict marked, instead of landing as a mess someone else has to untangle. A new database migration whose number is already taken is renumbered; a migration that already ran is never touched.

No agent signs off its own work

This is the part the release is named after. An agent that checks itself is a model grading its own homework — it will usually tell you it passed.

So when an agent finishes, the platform starts the verifier. Not the model: the platform. A fresh agent, with its own copy and its own view, reads and tests exactly the state the builder handed over and gives a verdict — tests, review, security, or all three. Until that verdict is green, the work cannot be applied. There is no override.

It is enforced one step earlier too. A plan in which some agent would go unchecked is not presented to you at all; it comes back to the model to be fixed first. And a verifier cannot be assigned to itself.

When a check fails, the findings go back to the agent that built that part, not to a general queue. It fixes them in its own copy and the same verifier looks again.

Finally: end-to-end in a real browser

The end of a plan is not a self-report. The plan says in advance which flows have to hold — "a colleague is invited and then signs in", "a viewer cannot delete anything" — and a final verifier clicks through them in a real browser on its own copy of the app.

Every flow is marked pass or fail on its own, so you can follow it item by item instead of trusting one green "done". And after three failed rounds the system stops and asks you, rather than grinding on.

The right model for each part

Not every part of an app needs the strongest model. The plan picks one per agent out of the fourteen models in the picker, across six providers, together with a thinking depth — a faster, cheaper model for a well-specified part, the stronger one only where a part needs real reasoning. An agent is never given a model stronger than the lead itself unless you ask for one by name.

Afterwards the agents list shows what that cost: per agent, which model ran, how long, how many tokens, which files changed and by how many lines. Step by step, after the fact.

The plan writes itself in front of you

A plan used to appear when it was finished — a wall of text arriving at once. Now it opens as its first file starts streaming and fills chapter by chapter, with the rail on the left growing as chapters arrive. A note at the end says plainly that the AI is still writing, so a half-finished plan is never mistaken for the whole one.

Approving or declining happens in the plan view itself rather than in the chat, so the decision sits where the thing being decided about is. A plan can be edited in place instead of asked for again, and any passage of it can be quoted into the chat to talk about that passage specifically.

The design is no longer described in words alone. A plan carries up to three real looks — colours, type and a worked example — in its own Look & feel chapter, and the one you pick is what the build follows. Three at most, deliberately: a wall of variants is a decision deferred, not a choice offered.

Support became a case

Every support request now has a readable case number, a status you can see, and a thread that holds the whole history. Files can be attached on both sides, not only when opening it. You can close your own case and take that back if the problem returns, and a reply by email lands in the same thread instead of starting a second conversation about the same thing.

A finished case asks one question: did this help? The answer goes to us, not into a void. The reply box stays open on a closed case, so a follow-up does not need a new ticket and a new number.

Everything else

Dynamic Agentic Mode is part of Suite Builder. The full release notes live on the Version 1.6 page.

• Every published build carries an app version and a build number, stamped from the commit it was built from, so "which build is actually live" has an answer instead of a guess.
• Monitoring got a landing page that answers the first question — is the app healthy — before you go looking, with one time range that every view shares and that lives in the address.
• An app nearing its storage, memory or connection limit now warns its owner beforehand, with the actual figure against the actual limit. A crash loop is reported as a crash loop.
• The resources view is no longer reserved for the larger plans: anyone with a published app can see what it uses.
• An invitation no longer depends on the plan of the person invited — whoever joins works at the highest plan in that team, and the project says which plan it needs.
• A teammate can take hosting over onto their own plan, with the same address, the same data and no interruption, so an app no longer hangs on an account nobody can reach.
• When a model provider fails for a moment, the chat shows a notice with a countdown and retries by itself instead of ending the turn with a red error.