Editable artifacts are the agent handoff
Figma says its MCP deck workflow produced the first 80% of the work. The honest read is that the last 20% is the handoff — so measure time-to-review, not automation rate.
Figma published four ways it uses its own MCP server internally, and buried in the deck workflow is a sentence more useful than the demo around it: the agent produced the first 80% of the content work, and the team still needed image swaps, copy edits, and a review pass.
Most vendor posts would have rounded that to "we automated our decks." Figma named the remainder instead, which is the difference between a case study and a claim.
What the four workflows actually have in common
Look at where each one ends. A generated deck enters review. A FigJam board starts a workshop. Code-canvas changes travel toward a pull request. Not one of them terminates in autonomous publication.
What the agent produces in every case is an editable, native object inside the system where humans already work — a Figma file, a board, a branch. The MCP write tools create and update real Figma objects rather than emitting a flat export; the docs are explicit that download_assets returns original files or renders for up to 20 nodes per call, and the write side mutates native structures.
That is not a limitation of the integration. It is the integration's whole value. MCP shortened the distance to the reviewable artifact. It did not remove the review.
The metric I would swap
Here is the claim I will own, and it is about measurement rather than technology.
Stop reporting agent workflows as an automation percentage and start reporting time-to-first-reviewable-artifact. Automation rate is a vanity number: it describes how much of a task the model touched, which is not the same as how much work left the queue. Time-to-review describes the thing that actually changed — how quickly an accountable human gets something concrete to accept, edit, or reject.
The two numbers diverge in a way that matters commercially. A workflow that automates 80% but emits a PDF nobody can edit has moved the work sideways; somebody now rebuilds it natively to make the changes. A workflow that automates 50% into an editable file in the right tool has genuinely compressed the cycle, because the remaining work happens where the reviewer already is.
Figma's 80% is only impressive because the output lands as a Figma file. Change the output format and the same percentage becomes worthless. That is why the artifact, not the automation rate, is the unit worth designing around.
Why this keeps going wrong in enterprises
At Trigent the pattern I see most often is an agent that is genuinely capable and an output format that is quietly hostile to the next person.
A team builds something that drafts a document, a report, a configuration. It works. Then it hands over a rendered artifact — a PDF, a pasted block of text, a screenshot in a ticket — and the reviewer's first action is to recreate it somewhere they can actually edit. Every gain the agent produced gets spent again in the rebuild, and nobody measures that because the demo ended at generation.
The fix has never been a better model. It has been changing what the last step writes to. When the same agent writes into the live document, the real repository, the actual ticketing object, the review becomes an edit instead of a reconstruction. The capability was identical; the handoff changed.
I have also learned to be suspicious of my own enthusiasm here. The first time a workflow like this works end to end, the temptation is to push for autonomous publication — remove the human, book the full saving. That is usually the moment to stop, because the review pass is doing more than quality control. It is where accountability attaches. An artifact nobody reviewed is an artifact nobody owns.
The scope of the evidence
Worth being precise: these are Figma's own internal cases, not an independent benchmark. There is no third-party measurement of the 80% figure, and there would not be — it is a description of their experience with their tool. The write capabilities are open beta, with two related product integrations still closed beta.
So I am not citing this as proof that MCP delivers a specific productivity number. I am citing it as a well-documented example of where a mature team chose to end the automation, by a company with every commercial incentive to claim more. The choice is the evidence, not the percentage.
What to take into your own stack
The practical question for any agent workflow you are building is not how much of the task the model can do. It is: what object does it hand over, who can edit that object without rebuilding it, and how long until they have it.
If the answer is a native artifact in a governed system, you have compressed a cycle. If the answer is a rendered output that gets manually reconstructed, you have built a very sophisticated way to produce a first draft that somebody retypes. Both feel like progress in a demo. Only one of them shows up in the calendar.
Agents do not remove the handoff — they move it earlier, so build for the artifact your reviewer can edit and measure the time it takes to get there.
