Publishing with agents
Agents use the same publishing workflows
Once an AI tool is connected to Webflow through the Webflow MCP server, an agent can make and publish changes on your behalf.
The important thing is that the publishing model doesn’t change.
The agent makes the change, but you want to review it before it reaches production.
You can use the same workflow you would for work created by a teammate: keep the change isolated if needed, review it, publish it to staging, and move it to production when it’s ready.
.png)
Depending on the work and the access available, an agent can operate within the same publishing workflows you’ve already learned, including publishing to staging, production, single-page publishing, CMS item publishing, etc.
So whether a person or an agent is doing the work, the same question still applies: What should be published, and how should it move through your workflow?
How do permissions work with agents?
Agents work within the Webflow access and permissions available through the connection they’re using.
They can’t use an agent connection to bypass publishing restrictions.
For example, if the person using the connection can’t publish the full site to production, the agent can’t use that connection to publish the full site to production either.
The same principle you use when setting up your team applies here:
.png)
Can I use the same review workflows with an agent?
Yes — If an agent-created change needs review, you can use the same safeguards you’d use for other work.
For example:
- Use a page branch when the work should stay isolated while it’s reviewed.
- Use comments or approvals when someone needs to review the work.
- Use staging when the change should be tested in a published environment before production.
The work may have been created by an agent, but the review process should be the same.
How do I see what an agent changed?
Activity from MCP-connected tools appears in the Site Activity log.
That gives your team a place to investigate questions like:
- What changed?
- When did it change?
- Who initiated the activity?
- Where did the activity come from?
Source information helps distinguish activity performed directly in Webflow from activity that came through an MCP-connected tool.

You’ll take a closer look at the Site Activity log later in the course.
Use the same guardrails
Permissions
Control what the person — and the agent working through their connection — is allowed to do.
Review
Use branches, comments, approvals, and staging when work needs another look before production.
Publishing scope
Choose the same full-site, single-page, or CMS publishing option based on what’s ready.
Activity history
Use the Site Activity log to understand what happened and where the activity came from.
Use the same permissions, review steps, publishing scopes, and activity history you already use with your team.
Got it down?
Next, you’ll move from individual publishing workflows to preparing for a full-site launch.