Fabrizio Ferri-Benedetti is not interesting because he gave technical writers a new job title. He is interesting because he treats documentation as infrastructure.
His work points at a practical shift: docs are no longer only pages for humans. They are also context for agents, validators, support tools, product teams, and future writers.
The bigger frame
“Context curator” is a useful phrase, but it is too small on its own.
Ferri-Benedetti’s broader pattern combines:
- technical writing;
- knowledge design;
- LLM workflows;
- documentation testing;
- small tools that make writing systems more inspectable.
That puts him close to context engineering and AGENTS.md . The writer is no longer only polishing the surface. The writer owns the context layer that AI tools will read.
The operator pattern
The pattern is: own the prompt, own the context, test the docs.
| Layer | What the writer controls |
|---|---|
| Source material | Docs, examples, changelogs, issues, support language. |
| Context shape | Local folders, prompt files, retrieval rules, summaries. |
| Test personas | Fake users that read docs from different levels of skill and intent. |
| Quality checks | Lint rules, RAG checks, contradictions, missing steps. |
| Delivery | A human-readable page and a machine-readable context surface. |
That is a better model than “writer asks ChatGPT to rewrite a paragraph.” It makes the writer responsible for the system around the model.
Tools as argument
The strongest part of Ferri-Benedetti’s public work is that he builds small tools around the argument.
Examples include:
- Impersonaid, which uses personas to test documentation;
- Valegen, which explores AI-assisted Vale rules;
- Aikidocs, which argues that writers should own their prompts and context instead of outsourcing them to generic chat sessions.
The tool names matter less than the habit: do not treat docs as static text. Instrument them.
What teams copy
A docs team can copy this without a reorg.
- Put prompts, examples, and evaluator notes in the repo.
- Add a local
context/folder for product concepts, terminology, and user roles. - Create two or three test personas for new docs.
- Ask the model to fail the docs before publication.
- Keep final judgment with the writer.
This is prompt engineering with receipts. The prompt is not a magic phrase. It is part of a documented workflow.
Why it matters
AI makes bad documentation fail faster. A vague page becomes vague context. A missing prerequisite becomes a broken agent answer. A stale example becomes a generated bug.
The upside is just as direct. Good docs can become:
- better support answers;
- better onboarding;
- safer automation;
- cleaner internal memory;
- reusable context for coding agents and product teams.
That is why Ferri-Benedetti fits self.md. He is a practical example of the writer as context engineer.
Internal map
Use this page with:
- Context engineering for the discipline.
- AGENTS.md for repo-level instructions.
- Tom Johnson on AI technical writing for the writing role shift.
- MCP servers for connecting docs and tools to agents.
For agents
| Field | Content |
|---|---|
| Thesis | Fabrizio Ferri-Benedetti shows that technical writers can own the AI context layer, not just the prose. |
| Proven pattern | Git-backed context, prompt ownership, persona-based docs testing, and small tools around documentation quality. |
| Copy tomorrow | Put prompts and context files in the docs repo, then test a page through two user personas before publishing. |
| Do not claim | Do not reduce him to the phrase “context curator” or claim fixed tool metrics without checking. |
| Internal links | /concepts/context-engineering/, /concepts/agents-md/, /people/tom-johnson-ai-technical-writing/, /tools/mcp-servers/ |
Sources
- Fabrizio Ferri-Benedetti
- From technical writers to AI context curators
- Own the prompt
- Impersonaid
- Valegen
Next: Context engineering