This part is a plain description of what's on the shelf, with no recommendations attached. The point is to see which capabilities have already been productized, so that you can tell what you'd be rebuilding and what you'd be genuinely inventing. Capabilities are accurate as of August 2026 (with a few September 2026 finds woven in below — LocIn, ContentRX, Gummble, Ditto Specs) and they move fast, and company sizes are approximate.

The two purpose-built tools

Only two products exist whose entire subject is UX content, and both are small teams. Their full mechanics are on their cards — Ditto and Frontitude. What matters at this level:

• Ditto (~15 people) is the most complete. It owns the string system of record and reaches it from five surfaces: a Figma plugin, a web app, an MCP server, a GitHub PR bot, and a CLI, plus a packaged set of agent skills. Its 2026 additions were all agent-facing — including Specs (component-level .ditto.md files that list each text surface and the rules that apply, so an agent loads only the rules for the surfaces it is touching) and an agent package that bundles the connection, standing instructions, and review skills so the copy library is default equipment rather than a tool someone must remember to call. See the Ditto card.
• Frontitude (2–5 people) is Figma-first, and its distinguishing idea is architectural rather than featural: content guidelines attach to design-system components, so the design system does the retrieval. Through 2026 it also pushed review from Figma (rebuilt plugin in August), push-from-code into the library, and agent read/edit of workspace copy. Its MCP integration entered early access in August 2026. See Frontitude.

Emerging beside these two — not replacing them — are agentic review and evidence products such as ContentRX (one editorial standard across chat, editor, PR, and CLI) and Gummble (searchable library of real shipped screens and microcopy for agents). They are commercial layers for checking and researching copy; they are not string systems of record. Be honest about that when you compare them to Ditto or Frontitude, and about what is open versus paid.

The two enterprise governance platforms

Neither is a UX content tool. Both govern all of a company's content — documentation, marketing, support, legal — with UX copy as one content type among many. They matter here because they solved terminology and style enforcement at scale years before the content-design tools existed, and because their customers are the enterprises a content team competes with internally for budget.

• Writer (~600 people).
  • Runs a proprietary model, Palmyra, with a company knowledge graph behind generation.
  • Enforces terminology, brand voice, and compliance across Docs, Word, Chrome, Outlook, CMS platforms, an API, and a Figma plugin.
  • Enterprise licensing, org-wide rather than per-seat.
  • No MCP or agent surface disclosed — an odd absence, given everything else in 2026.
• Markup AI (~141 people, the former Acrolinx) is deterministic NLP linting with an AI-governance layer on top. Its 2026 positioning is what stands out: governing AI-generated content against the same digitized standards as human-written content, with dashboards for compliance across large content estates.

The localization platforms, where they overlap

These are translation-first products, but four of them ship style-grounding machinery more rigorous than anything in the content-design category — which is why they keep appearing in this report.

• Crowdin treats a style guide as a permanent system prompt. Three ways to create one:
  • Upload it — .docx, .pdf, .md, .xlsx.
  • Generate one by describing your voice in plain English.
  • Have their Copilot reverse-engineer one from your existing translations.
  Once it exists it is addressable by ID in their AI endpoints, so it can be injected into any generation or QA step. Real-time checks flag violations as someone edits.
• Lingo.dev has the most technically rigorous style grounding found anywhere in this research. Four parts:
  • A glossary matched to content by semantic similarity rather than string matching. They report a 59% reduction in terminology errors on regulatory content.
  • Per-locale brand-voice rules.
  • A ranked chain of model providers, with fallback.
  • An independent cross-model review scoring output on MQM dimensions — fluency, accuracy, terminology, style.
• LocIn (around June 2026) is the “ship from the repo” impulse again: a command-line and CI-oriented way to find product strings, translate them, write them back, and validate — with brand-voice profiles for tone and an eye on placeholders like {{name}} staying intact. It sits next to the big localization platforms in spirit, but the doorway is a developer workflow rather than a translator’s workstation. It does not replace deciding what the empty state should say in the source language; clear Spanish of a confusing English empty state is still a confusing empty state.
• Lokalise and Phrase are the two largest by review volume. Their content-relevant capability is context: screenshots attached to keys, character limits per key, and in-canvas preview of every language so text overflow surfaces before development.
• Smartcat adds adaptive machine translation that learns from reviewer edits, plus live in-canvas previews without extra design seats.

