Document Writer Agent

The Document Writer agent generates well-structured, professional documents from the instructions you give it. When a step in a workflow needs to produce a real document (a report, a brief, a policy draft, meeting notes), the Document Writer creates it as structured HTML, can revise it section by section, and keeps a version history you can refer back to.

In the AI Employee builder, the Document Writer Agent appears in the Generation group of the agent library. It is a preset built on the document_agent base type, shipped with instructions already written for document generation, so you can drop it onto a workflow and configure only what you need.

When to use it

Reach for the Document Writer when a workflow needs to produce a document as its output, rather than answer a question or pull data out of text:

  • Draft a structured report or summary from upstream research.
  • Generate a first-draft document (a proposal, a policy, an onboarding guide) that a person will review.
  • Revise an existing document section by section across a multi-step conversation.

If you only need a short text reply or an answer from your knowledge base, use a Custom Agent with a knowledge base attached. If you need machine-readable JSON, use the Data Extractor Agent.

How it works

The Document Writer runs on the shared agentic loop (see the Agent Reference overview), with a document-specific instruction block appended to your Instructions. It has three built-in document tools available in its loop:

  • create_document — produces a new document. The agent is instructed to emit well-structured, semantic HTML: an <h1> title, <h2>/<h3> headings, and every major section wrapped in <section id="..."> tags with descriptive IDs (for example <section id="introduction">).
  • update_document — revises an existing document. The agent first calls get_document to read the current content, then applies a change. It can target a single section by passing the section's id (the server merges the new HTML into the full document) or replace the whole document at once. Sections that weren't asked to change are preserved.
  • get_document — reads the current content of a document. This is read-only and always runs before an update.

The agent also behaves conversationally: if the request is a question or chat rather than a document operation, it replies in text without touching the document tools, and after creating or updating a document it returns a brief plain-language summary of what it did. When knowledge bases are attached, it can call search_knowledge_base to gather context before writing, and it can call ask_human to ask a clarifying question when a request is vague (unless HITL is turned off on the node).

Configuration

The Document Writer ships with its instructions pre-filled and exposes these advanced settings in the builder:

SettingPurpose
InstructionsThe system prompt. Ships pre-filled with document-writing guidance; edit it to set the document's purpose, tone, and structure. Supports {{input.<field>}} placeholders.
LLM configurationThe model and generation settings, served through EmaFusion™.
Knowledge basesOptional. When attached, the agent can research with search_knowledge_base before writing.
HITLOptional human-in-the-loop. When enabled, the agent can pause to ask a clarifying question via ask_human.

The underlying document_agent base type needs no type_config — its document instructions are self-contained. The default Instructions are:

You are a document writer. Generate well-structured, professional documents
based on the provided instructions. Use clear headings, organized sections,
and appropriate formatting.

User instructions: {{input.instructions}}

Not version-managed. document_agent runs on the shared engine and carries a single live v0 catalog entry (so it resolves through the catalog API), but it gains no additional versions and skips publish-time version validation. See The agent-type catalog.

Inputs and output

The preset declares one input field, instructions — the text describing what to write. You wire it on the node through input_mapping, the same way as every other agent.

Input

{ "instructions": "Write a one-page onboarding guide for new support agents, covering the ticketing tool, escalation paths, and the on-call rotation." }

Output

The agent's primary output is its conversational reply — a short, plain-language summary of what it produced. The documents it created or edited are surfaced separately in a document_operations array, so a downstream node (or the UI) can link to the result without parsing the model's text:

{
  "output": "I've drafted a one-page onboarding guide with sections for the ticketing tool, escalation paths, and the on-call rotation.",
  "document_operations": [
    {
      "type": "created",
      "document_id": "doc_a1b2c3",
      "title": "Support Agent Onboarding Guide",
      "version_number": 1
    }
  ]
}

Each entry in document_operations records one create or update:

FieldMeaning
type"created" or "updated".
document_idStable ID of the document. Use this to reference or fetch it downstream.
titleThe document's title.
version_numberThe version this operation produced. Each edit increments it, preserving the history.
change_descriptionFor updates, a brief summary of the edit.
section_idFor section-scoped updates, the id of the section that changed.

In the builder, a Document Writer node exposes document_id and document_url output ports so you can pass the result to a publish step or a later node.

PPTX deck generation

When a workflow generates a presentation deck rather than an HTML document, the underlying document generation service handles PPTX files through a separate slide-rendering pipeline. This pipeline has two improvements that affect the quality of generated and exported decks:

Per-slide original and styled variants. The service now stores both the original slide content and a styled variant for each slide in a deck. When polling a deck for status, the response includes batch slide data and per-slide thumbnails alongside the deck status, so a downstream step can display or compare both forms without making additional requests.

Improved colour and fill export fidelity. PPTX-to-HTML render fidelity increased from 62% to 90%. Fills, background colours, and shape fills that were previously dropped or approximated now export accurately. The exported PPTX is also byte-identical to a round-trip through the same source, so decks you generate match what recipients open in PowerPoint.

Deck status polling. The deck generation endpoint uses a unified /status polling model: a single call returns the deck's overall status, the batch slide list, and slide thumbnails together. Callers no longer need to poll slides and thumbnails separately.

The PPTX pipeline is distinct from the document_agent preset described above. The document_agent produces HTML documents. PPTX output is produced by a dedicated deck-generation workflow in the document generation service, not by placing a Document Writer node on a workflow.

Example

A workflow that turns a research step into a polished brief:

  1. A Custom Agent node with a knowledge base attached researches a topic.
  2. A Document Writer node takes that research on its instructions input and produces a structured HTML brief, returning the new document's document_id.
  3. A publish node delivers the document to the requester.

What's next

Last updated: Aug 27, 2026