Natural language generation (NLG) is the production of readable human-language text from structured data, facts, or another representation of meaning. For example, a system can turn monthly sales figures into a sentence explaining that revenue rose compared with the previous month. The sentence is generated text. It does not, by itself, update a report, change a CRM record, or send a message.
NLG includes templates, rules, traditional data-to-text systems, neural models, and large language models (LLMs). The practical question is not simply which model to use. It is which generation method fits the job, what the output must contain, and how to check it before a connected system acts.
This guide distinguishes NLG from NLP and NLU, compares deterministic and flexible generation methods, and shows how to design structured outputs, validation gates, provenance, duplicate handling, and human ownership into an NLG workflow.
NLP vs. NLU vs. NLG: where generation fits
Natural language processing (NLP) is the broad field of techniques for working with human language. Natural language understanding (NLU) interprets language to identify meaning, intent, entities, or relevant details. NLG produces language from information, facts, or intent.
Consider a customer who writes, “Please update my ticket to say I cannot sign in.” A system might interpret the request and represent it as a structured intent such as action: update_ticket and issue: sign-in problem. It could then generate a response confirming what it understood. Updating the ticket is a separate operation that requires an available and authorized action.
This flow is a useful functional distinction, not a required product architecture. A system may combine or rearrange these capabilities rather than expose separate NLP, NLU, and NLG modules.
Choose a generation method before choosing a model
Templates and rules suit bounded, repeatable outputs where approved wording, reproducibility, or auditability matters. Neural systems and LLMs can help when inputs vary and the task calls for explanation, paraphrasing, or synthesis. Choose based on the acceptable range of outputs, the consequence of an error, and whether the result can be checked.
- Use a template for an approved status notice with known fields such as a customer name, case number, and delivery date.
- Use rules when conditions and wording are predictable, such as selecting a standard message from an order status.
- Consider an LLM when a support ticket contains varied prose and the task is to draft a concise explanation or classify the issue for review.
Output variability alone does not reveal how a system works. Templates can contain variable fields, and generative systems can be constrained to produce consistent formats. Reiter and Dale’s 1997 account of applied NLG systems provides a useful conceptual map: determine content, structure the document, aggregate related facts, select words and references, and realize the text with grammar and punctuation. These are ways to reason about a generation task, not six mandatory software stages.
Many modern neural and LLM-based systems do not expose those classic stages as separate user-visible modules, although they may also use explicit planning, retrieval, tools, or deterministic post-processing. The six-task model remains useful for asking what the system must accomplish.
The 2017 Transformer paper introduced an architecture built around attention mechanisms rather than recurrence or convolution. It reported greater parallelization and shorter training time in its experiments. The paper helps explain an important architecture; it does not mean every NLG system needs a transformer or that all current models are identical.
Use fixed wording when the wording must be fixed; use flexible generation when context varies and the result can be checked.
Extractive vs. abstractive summarization
An extractive summary selects sentences or passages from the source. An abstractive summary generates new wording based on the source’s meaning. Extractive output is often easier to audit because it reuses source text. Abstractive output can read more naturally, but it may alter or add details that the source does not support.
Neither method guarantees a faithful summary. Research has documented unsupported content in abstractive summaries, while separate work shows that extractive summaries can mislead through omitted context, coreference, sentence selection, or discourse problems. See the studies on abstractive summarization faithfulness and extractive summarization unfaithfulness.
A copied sentence can still mislead if its pronoun, exception, or meaning depends on omitted text. For decisions involving dates, amounts, or obligations, extract and validate those fields against the source instead of relying on summary prose alone.
For a low-risk internal overview, a concise summary with a source link may be adequate. When a decision depends on exact facts, retain the source reference and verify those facts separately.
Design the workflow: from source record to controlled output
Define the source, output contract, checks, destination, and exception owner before connecting an AI step to another system. This makes clear which facts the model receives and what a later step is allowed to do. For help planning the automation sequence, see Zapier automation consulting.
The following is a hypothetical engineering design for summarizing support tickets, not a vendor template. The input grain is one version of one ticket, identified by its ticket ID and update timestamp. It is not a daily batch, an AI run, or an undifferentiated collection of tickets.
{
"ticket_id": "T-1042",
"ticket_updated_at": "2026-11-10T14:35:00Z",
"customer_account_id": "AC-208",
"ticket_body": "The latest invoice shows a charge the customer does not recognize.",
"source_url": "https://support.example.test/tickets/T-1042",
"language": "en",
"prior_status": "open"
}The AI task is bounded: summarize only the supplied ticket content, choose an issue category and urgency from approved values, and flag ambiguity rather than filling gaps with guesses. A proposed output contract is:
{
"concise_summary": "Customer questions an unrecognized charge on the latest invoice.",
"issue_category": "billing",
"urgency": "normal",
"needs_human_review": true,
"review_reason": "The charge has not been checked against billing records.",
"source_ticket_id": "T-1042",
"source_updated_at": "2026-11-10T14:35:00Z"
}Zapier documents that AI by Zapier can return defined output fields for later Zap steps. Before configuring a destination, define each field’s type, required status, allowed values, maximum length, null behavior, source field, validation rule, review condition, and destination mapping. A structurally valid field does not establish that its content is factually correct.
For traceability, retain the source ID and version alongside the generated result. Where it matters, also record the source URL, prompt or instruction version, model identifier, generation time, reviewer decision, and destination write time. These are proposed design practices, not claims that a product automatically creates the fields. If the generated fields belong in a CRM, CRM systems consulting can help clarify field ownership and guarded updates.
Validation, duplicates, privacy, and ownership
Separate structural validation from factual verification. Require the ticket ID and summary, reject an unknown category or urgency, check that the destination record still exists, and route empty, contradictory, unusually long, or high-impact results for review. Separately compare important claims with source material when the consequence warrants it.
Define the natural key at the same grain as the work. For the ticket example, a proposed key is source system + ticket ID + source version. It distinguishes multiple updated versions of one ticket. A run-level record would need a different key, such as source record ID + input hash + prompt version + model identifier + run ID. A citation-level record should likewise identify the answer, cited source, and citation position rather than being collapsed into a daily summary.
A read-then-create check can race when two runs process the same version concurrently. Use a destination-enforced unique key, database-enforced uniqueness, or a transactional upsert where available. If the destination cannot enforce uniqueness, use a storage layer that can reject duplicates atomically. Treat retries as normal and ensure that a failed downstream write does not create a second record on replay.
- Required fields are present, and categories match an explicit allowlist.
- The source record ID, version, and destination record match the item being handled.
- Important dates, amounts, statuses, and obligations are checked against source data.
- Concurrent replays cannot create duplicates where a write is consequential.
- Empty, unknown, or ambiguous results have a named human owner.
Restrict AI inputs to approved fields, particularly for personalized communication. Verify recipient eligibility and consent before sending, and consider review for sensitive or high-impact messages. Generated text, validation, authorization, and external action are separate controls.
Where NLG is useful: compare the job, control, and destination
These are illustrative workflow designs, not prebuilt integration recipes. Each chain depends on the source, destination action, connected account, permissions, and product path available in the specific environment.
| Trigger or source | AI job | Validation | Action and fallback |
|---|---|---|---|
| Sales figures for a reporting period | Draft a short explanation of changes from supplied figures. | Compare figures, period, totals, and units against the source data. | Save approved narrative with the report. If figures conflict, stop the draft and route it to the reporting owner; prose must not replace the underlying data. |
| New or updated support ticket | Summarize and classify one ticket version. | Require the source ID and summary, validate category and urgency, and check the version key. | Write validated fields to the ticket or summary record. Route unknown, empty, contradictory, or high-impact results to the ticket review queue. |
| Eligible customer record and campaign request | Draft a message using approved CRM fields. | Check field eligibility, recipient status, consent, required approval, and prohibited claims. | Save as a draft or send only after an available authorized action and any required approval. Missing consent routes to the campaign owner. |
| Customer message in a conversational system | Interpret intent and draft a response or structured request. | Check required details and pause consequential or unclear requests for review. | Return a response or call a separately authorized configured tool. Record the actual tool result, not just the generated wording. |
AI by Zapier and MCP: generation is not an app action
AI by Zapier can return defined output fields for later Zap steps. Its tool documentation also describes configurable approval requirements for individual tools. These are documented capabilities, not a guarantee that every workflow or tool call automatically includes human approval.
Model Context Protocol (MCP) provides a standard way for a compatible client to discover and call tools exposed by a server. Zapier MCP documentation specifies Streamable HTTP and says SSE is not supported. A particular action still depends on the configured tool, connected app, account permissions, client compatibility, task allowance, and the target application.
In Zapier-managed app connections, the model can invoke configured tools without receiving the app account’s raw credentials. Review the applicable product, account, logging, and data-processing details before making broader security commitments.
A generated “your refund has been issued” sentence is not evidence of a refund. A refund requires a separately available and authorized billing action, and its result should be recorded. The practical sequence is: generate a draft or structured intent, run deterministic checks, obtain approval when required, invoke an authorized connected-app action, and record the returned result. See AI agent design and implementation for the distinction between generated responses and tool use.
Start small and measure whether the output helps
Pilot one bounded task with a stable source, an explicit output contract, and an accountable owner. For the ticket example, process a limited sample, compare summaries with source tickets, and review exceptions before expanding automation.
Track correction rate, review rate, missing-field rate, duplicate-write rate, and time to complete the task. These are proposed evaluation measures, not reported performance results. Keep a human-reviewed sample in the evaluation process, especially before allowing higher-impact writes.
Expand only when the field contract works, exception ownership is clear, and the destination behaves correctly on retries and concurrent runs.
Frequently asked questions
Does natural language generation require an LLM?
No. Templates, rules, and other data-to-text methods are also NLG. An LLM is one option when inputs vary and flexible language is useful.
Is extractive summarization always more accurate?
No. It reuses source sentences and can be easier to inspect, but omitted context or references can change how those sentences read. Check consequential details against the source.
Can an abstractive summary be checked automatically?
Parts of it can. Validate fields such as dates, amounts, identifiers, and categories against structured source data, then use source comparison or human review for claims that cannot be checked deterministically.
Does generating text change an external system?
No. Generation produces text or structured output. A separate available and authorized action is needed to update a record, send a message, or perform another operation.
Does MCP work with every AI client?
No. The client must support the relevant MCP transport and the configured server and tools. For Zapier MCP, the documented transport is Streamable HTTP, and SSE is not supported.