The documentation platforms

These platforms publish documentation rather than product copy. They're here because two of them have shipped, as ordinary features, several things this report otherwise describes as unsolved.

GitBook: a style guide as a product object

GitBook's style guide feature is the most complete productization of this report's own recommendations that exists in any tool, content design included. Five mechanics:

• Two audiences, stated. The guide serves the team and the agent, and for the agent it is "the source of truth it must follow whenever it writes, edits, or reviews content. It overrides the Agent's own defaults."
• Progressive disclosure, built into the product. The agent "loads your style guide's first page in full into its context on every task" and reads other pages only on demand from the table of contents. Their instruction: put your main rules on the first page. That is the agent-skill sizing pattern, shipped as a feature.
• Two enforcement tiers, marked by whether a rule has an ID. Numbered rules (G-10, MS-9) are enforceable — the agent flags violations and cites the ID. Unnumbered guidance, like a voice description, is judgment: applied when writing, offered as a suggestion, never flagged as a violation. IDs must never be renumbered or reused, "past flags and your decision log refer to them."
• Templates generated from published guides. Starter, Google, or Microsoft — the latter two "pre-filled with enforceable rules from their source guides," and GitBook updates them when the source guides change.
• Style guides are org-level objects. Shared across sites or forked per site, with an API to list them and to get or update the agent's instructions.

GitBook also generates an MCP server automatically for every published docs site — "Docs published on GitBook automatically generate an MCP server you can hook up to external tools" — plus an agent that drafts updates from support tickets and product changes, and identifies outdated pages for review.

Mintlify, and one claim that doesn't survive checking

• Confirmed: every Mintlify site hosts llms.txt and llms-full.txt at the root and at /.well-known/.
• Not confirmed: the widely repeated claim that every Mintlify site also auto-generates a skill.md. Mintlify serves an agent-skills index on its own docs site — three skills about using Mintlify — but a customer site checked for the same path returned an application shell rather than a skills index. A vendor publishing skills about its own product is not the same as every customer site emitting one.

What this means for content design

• The two-tier idea is now shipping in a product. Coding-agent tooling and OpenAI's Model Spec both tag rules with an enforcement or authority tier (see making a rule hold); GitBook turned the same idea into a numbered-ID convention with citation. Nobody has done this for UI copy.
• Style-guide rules with stable IDs solve the audit problem every serious review tool runs into: a flag you can trace to a rule, and a decision log that still resolves months later.
• The docs world ships the standards; content design ships the tools. A team can install Google's or Microsoft's writing rules in an afternoon — see Vale's registry. No equivalent library of product-copy rules exists to install.

What's productized, by capability

Bold marks the strongest implementation of that capability in the commercial layer. "—" means not found in public documentation as of August 2026, not necessarily absent.

Terminology and hierarchy: the two extremes

These two capabilities sit at opposite ends of what the commercial tools offer. One is the most thoroughly productized thing in this entire report. The other barely exists as a product at all.

Terminology is mature, buyable, and mostly built by another industry

If you want terminology enforcement, you are not on the frontier — you are shopping. The localization and technical-writing industries have been building this for years, and 2026 added AI extraction on top:

• Markup AI — terminology enforcement is its origin story, going back to its Acrolinx years. Governance dashboards across a whole content estate.
• Kaleidoscope (Quickterm / TermCatch) — the sharpest named mechanic in the group.
  • "Terminology Augmented Generation" (TAG) injects approved terms into a generation pipeline in real time, over their own API.
  • TermCatch auto-extracts term candidates from files and web content, AI-clusters synonyms and variants with confidence scoring, and generates definitions, part of speech, and domain metadata.
