The key point: in June 2026, Retool is switching to an AI-only app builder on a new full-stack React/TypeScript architecture, paired with an MCP server that lets you create Retool apps from any AI coding agent (Claude, Codex…). The ambition is to capture the speed of generative AI without losing the enterprise governance that sets Retool apart from “vibe coding” tools (Lovable, Replit, v0…).
1. What's new
The headline change: a move from a closed, proprietary rendering engine to a standard, inspectable React + TypeScript stack.
Until now, Retool's proprietary abstractions made it possible to build quickly, but they had three limitations: AI models could not work natively in the Retool format, developers could not bring their own tools and workflows, and apps built elsewhere (Replit, Lovable, v0, etc.) could not run on Retool or inherit its centralised governance. With this new engine, Retool apps are now written in React on the frontend and TypeScript on the backend: the AI agent generates standard code that any technical team can inspect, reuse and improve, with nothing locked into a proprietary format (source).
1.1 Rethinking the experience as a true AI editor
The feature is enabled from the organisation settings, with the option to connect your own model (AWS Bedrock, Azure, OpenAI…) rather than relying solely on Retool's default model.
The new editor is designed for prompt-first use: you can address a prompt to the whole app, or click a specific element in the preview to scope the prompt to that component (source).
1.2 An improved in-app chatbot
Retool has also opened the door to far more input types than before: you can now drag and drop screenshots, PDFs, design files (Figma…) or spreadsheets, and the agent works directly from the same references the team already uses. This means work already done elsewhere (mock-ups, specifications, datasets) can be picked up and handed to Retool to carry on building the app (source).
- Code tab: inspect and directly edit the generated React; clicking an element in the preview takes you straight to the corresponding line of code.
- Data tab: whereas AI-generated apps often make it hard to tell what they actually do with data, Retool keeps this layer readable by design: every piece of data-access logic is exposed as a function you can open and understand. For more complex conditional logic, a visual data graph shows the relationships between inputs and data sources, and how user actions translate into data operations.
Importing existing apps: if I have a React app already started on Lovable, Replit, v0 or any other vibe coding tool, or even a React project from a local repository, I can now import it directly and deploy it on Retool, with no rewrite. During the import, Retool automatically maps the app's data connections to the resources my team has already configured and secured. The app also inherits Retool's app-level permissions (RBAC), to control who can view, use or administer it, with the same rules as everywhere else in Retool (source).
The major drawback is that apps built on the previous architecture will have to be converted.
In the Chat tab, a new “Convert classic app” shortcut lets you convert a “classic” app (built with the old Retool editor, before this update) directly to the new React editor. An agent imports the classic app's source code in read-only mode, draws up a multi-phase conversion plan, then converts resource queries, JavaScript and the rest of the code into equivalent functions in the new model. The original classic app is never modified during the process; for complex apps, conversion can take up to an hour. Classic apps remain supported for at least two years after the new editor becomes generally available, so converting is not mandatory (source).
1.3 MCP: driving Retool from any AI agent
The key point: an MCP server in public beta lets you drive Retool (apps, resources, users) directly from Claude, Cursor, Codex or Kiro, with the same security guardrails as the web interface.
Governance and security: where you build should not determine how secure it is. Retool is extending its governance model to connected coding agents: whether you are improving an existing app or starting from scratch via MCP, changes automatically inherit the security standards the organisation has already approved (access control, audit trail, data permissions), configured once at platform level rather than app by app (source).
Instead of opening a browser, administrators can interact with Retool directly from their AI coding environment to:
- build and modify apps, then deploy them to the Retool platform;
- write queries against connected resources to power data analysis;
- invite users in bulk or manage pending invitations;
- audit the users who have access to the organisation;
- inspect the configuration of the organisation and its resource environments;
- list all connected resources and view their configuration.
Technical documentation: MCP tools reference.
Can you now export the React code and deploy it outside Retool?
In short: the code is more open (React/TypeScript, syncable with your Git repository), but running it in production remains tied to the Retool platform (changelog).
These changes introduce two limitations.
1.4 Is routing everything through AI really progress?
I have my doubts about a strategy that requires (or only allows) changes to be made through AI. Where the old editor let you show or hide a button, or change the action it triggers, in two seconds with a single click, everything will now have to go through a natural-language prompt or straight into code, then be tested to make sure there are no side effects or misunderstandings on the AI's part. For trivial, repetitive changes, this detour strikes me as rather limiting, and potentially slower than a direct click in the old editor.
1.5 The forced migration of complex apps
The second limitation is the eventual obligation to migrate complex apps built in the classic editor to this new AI editor. Retool has announced that it will only maintain the old editor for the next two years. After that, it will most likely no longer be possible to edit an app other than through AI, which raises the question of what happens to critical, complex and already stable apps, for which a conversion (even an AI-assisted one) is never risk-free.
2. Why this change: the real battle is governance
With AI, anyone can now build an app. We quickly reach a point where operational staff with no technical knowledge become the developers of their own tools. The real question is no longer “can we build an app easily?” but “how do we manage it across the whole company?”. Retool is trying to answer that question, and this acceleration brings new challenges.
2.1 Visibility and pooling
One of the key challenges is providing visibility over the apps already built, so that two people do not end up working on the same thing in parallel without knowing it. This starts with clearly sharing knowledge of what exists or is in development, so that new joiners can quickly find the apps already in place rather than starting from scratch, which calls for centralised documentation or a catalogue accessible to everyone. In the longer term, the goal is also to pool development work: Retool lets several people work on the same app while managing separate environments (test/production, or per team), paving the way for structured collaboration rather than isolated, redundant development.
2.2 Hosting and centralisation
Today, some apps run locally while others are hosted all over the place (Cloudflare, Vercel, AWS…), which makes it very hard for a company to get a centralised overview of everything that exists. This fragmentation complicates several essential issues:
- GDPR: a developer may pick a hosting provider simply because an AI or a tutorial suggested it, without knowing the data residency constraints (hosting outside the EU, transfers of personal data, etc.), exposing the company to compliance risks it has no control over.
- Billing: each service (hosting, domain name, database, third-party APIs…) generates its own invoice, often on a different bank card or account, which makes tracking costs and allocating them to a specific project extremely tedious.
- DNS and URLs: when each app has its own domain or subdomain configured with a different provider, nobody in the company knows exactly what points where, or who has the rights to change it when needed (renewal, migration, incident).
On top of this come other risks: security and access management (passwords and API keys scattered across several platforms, with no centralised view of who has access to what), dependency on a single person who understands an app's architecture (if that person leaves the company, nobody knows how the service is hosted or how to maintain it), and technical debt resulting from the lack of common standards, which makes every new app more expensive to take over or evolve.
2.3 Security and permissions
Another major challenge is centralising permission management. The point is to know precisely who has access to what, depending on the app's sensitivity, its criticality and the data it handles. This means managing how tools connect to one another while keeping control over that access. For example, you need to prevent just anyone from reading or writing to the CRM, which remains a central, critical tool for the business, and where a mishandled operation can have serious consequences.
It also means segmenting environments and API keys by team or by user. This is a genuinely crucial point for limiting the blast radius in the event of an error or a leak: if each team or each app has its own isolated access, a problem with one of them does not expose the whole system, and it becomes much easier to identify the source of an incident and contain it quickly.
3. Conclusion
With this new strategy, Retool is positioning itself as a direct competitor to Lovable for Enterprise in the enterprise segment: where vibe coding tools bet on sheer generation speed, Retool adds the governance layer (permissions, audit trail, secure resource connections, RBAC) that was missing until now to deploy this kind of app across an organisation. This repositioning is not a mere product tweak: it reflects a fundamental shift in how companies will have to manage the proliferation of AI-built internal apps.
I am convinced that any company that fails to tackle this issue in the coming months will run into serious difficulties: a proliferation of uncatalogued apps, scattered hosting and access, dependency on a few key people who know how a tool was built, and growing exposure to security and compliance risks (GDPR in particular) that the company no longer controls. The real risk is not that teams build apps with AI — that will carry on, with or without a framework — but that they do so without any centralised governance.
The aim is to centralise apps (visibility, lifecycle, hosting), centralise authentication and permissions (who has access to what, with which keys, in which environments), and centralise skills or reusable building blocks (resource connectors, workflows, development standards) so that every new app builds on a common foundation rather than starting from scratch, along with a series of tests before going into production. It is this centralisation that makes it possible to keep the speed gains brought by generative AI without suffering the side effects in terms of security, costs and technical debt.