Vercel used to burn engineering and marketing hours turning infrastructure work into a customer-readable changelog entry. "We put a lot of work into drafting up our product change log," CEO Guillermo Rauch says on the Agent Native podcast in August 2026. Then the fix, in one sentence:
"Because we have an agent internally, we've cut down that process into one Slack thread that the engineer creates"
One thread. That's the whole interface.
Operators hear claims like this and can't see the machinery. Search for an AI workflow automation example, and you get git-commit toys or twelve-item listicles. What's actually inside Vercel's workflow? Where does a human say yes? What file holds the instructions, and what happens when the output goes bad?
So let's tear one down. Below is the full anatomy of a governed skill, translated to a stack you'd recognize (Acme Corp: Slack, HubSpot, a WordPress blog), with the skill file, the gate, and the measurement shown, not described.
The short version: Vercel's CEO says an internal agent cut their changelog process to one Slack thread. This post tears down what that workflow looks like as a governed skill: a plain markdown file, an event trigger, a scoped tool, a human gate before anything publishes, and a log. In January 2026, Gartner reported at least 50% of GenAI projects were abandoned after proof of concept (Gartner, 2026). The anatomy below is what the surviving half builds.
What did Vercel actually automate?
A cross-team content process, end-to-end. In January 2026, Gartner's analysis of GenAI project failure found that at least 50% of GenAI projects were abandoned after proof of concept by the end of 2025 (Gartner, 2026). Vercel's changelog workflow is one that survived, and its CEO described it in enough detail to dissect.
Rauch describes the before-state himself: "It used to actually take a lot of work for an engineer that is in the depths of infrastructure to collaborate with a marketing team and get that thing out into the world" (~45:01). An engineer shaves seven seconds off deployment times. Marketing has to find out, understand it, and write it up for customers. Handoffs pile up. The entry ships late or not at all.
The after-state: the engineer opens one Slack thread. The agent, which Vercel calls V, does the translation work. "The agent refines what they're telling me because... engineers are sometimes so in the weeds that they struggle to communicate things in a way that is, I call it, context-free" (~45:14). The output he wants reads like this: "Simple, seven seconds. It's enabled for every customer; it's free" (~45:35).
Why is this workflow the perfect specimen? Four reasons. It crosses teams (engineering to marketing). It recurs with every release. It has a system to it, a repeatable formula. And the output is public, so quality failures are visible to customers, not buried in a dashboard.
One honest sentence before we go further: these are Rauch's claims about his own company, cited in the podcast. I didn't verify Vercel's internal numbers, and neither can you. What we can verify is the anatomy, because the parts are standard.
Here's what that thread looks like translated to Acme Corp, our placeholder company:
What is a skill, in plain terms?
A skill is a Markdown file that tells a coding agent how your company does one thing. The format has already won: Firecrawl's tracker of the open agent-skills ecosystem counted growth from 2,179 to more than 40,000 published skills in 20 days in early 2026 (Firecrawl, "Agent Skills", 2026). The open question isn't the format. It's governance.
Inside the file: instructions, examples, output rules, and limits. Any developer can read it. So can you, because it's written in plain language, not code. There's no proprietary layer holding your work hostage; the file moves with you if you change tools.
Now the part most explainers miss. The skill isn't documentation about the agent. The skill IS the asset. Listen to what Rauch says he put into his: "People want to know what's the benefit, how much does it cost, and what do I do to get it?" (~45:47). And then: "that formula that I developed over many years of product marketing skill, I put into that Eve agent" (~46:00).
Read that again. A CEO's decade of product-marketing judgment, compressed into three questions, written into a file. The agent is just the courier. The formula is the deliverable, and it now runs on every changelog entry without him in the room.
That's the business case in one move. You're not buying model intelligence. You're capturing the judgment of your best person on one task, so the task stops depending on their calendar. Which is also why the shape of the workflow, not the tools, decides whether any of this works.
What does that file actually look like for a real business workflow? That's the teardown.
The teardown: one changelog skill at Acme Corp
A governed skill for this workflow has exactly five parts: a trigger, a skill file, a tool with scoped access, a human gate, and a log. In November 2025, McKinsey's State of AI survey of 1,993 organizations found 62% experimenting with or scaling AI agents, while only about a third had scaled AI beyond pilots (McKinsey, "The State of AI", 2025). The missing parts are usually four and five.
Part by part, all placeholder data:
1. The trigger. An engineer posts in #releases at Acme Corp. That's a Slack event, nothing exotic. No form, no ticket, no new tool for anyone to learn. The workflow starts where the work already happens.
2. The skill file. The heart of the thing. Here's the complete file, runnable as written:
markdown
---
name: changelog-draft
description: >
Draft a customer-readable changelog entry from an engineer's
release note posted in #releases. Draft only. Never publish.
trigger: slack message in #releases
tools: cms-draft (draft-only access to blog.example.com)
owner: marketing-ops (Dana at Acme Corp)
---
# Changelog Draft Skill
## What you do
Turn the engineer's release note into one changelog entry
customers can understand without knowing our infrastructure.
## The formula (every entry answers three questions)
1. What is the benefit? Lead with it. Plain words, one sentence.
2. What does it cost? Say "included in every plan" or name the
plan. Never invent pricing.
3. What does the customer do to get it? "Nothing, it is already
on" or the exact steps, max three.
## Voice rules (Acme Corp)
- Second person. "Your exports finish faster."
- Numbers over adjectives: "40 seconds, was 3 minutes,"
never "blazing fast."
- Max 80 words per entry. No exclamation marks.
- If the engineer's note names internal systems (queues, flags,
services), translate or drop them.
## Output format
- Title: benefit in six words or fewer.
- Body: benefit, cost, how to get it. In that order.
- End with the date and the product area tag.
## What you may not do
- Never publish. Create a CMS draft and request approval.
- No pricing claims beyond the plan names in /docs/plans.md.
- No customer names, logos, or usage numbers. Ever.
- No forward-looking promises ("coming soon").
## Approval request format (required fields)
- The full draft body, not a summary.
- Target URL and scheduled publish time.
- Rollback path: the draft ID and the one-click unpublish step.
- The engineer's original note, linked, for comparison.No competitor post I found while researching this shows a complete business-workflow skill file with a governance section. You just read one. Steal it.
3. The tool. The agent gets draft-only access to the blog CMS. Not admin. Not publish. Rauch describes the same pattern at Vercel: the agent "ends up being sort of the facilitator of the transaction, but it doesn't have direct access to WordPress itself" (~30:02). The permission system you already have does the enforcing, which is exactly where the gate belongs: inside the tool.
4. The gate. A human approves before anything is published. It gets its own section below, because it's the part everyone waves at and nobody designs.
5. The log. Every draft, edit, approval, and rejection gets recorded: who, what, when. Without it, the workflow can't be audited, and six months from now, nobody can answer "why did we publish that?"
Where does the human gate sit?
Between the draft and the write action. That placement is deliberate, and it's the least automated part on purpose. In July 2026, Schellman's survey of 525 US enterprise professionals found 74% say they could pass an AI compliance audit today, while only 27% describe their governance as fully mature (Schellman, 2026). Most gates exist in the deck, not the workflow.
Rauch's test for gate placement is an intern: "Now you hire an intern. Can the intern ship any blog post that it authors together with your internal agent to prod? You probably don't want that" (~29:11). Same logic for the agent itself. He's blunt that this is the builder's job: you define "the tools, the human-in-the-loop approvals, and the data access controls for anything that the agent can do" (~18:07).
Here's where I push past the podcast. "Human in the loop" as a phrase is saturated; every vendor claims it. The difference between a real gate and a checkbox is what the reviewer sees. At Acme Corp, the approval request shows the reviewer the actual pending change: the exact post body, the target URL, and the rollback path. Not a summary. Summaries are how reviewers approve things they never inspected.
Want the receipts on why that matters? In February 2024, engineering firm Arup lost US$25.6 million in Hong Kong: an employee approved 15 transfers after a video call where every colleague on screen was a deepfake (South China Morning Post, 2024). An approval happened. The reviewer couldn't inspect what they were approving. A gate that shows a summary instead of the change fails the same way, just quieter.
Full disclosure: at PromptMetrics, the replayable, step-level approval object (every gate decision stored with the exact pending change and an idempotency key) is designed, not yet built. The Slack-approval pattern above is buildable today with standard parts; our sharper version is on the bench. I'd rather tell you that than imply otherwise.
Does the gate slow the workflow down? Barely, and it's the thing that lets the workflow ship at all. The same Schellman survey found organizations with mature governance run agents in production at 78%, versus 22% for developing programs (same source). Governance isn't friction. Governance is the new job, and the gate is its smallest unit.
The baseline: what Acme Corp measured before building
Before the skill existed, Acme Corp timed the manual workflow for two weeks. Why bother? Because in May 2025, IBM's Institute for Business Value study of 2,000 CEOs found only 25% of AI initiatives had delivered their expected ROI, and only 16% scaled enterprise-wide (IBM IBV, 2025). You can't compute ROI on a workflow you never timed.
Baselining is boring, and it's the discipline everyone skips. Acme Corp recorded four things, alongside normal work, no new software:
Who touches each changelog entry, by name and role?.
Elapsed calendar time from "shipped" to "published."
Number of handoffs per entry.
Where entries stall (the honest one: waiting on marketing review, every time).
Rauch himself grounds engineering productivity in this exact output. His measure of whether the team is shipping: "Have you shipped something that we can communicate to customers" (~44:20). The changelog is his metric surface. The baseline is what makes your after-state a fact instead of a feeling.
One scope note: this post assumes you've already chosen the workflow. Choosing well is its own discipline, covered in how to pick your first workflow.
What breaks, and who fixes it?
The skill drifts. Not might: does. Fixing it is meta-work, and in the same January 2026 analysis, Gartner names poor change management among the five reasons GenAI projects die after the PoC (Gartner, 2026). The build is a fortnight. Maintenance is the job.
Rauch's escalation story is the pattern to copy. A published post reads "like complete claw slop." The response isn't scolding the output or the agent. "You work on the content writing skill of your Eve agent. And so this is the meta work that we will all be doing in the future" (~30:46). And the mechanism: "You're putting that intelligence into the agent in the form of skills, in the form of tools" (~31:06). I unpack that habit in work on the skill, not the output.
At Acme Corp, the same story looks like this: the product gets renamed, the agent keeps using the old name, and the tone drifts flat. The fix is a three-line edit to the voice rules in changelog-draft.md, logged like a code change. Ten minutes, owned by Dana in marketing-ops.
Where it still leaks. Three failure modes I'll name plainly, each with an owner:
The rubber-stamp gate. Volume grows, reviewers start approving on autopilot. Owner: whoever holds the gate rota. Fix: sample-audit five approvals a month against the log, and test the skill before you trust it.
The stale skill file. Nobody owns it, so nobody edits it, so it quietly rots. Owner: named in the file's frontmatter (Dana, in our example). No name, no skill.
The unread log. A log nobody reads is a compliance prop. Owner: The workflow owner reviews it monthly, for fifteen minutes, calendar-blocked.
Maintenance is the difference, not the model. In September 2025, BCG's survey of 1,250 executives found only 5% of companies generating substantial value from AI at scale, while 60% saw minimal gains (BCG, 2025). The 5% do the meta-work. 60% bought the demo.
Field note from our own rebuild. I drafted this exact class of skill for PromptMetrics' publishing workflow, and the first version got two things wrong. The voice rules were too thin ("write like us" is not a rule), so tone drifted within a week; the fix was five concrete rules with examples, like the Acme file above. And the approval request had no rollback line, so saying yes felt like jumping without a rope; one required field fixed it. Both were one-line lessons that cost me a week each.
Frequently asked questions
What is an AI agent skill?
A plain Markdown file that encodes how your company does one task: instructions, examples, output rules, and limits. Any developer can read and maintain it, and so can you. In early 2026, the open skills ecosystem grew from 2,179 to over 40,000 published skills in 20 days (Firecrawl, 2026).
Does a governed workflow mean a human approves every action?
Every write action, yes: publishing, sending, updating a record. Drafting and research run without approval. The gate pays for itself: in 2026, Schellman found organizations with mature governance run agents in production at 78%, versus 22% for developing programs (Schellman, 2026).
How long does it take to build a skill like this?
One workflow, one governed skill, one to two weeks of build at fixed scope: that's the First Skill Sprint shape (€8,000 to €12,000, published pricing, fixed deliverables). The baseline measurement comes first and takes about two weeks of passive timing alongside normal work, so the after-number means something.
Why did Vercel's changelog example matter?
Because a CEO running an internal agent used by almost 1,000 people described, on the record in 2026, the same anatomy operators need at a 20-person scale: a skill file encoding senior judgment, an event trigger, a scoped tool, and an approval before production (Agent Native podcast, 2026). The parts don't change with headcount.
The anatomy, one last time
One workflow, five parts: trigger, skill file, scoped tool, human gate, log.
The skill file is the asset. It captures your best person's judgment and moves with you.
The gate is a designed artifact, not a checkbox. The reviewer sees the actual change and the rollback path.
Baseline first, or the after-number is fiction.
Someone owns the meta-work, by name, or the skill rots.
If you can name your one broken workflow in a sentence, that's the whole entry ticket: book a Discovery conversation (free, and we'll tell you honestly if we're the wrong fit). Choosing a partner instead? Here's how to evaluate an implementation partner. Still watching from the sidelines? Operator Stack is where operators compare notes.