• XTM — a Termbase Builder that auto-extracts terms from source files, plus Language Guard: real-time alerts when restricted or forbidden terms appear, before delivery, extending into machine-translation pipelines rather than only human review.
• Trados — AI terminology extraction that builds termbases "in minutes" from a corpus.
• Lingo.dev — glossary matching by semantic similarity rather than string match, so "bill" surfaces the "invoice" entry. Reported 59% reduction in terminology errors on regulatory content.
• Crowdin, Lokalise, Phrase, Smartcat — glossaries and termbases as standard equipment, with terms visible inline during editing.
• Writer, Ditto, Frontitude — all three carry approved-term and banned-term lists inside their style-guide systems.
• Open source — terminologue for glossary management; retext and Vale can both enforce term substitutions.

Four mechanics from that industry transfer regardless of what you buy:

1. Hard versus soft enforcement per term. Criticality decides whether a violation blocks or warns — not one global severity for the whole glossary.
2. The termbase exposed via API, so authoring, review, and QA tools all query the same source rather than keeping copies.
3. Termbase checks in the CI pipeline, so violations surface before strings reach anyone downstream.
4. Retrieval grounding on the approved termbase before generation — TAG's whole premise, and the same idea as terminology.

Information hierarchy is reviewed by two other disciplines, and by nobody as content

Hierarchy does get checked in 2026 — just never as a content question. Two adjacent forms exist:

• As accessibility. WCAG tooling checks heading levels, semantic structure, reading order, and ARIA labelling. Real, mature, and automated — but it verifies that structure is machine-parseable, not that it is comprehensible. A page can have flawless heading semantics and still bury the thing the user came for.
• As visual design critique.
  • AI design-review tools and design-review agent skills judge "hierarchy clarity" and how easily a main action can be spotted — but as layout and emphasis, not as words.
  • Figma's native AI reads layout context so generated copy fits the space.
  • A 2026 assessment of these tools puts the limit plainly: they save time on variants and auto-layout, and almost nothing on information-architecture decisions.

Nobody asks the content-design version of the question, which has three parts:

• Does this screen have one clear primary message and one clear next action?
• Does the reading order match the order the user needs?
• If the screen is confusing, is that a wording problem or a structure problem?

Every commercial content tool in this part operates on strings — one at a time, in isolation, with no model of the screen they sit on. The two closest things that exist are both agent skills, not products: the Wix whole-screen review, which treats structural critique as a permitted output, and better-interface on the Figma shelf, which puts writing rules alongside layout, typography and accessibility and insists on one consolidated verdict rather than separate audits.

There is nothing to buy here.

Three things the commercial layer settled

1. The system of record is the product; the AI is a feature.

   Every one of these tools sells a place where approved content lives.

   Between 2025 and 2026 the AI layer changed completely — new models, new surfaces, MCP — while the libraries, component linking, and review workflows stayed put.

   That stable part is where the years of work are. It is also the part an internal build usually already has in some form: a translation-key system, a design-system doc, a spreadsheet.

2. Agent surfaces arrived everywhere in 2026, and nobody treats them as optional.

   Ditto shipped an MCP server, a PR bot, a CLI, Specs, and an agent-skills package. Frontitude entered early access. The localization platforms shipped MCP servers across the board. Newer commercial layers such as ContentRX and Gummble sell the agent doorway for review and evidence rather than for owning the library.

   The bet is uniform: copy will increasingly be generated inside coding agents, so whoever's rules the agent consults becomes the source of truth. Writer's absence from this pattern is still the exception to watch — as of the August 2026 commercial sweep, no MCP or agent surface was disclosed; this draft does not invent later Writer features without a verified source.

3. "Cite the rule" became table stakes.

   Ditto, Writer, Markup AI, and Crowdin all name the rule behind a flag rather than issuing an unexplained rewrite. GitBook goes one step further and cites a stable rule ID.

   This converged because of the trust math for review tools. Once a meaningful share of suggestions are wrong, users stop trusting all of them — and a suggestion that names its rule can be argued with, which is what keeps it trustworthy.

What nothing commercial covers

Verified absences as of August 2026 — checked against product documentation, not inferred. These are the openings an internal build has to itself. (September 2026 additions such as ContentRX and Gummble narrow the review and evidence gaps a little — same-standard multi-surface checking, and searchable microcopy from shipped products — but they still do not own a string system of record, and they do not close whole-screen structural review.)

