The agent builds screens and endpoints in FlutterFlow through FlutterFlow's own MCP. AxonWeaver registers every endpoint, reconciles it with FlutterFlow and answers the app with realistic data while the real logic does not exist yet. Later a business process takes over the same address, and the app does not change.
Screens, widgets, actions and the endpoints themselves live in FlutterFlow. The agent changes them through the FlutterFlow MCP server: validate first, run only when validation is clean. AxonWeaver writes nothing into FlutterFlow.
The registry holds the method, the path, the request and response schemas and the navigation graph between screens. It reads FlutterFlow and says whether the two sides agree, and if not, exactly where they differ.
The agent works with two MCP servers: FlutterFlow and AxonWeaver. The second accepts writes only with the operator's session id, and every call shows up in the workspace log.
Who works at each step: the agent, FlutterFlow, AxonWeaver and a person
The agent reads the workspace context: FlutterFlow pages, app state, data structs, the APIs already registered and their status. Then it agrees the contract with a person: page, widget, event, request and response fields. Fields are not invented: when something is ambiguous, the agent asks before writing, not after.
The agent describes the endpoint and its binding to a widget event in the FlutterFlow DSL and hands it to the FlutterFlow MCP server: validate first, run only when validation is clean. The FlutterFlow CLI runs in its own container, with a separate workspace per FlutterFlow project.
The agent registers the endpoint in AxonWeaver under the same name it has in FlutterFlow, or imports every unregistered one at once. Each gets a reconciliation status: in_sync, schema_mismatch, missing_in_ff, unlinked or unknown, plus a diff when they differ. Name, method, path and response fields are compared.
The agent runs the endpoint in a sandbox with no outbound traffic and stores an answer for each case: success, phone already taken, wrong code. A Listening receiver answers the app at the endpoint's address, and a person sees on the real app how the screen behaves in every scenario.
The endpoint is deployed into an Axon project's container and gets a public base address. In FlutterFlow only the base address variable changes; the tail of the path stays the same. Once a business process stands behind the endpoint, the workflow's answer becomes the endpoint's answer, and undeploying the process brings back the receiver's answers.
A Listening receiver takes the endpoint's address and answers every call the app makes. Where the answer comes from follows a simple order, and the answer always says which source it came from.
def generate(request) -> dict:
app_id = str(request["query"].get("applicationId", ""))
return {"status": "declined" if app_id.endswith("9")
else "approved",
"reason": ""}
An example from the agent's skill: applications whose number ends in 9 are declined, the rest approved. The same request always gets the same answer, so a demo can be repeated.
Each case has its own named answer: happy_path, phone_taken, rate_limited. The agent writes the body, AxonWeaver checks it against the response schema and stores it. A mismatch with the schema does not block the write; it shows which fields are missing and which are extra.
When the answer depends on the request, a procedure answers: one application approved, another declined, one code accepted, another refused. It runs in a sandbox with no network and no file system, a forbidden import is refused when it is stored, and before storing it is tried on sample requests.
Every call from the app is kept: method, path, parameters, body and what the receiver answered. If a procedure fails, the receiver still answers and the reason stays next to the call. It is the first thing to read when a screen behaves oddly.
Moving from a receiver to the backend needs no rework of the app. Only what stands behind the address changes.
A FlutterFlow project attaches to several Axon projects, each with its own container and its own deployment state. The workspace shows the base addresses for each: the project runtime, the Listening receiver and a dry run.
When an endpoint changes, AxonWeaver marks its deployments in every attached project as stale, and a redeploy refreshes them in a project in one action. The old route is removed so that nothing answers at the previous address.
A process that starts from an interface endpoint is bound to it on deploy. In sync mode the workflow's answer becomes the endpoint's answer; in async mode the app gets 202 at once. Permissions for the endpoint are checked at the door of the project runtime.
A workstation screen — a queue, a card, an action, a report or a dictionary — is declared as data once. The screen contract, the permission key, the endpoint and the translations all come out of the declaration.
The platform checks five things: the process behind an action is deployed, the queue's source is known, the roles exist in the project, the widget and the endpoint share one permission, every caption has text in three languages. With errors, no screen is generated.
The platform hands out the screen contract, the permission key and the endpoint, and the translations as a CSV in FlutterFlow's import format. The agent builds the screen layout against the contract.
Captions are keys of the project dictionary in English, Spanish and Russian, and the screen reads them before drawing. A menu section is open when the person holds a permission on at least one widget of that section.
The agent built in FlutterFlow the workstation shell, applications, loans, payments, the mandate panel, the client card, reports with an export to 1C, and administration. Every endpoint is registered in AxonWeaver and answers through a receiver; the screens were checked in the browser under different roles.
Client registration from the phone number to signing the agreement. The app checks only field masks; the decisions — the confirmation code, the bank list, income verification — come from AxonWeaver receivers. Screens were compared with the Figma designs in pairs, screen by screen.
The boundaries of responsibility are fixed in the agent's skills and in the code, and we state them plainly.
AxonWeaver does not write into FlutterFlow. Screens, actions and endpoints are changed only by the agent through the FlutterFlow MCP.
Reconciliation does not cover the request schema: FlutterFlow does not expose it without its desktop app. The reconciliation answer names what was not checked.
There is no model inside AxonWeaver that invents answers. The agent writes answers and procedures; the platform checks and stores them.
Nothing polls FlutterFlow in the background. Changes are pulled on request, and the reconciliation status shows when that is needed.
Demo access, an architecture walkthrough and a timeline estimate for your domain.