webflow-agent-kit build log: safe tools for Webflow AI agents

*Open source as the FDE feedback loop — typed, validated operations so agents do not freestyle your CMS.*

I built webflow-agent-kit because every time an AI agent touches a real Webflow site, the failure mode is the same: the demo works on a toy collection, then production hits wrong field types, partial updates, and an agent that invented a slug. The kit is a **TypeScript-first, Zod-validated** tool layer for Webflow — multi-framework, public beta — so agents get safe, structured operations instead of raw hope. That is Forward Deployed Engineering in open-source form: field pain becomes a reusable pattern. Role context lives on my FDE hub; this post is the build log.

The short version

**webflow-agent-kit** exposes Webflow to AI agents through typed tools with runtime validation. As of the public beta that is **62 tools across 13 groups**, shipped as **seven packages** — a core plus adapters for Vercel AI SDK, MCP, LangChain, Google ADK, a skills package and a CLI. MIT licensed. The goal is fewer silent corruptions, clearer errors, and a path toward standard agent interfaces.

Repo: github.com/anilandcode/webflow-agent-kit

Why this exists

Agencies and product teams want agents that draft or update CMS items, audit SEO fields, sync content from docs or design systems, and run plan-approve-apply loops.

Webflow's API is capable. Agents are not. They skip required fields. They pass strings where Webflow expects references or options. They overwrite live items with no staging story. They fail opaquely when a token scope is wrong.

In the 80% nobody demos I argued that production is identity, data, security and ops. For Webflow, **schema and validation are the data plane**. If the tool layer lies, the agent will lie confidently to your CMS.

So the thesis is narrow:

Do not give agents a bare HTTP client. Give them tools that validate inputs and make failure loud.

Same instinct as guardrails on support agents (SupportPilot) and citations on RAG (DotChat) — different surface, same FDE job.

What good looks like for agent plus CMS tools

Webflow's own direction — APIs, MCP, agent-ready surfaces — makes this more relevant, not less. Agents need governed tools, not more tokens.

Architecture

┌─────────────────────────────────────────────┐
│  Agent runtime (Claude, Vercel AI, MCP)     │
└─────────────────────┬───────────────────────┘
                      │ tool calls
                      ▼
┌─────────────────────────────────────────────┐
│  webflow-agent-kit                          │
│  - Zod input/output schemas                 │
│  - 62 named operations across 13 groups     │
│  - Shared error shaping                     │
└─────────────────────┬───────────────────────┘
                      │ validated requests
                      ▼
┌─────────────────────────────────────────────┐
│  Webflow API                                │
└─────────────────────────────────────────────┘

Design choices that mattered:

**Monorepo with adapters.** The core is separate from framework bindings, so the kit is not locked to one agent SDK. That is why there are seven packages rather than one.

**Zod at the boundary.** Types for humans, schemas for runtime. Agents need both — a type alone does nothing at 3am when a model invents an enum value.

**Topological builds.** Package build order matters, and CI must build dependencies before typecheck. We burned time here so you do not have to.

**Beta channel first.** Ship learnable surface area. Do not pretend `latest` means "finished Webflow."

Quick start

npm install @webflow-agent-kit/core@beta @webflow-agent-kit/vercel-ai@beta

export WEBFLOW_TOKEN=your_token_here

import { createWebflowAgentKit } from '@webflow-agent-kit/core';
import { toVercelAITools } from '@webflow-agent-kit/vercel-ai';
import { generateText } from 'ai';
import { anthropic } from '@ai-sdk/anthropic';

const kit = createWebflowAgentKit({ type: 'env' });
const tools = toVercelAITools(kit);

const { text } = await generateText({
  model: anthropic('claude-sonnet-4-5'),
  tools,
  maxSteps: 10,
  prompt: 'List all my Webflow sites and their published status.',
});

Safety defaults I recommend even where the kit allows more: staging site or staging collection first, human approval on bulk writes, scoped API tokens, and a log of every tool call.

What the surface actually covers

Beta is for design partners, agency automations, and builders wiring Webflow into agent workflows who will file real issues. Beta is not a guarantee of full API coverage, zero breaking changes, or set-and-forget production without review.

What broke

**CI and the package graph.** Clean runners failed typecheck when package `dist` outputs were missing. The fix is boring and important: build packages in dependency order, and run build before typecheck in release workflows. Monorepos punish "it works on my machine."

**Scope creep versus a usable beta.** The temptation is every Webflow endpoint as a tool on day one. Agents drown in tool lists and you never ship. The bias was working groups first, then expand as real users demand the next surface.

**Docs versus code.** Agent tools without examples are shelfware. The README has to show install, token, one safe read path, and one validated write path with an approval mindset — or nobody gets past the first five minutes.

How this is an FDE feedback loop

The classic loop from what FDEs actually do: embed and feel the pain in a real customer stack, ship a thin slice that works on live constraints, harden, hand off, then feed patterns back into product or open tools.

webflow-agent-kit is step five made public. Instead of a private client script, the validation patterns become a kit others can fork, file issues against, and improve. That is how open source compounds FDE work beyond a single retainer.

Who should try it

Agencies running Webflow at scale who want agent-assisted CMS operations. Builders wiring Webflow into Claude, custom agents, or MCP-style setups. Teams tired of one-off scripts that corrupt collections. People willing to be design partners, where feedback beats feature requests.

Who should wait: anyone needing an officially supported Webflow agent platform guarantee, teams that cannot review agent writes before production apply, and projects with no staging or backup discipline on the CMS.

Lessons I would repeat

Validate at the tool boundary, because the model will not. Ship beta with a clear list of non-goals — trust beats coverage bragging. Treat CI as part of the product for multi-package kits. And treat open source as a handoff format: future you, and future clients, can extend it.

What is webflow-agent-kit?

An open-source, TypeScript-first toolkit of Zod-validated tools so AI agents can interact with Webflow more safely than raw API calls. Public beta at github.com/anilandcode/webflow-agent-kit, currently 62 tools across 13 groups in seven packages, MIT licensed.

Is webflow-agent-kit an official Webflow product?

No. It is independent open source aimed at agent builders and agencies. It sits above Webflow's official APIs as a validation and tool layer.

Can I use webflow-agent-kit in production?

Only with beta discipline: staging first, least-privilege tokens, human approval on destructive writes, and monitoring. Read the repository licence and README limitations.

How is webflow-agent-kit related to Forward Deployed Engineering?

Forward deployed work turns customer-environment pain into working systems and reusable patterns. This kit is a public pattern for agents plus Webflow without silent CMS corruption.

Where do I file bugs for webflow-agent-kit?

GitHub issues on the repository. Design-partner feedback describing a real workflow and what broke helps far more than a request to support every endpoint.