• Whole-screen structural review — the clearest gap, covered in detail above. Per-string grading can still miss a broken screen — nothing on the shelf sells frame-level content critique as a product. (See the described Coinbase Figma build in Part 1.)
• Comprehension testing. No product simulates a reader and reports what they would do. Persona panels exist as a general technique (simulated readers) but no content tool has adopted them.
• Research grounding. No commercial content tool reads a research repository. The connector exists (Dovetail's MCP); nobody has wired it to content review.
• A published eval methodology. None of the four discloses how it knows its suggestions are good. Markup AI ships dashboards and Ditto ships analytics, but no rubric, no calibration method, no accuracy figure.
• Code-grounded context. Ditto's onboarding agent reads a codebase once to build a library. Nothing reads the code at review time to check which states and actions actually exist.
• An open microcopy benchmark. No vendor publishes one, and none exists publicly — so nobody can compare these tools on output quality, including the vendors themselves. (Evaluation machinery exists in the open — see writing-eval — but there is nothing labeled to point it at.)

  Checked against Hugging Face, 24 Aug 2026. A sweep of models, datasets, and spaces for microcopy, UX writing, and UI copy returns no quality-labelled dataset of any size. The only UI-related datasets are the Screen2Words and RICO family — screen captioning corpora from 2023–2025, which describe what a screen does rather than judge how well it is written. The only models tagged for this work are ux-writing-1 and its three variants; everything else returned is marketing and ad copy. The gap is real, rather than merely undocumented.

Where the blocker actually is

Three findings from the August 2026 sweeps locate it fairly precisely, and none of them is about capability.

First: a Google team used the exact mechanic that could govern copy to fence copy out.

The site-kit-wp repo ships a Gemini review style guide with a section headed "User-facing copy comes from design." It instructs the reviewer: "Treat user-facing strings and i18n copy as authored against design (Figma) and product decisions. Do not suggest wording, tone, or capitalization changes to display strings."

The agent could review copy. It is told not to, because copy authority lives in Figma — outside the repo the agent can see.

Second: of the big-tech design systems checked, almost none publishes its product-copy guidance in a form an agent can read.

• Atlassian is the counter-example, twice over. It ships llms-content.txt, and its public MCP server serves the same UX-writing foundations as a live tool call — messaging types, voice and tone, inclusive language, grammar and style.
• Material Design has real UX-writing pages — style guide, word choice, grammar and punctuation, all deferring to AP Style. But the site is a JavaScript application with no llms.txt and no markdown, so an agent cannot reach any of it.
• Microsoft's guide exists as markdown, but only in an archived repo.
• Apple's writing guidance has no machine-readable surface at all.
• AWS Cloudscape is the exception, and by side-effect: it serves a markdown version of every page, so its error-message rules happen to be readable today.

Third, and most telling: the companies building these tools do not publicly govern their own product copy with them. A sweep of the AI labs and AI-native products found one public artifact governing a company's own user-facing strings — Gemini CLI's string-reviewer, and it is dogfood-only. Four companies govern their own long-form documentation well: GitHub, Anthropic, OpenAI, Lovable. One does both — Vercel, with a voice test that fails a build. For product interface copy the record is near-silent.

The sharpest data point: anthropics/skills/brand-guidelines publishes Anthropic's own brand as a machine-readable skill, and it contains colours and typefaces only — no voice, no tone, no terminology. The same asymmetry as every design system in this report, at the company that ships the agent runtime.

Put together, this means the tooling to govern copy exists and the guidance exists, but the two are kept apart from each other. Copy is owned in design tools, while the agents work in repos.

That is an organisational boundary, not a technical one — which is why the builds that solved it all did the same thing first. They put the rules where the agent already works.

Read against Part 1, the shape is consistent:

• The commercial layer has solved storage, propagation, multi-surface distribution, and rule-citation — hard infrastructure that took years.
• Internal builds are ahead on the judgment layer, the input layer, and the measurement layer, because those require your doctrine, your research, and your definition of good.