The short answer
Webflow is a visual builder: you work inside its canvas, wire up a CMS, tune interactions, and it hosts the result. Its agent connector is official and substantial, and it stops in three specific places. Across all three tool references there is no backup, restore or rollback tool; the Data API's Sites endpoints are List, Get, Get Custom Domains and Publish; and the design capabilities require the Bridge App to "remain open for these capabilities to work". Birta has no canvas. Its own agent in the panel, or the one you connect, builds and publishes the site, and the same agent reaches the draft, the version at its own address, the rollback and the client's remarks.
What each agent connector reaches
Webflow's connector is official and substantial: 24 documented data tools at mcp.webflow.com/mcp over OAuth, with connectors for Claude Code, Cursor, Windsurf and others, plus a Webflow app in ChatGPT. One of them publishes the site.
None of them backs up, restores or rolls back. Not in any of its three tool references, and the Data API agrees: its Sites endpoints are List, Get, Get Custom Domains and Publish. Read at developers.webflow.com.
Backups themselves are real, in Site settings under a Backups tab, where a person previews a version and restores it. So yesterday's site comes back through a human in a browser tab. (Webflow blocks automated reading, so that is its published help material as surfaced in search.)
The design half carries a second condition, in their words: open the site in the Designer, launch the Bridge App, and it "must remain open for these capabilities to work" (developers.webflow.com/mcp/reference/how-it-works.md). A connector that needs someone holding a panel open was fitted onto a product that already existed.
It reaches further into design than ours ever will, and three things ours cannot do at all: page branches, a per-page draft state, and CMS items that stay drafts.
Birta went the other way. Its agent, built in or connected, carries the loop: draft, publish at its own address, list what went out, put an earlier version back, read the remarks left on it. The restore is inside the connector, and nothing waits on an open Designer session. The price is Webflow's design tools.
Nobody imports a Webflow site into Birta
There is no importer, no bring-in-my-project button, nothing that opens a .webflow.io address and reads it. That is a decision, and it holds for every other source.
The reading half already belongs to the agent. Webflow's code export hands you a folder of static HTML, CSS and JavaScript, and Claude Code, Cursor, Codex and Claude Cowork read folders off your disk. A web-capable agent can also open the published site and pull the copy off the page. The tidiest route is Webflow's own server: connect it to the same agent and it lists pages, walks the element tree and reads CMS items, so the agent gets real content instead of scraped HTML.
Building a Webflow reader into a publishing service, when Webflow ships one, would buy nothing. Birta starts where the files are and gives them an address, versions you can roll back, remarks on a version, a declared form, a domain and a visitor count.
Compare the work after the first publish
Once a site exists, the two products manage very different things around it.
| Decision | Webflow | Birta |
|---|---|---|
| Best fit | Hand-designed sites with a CMS, animations, and ongoing visual control | Static commercial sites an agent already designed and now maintains |
| Building the site | You design inside Webflow's canvas, or hire someone who does | Birta's agent in the panel or a connected one produces the site; there is no visual canvas |
| Agent connector | Official, at mcp.webflow.com/mcp over OAuth, with 24 documented data tools tracing the Designer and the dashboard: elements, styles, components, CMS, pages, branches, forms, SEO, analytics, comment threads, publish. The designer-session tools also need the Bridge App left open in the Designer while they run | Birta's own agent in the panel, or a connector for yours: open a draft from a stored version, write files into it, publish it, list earlier versions, put one back live, read, answer and close a version's remarks, connect a domain, read leads. Nothing in it needs a browser tab open |
| Publishing a change | Edit in the canvas or through the connector, then publish either way | Re-publish through the same agent conversation, no separate publish step to learn |
| Versions and rollback | Automatic backups you preview and restore from Site settings. No backup, restore or rollback tool in any of the three tool references, and no endpoint for one in the public Data API, whose Sites list stops at List, Get, Get Custom Domains and Publish | Every successful publish is a saved version; the last 10 stay visible, and any of them can be made live again, from the same connection that published |
| Getting the files back | Code export carries over static HTML, CSS, and JavaScript; CMS Collections and Ecommerce content do not come out as working code | Every visible version can be downloaded as one archive of exactly what was published, no service extras mixed in |
| Lead form | Webflow's native Forms element, built in the visual editor | The agent declares the form's fields directly; submissions show up in the project's Forms tab |
| Lead delivery | Native form submissions and notifications inside Webflow | Leads land in the project panel, and everyone with access gets one email digest roughly 15 minutes after the first lead arrives; no Telegram, no webhook |
| Reviewing before it goes live | Invite a Reviewer into the project; they comment in Webflow's comment-only view, and can reply in a thread and resolve it. Its connector reads threads and posts replies too | Send the version's own address; whoever holds it marks remarks on the page with no account, and the agent reads them back, replies and closes them |
| Custom domain | Available on a paid Site plan | Connects on the Free plan |
| Payments from your visitors | Ecommerce with products, cart and checkout is part of the platform | Not yet. A planned backend module, not a permanent no |
| Free tier | A Starter plan exists, with Webflow's own limits | Own domain, lead form, remarks, versions and rollback; a Birta mark in the corner that the Team plan removes |
Webflow's CMS and interaction system are real capabilities Birta doesn't have, and its connector reaches most of its own product. What the table draws is where each connection stops. Two rows on Webflow's side stop outside it: the restore, which is a Site settings job with no tool and no endpoint standing behind it, and the review, which needs a reviewer invited into the workspace first. On Birta the version history, the downloadable archive, the declared lead form and the review remarks all answer to the same conversation that published the site.
Webflow gates a custom domain behind a paid Site plan. Birta connects one on its Free plan, next to drafts, versions, rollback and the whole review loop. The paid step on Birta is Team, for removing the Birta mark or a team sharing one project with its context. Check each product's current pricing page before deciding on cost alone.
Getting a client to sign off on a version
Webflow is not empty here. Its Reviewer role costs no paid seat: the reviewer opens a comment-only view, pins a remark to an element, replies and marks it resolved, and someone without an account can join after verifying their email. It all happens inside the workspace you let them into. (Published help material; their site blocks automated reading.)
Two things separate the rounds. Webflow attaches a remark to the project as it stands, after somebody invites the reviewer. Birta attaches it to a version: every version has its own permanent address, and whoever holds it opens the page with no account, no seat and no invitation, gets a nickname, and marks up the page itself.
The agent reads the threads back with their numbers, elements and timestamps, edits the same draft, and publishes a new version into the tab the reviewer already has open. Numbers are permanent, so "number three is still open" names one remark next week.
Webflow's reviewer closes their own thread, and create_reply lets an agent answer in one. On Birta the agent does both: after the fix it replies in the thread and closes it. Remarks go out as one digest roughly 15 minutes after the first, minus your own. Nothing is gated by plan; the walkthrough is in the versions and remarks guide.
For an agency the fork is the seat and the freeze. Webflow reviews the live project with the client inside your workspace. Birta reviews a stored version, so Monday's markup is still Monday's on Thursday. An agency that reviews sites on several hosts will want one tool for all of them, and the website feedback tools comparison covers the ones that work on any address.
Stay on Webflow when...
- The CMS is doing real work. Collections, dynamic pages, filtered lists. Birta publishes static files and has none of it.
- Someone designs by hand. The canvas, breakpoints and interactions reward a person tuning details, not an agent generating output once.
- You want an agent working the design surface. Webflow's does that element by element; ours writes files. The price is the Bridge App open in the Designer while that runs.
- Ecommerce is part of the site. Listings, cart and checkout are built in. Taking payments on your site is not something Birta does yet.
- The client relationship already runs through Webflow: its marketplace, its editor permissions. Leaving a working setup should buy something you need.
Birta fits better when...
- An agent produces the client site, Birta's own or yours, and what is left is publishing it and handling the form.
- A bad update has to be reversible. Every publish becomes a version, the last 10 stay, and any goes live again with the original files.
- The deliverable has to leave on demand. Each saved version downloads as one archive of exactly what was published.
- A real form belongs on the page and somebody has to see the submissions without wiring up a second tool.
The trade: no CMS, no canvas, no Ecommerce, no payments yet. Birta is narrower on purpose, and the narrow part is everything after the files exist.
Moving from Webflow
Webflow's code export is a reasonable start and does not carry everything. The alternative is connecting Webflow's server to your own agent and reading the pages, elements and CMS items straight out of the project.
What survives: static HTML per page, CSS, JavaScript including the animation logic Webflow generates, and your uploaded images and fonts. Plain, editable code.
What does not: CMS Collections and Ecommerce export as empty shells, because both need Webflow's backend to render, and forms keep their markup but submit nowhere. If the site leans on any of those, plan to rebuild that part.
- Step 1Get the content outPull the static export, or connect Webflow's own server to your agent and read the pages and CMS items from the project. Either way, note what depended on the CMS, Ecommerce, or native forms.
- Step 2Rebuild what didn't exportHand the static files and a description of the missing pieces to Birta's agent or your own, and have it rebuild the form and any dynamic content as part of the new site.
- Step 3Publish and verifyPublish through Birta, check every page and the form submission, then move an owned domain's DNS once the new site passes review.
So: a rebuild of the dynamic pieces, a straight carry-over of the static ones. After the first publish, every change, version and client remark runs through the same conversation.
The decision
Webflow is the right call when the site needs a CMS, Ecommerce, or ongoing hand-tuned visual design, and someone on the team is doing that design work directly.
One line has held across every vendor connector we have read tool by tool, Webflow's included. An official agent connection is normal now. A review round exists on several of them. Not one reaches a version history a connected agent can list and put back live, and that is the piece that decides how a bad afternoon ends. Webflow puts a second condition on top of that, because the capabilities touching its design surface want a Designer session held open while they run.
Birta is the better fit when an agent builds the client site and the job left is publishing it, keeping a real version history, and giving it a working lead form, without asking anyone to learn a visual canvas or hold a panel open to do it.
Hand the client site to an agent
Describe it in Birta's chat and its agent builds and publishes it. Or connect the agent you already use.