Before AI builds your n8n workflow, write the workflow compiler brief

The requirements doc is open in one tab. A model that can output n8n workflow JSON is open in the other. The doc says: when a new estimate request arrives, qualify it, enrich the company, and create the follow-up task.

That sentence sounds specific until you ask it to become software.

Which inbox counts as the source? Which fields may be read? Who owns the enrichment key? Is the follow-up task a draft or a live assignment? What happens when the company name matches two records? Can the workflow update the CRM, or only prepare a note? The requirements doc does not say.

A person would stop the meeting and ask. A model usually completes the job. It fills the empty parts with choices that look reasonable enough to survive a quick glance.

That is why a current r/n8n question about which AI model is best for generating n8n workflows directly from requirements documents matters. The conversation has moved past hand-building every automation. People are asking which machine can translate the doc into the workflow. Beginners are also comparing platforms through that lens, asking whether Make.com is the right place to start for AI automation rather than simply asking which tool moves data between apps.

Here is the safer frame: do not ask the model to invent the workflow. Ask it to compile a brief.

A requirements document is not the thing you paste into the machine. It is the raw material. The workflow compiler brief is the thin, boring, human-authored layer in between. It turns business intent into fields a workflow can actually honor.

The missing middle between doc and workflow

n8n makes this temptation easy because workflows are visible artifacts. They have nodes, connections, triggers, actions, settings, and executions. They can be copied, imported, exported, and inspected. That is good. It also means a generated workflow can look finished before anyone has named the decisions underneath it.

The brief catches those decisions while they are still cheap.

Think of it as a customs form for an automation import. Before the workflow crosses the border into your systems, the form declares what it carries, where it came from, what it is allowed to change, what needs inspection, and what gets rejected.

Without the form, the generated workflow arrives with a smile and a suitcase full of assumptions.

The brief, as a table you can copy

Fill this before you ask any model to generate the n8n workflow. A blank cell is not a detail to handle later. It is an instruction you are about to let the model improvise.

Scroll sideways to see all 3 columns.

Field	What you decide before generation	Example
Business job	The plain-language outcome	Turn a new estimate request into a reviewed follow-up task
Trigger	The exact event that starts the run	New form submission from the website quote form
Source records	The systems and fields the run may read	Form fields, company name, existing CRM account status
Destination records	The systems and fields the run may create or update	Draft task in CRM; no contact update
Credential owner	The named owner of every credential the workflow uses	RevOps owns CRM credential; marketing owns form webhook
Allowed changes	The maximum state change the generated workflow may make	Create draft task only; never assign owner automatically
AI-filled fields	Parameters the model may fill, with allowed values	Lead type in {new, expansion, partner}; urgency in {normal, rush}
Hard validation	Conditions that must pass before any write	Company domain must match one CRM account or stop
Stop condition	What sends the run to a person instead of continuing	Multiple CRM matches, missing email, high-value account
Test packet	The examples used before activation	Five redacted submissions: normal, duplicate, missing data, VIP, spam
Run record	The evidence kept for each execution	Input ID, selected account, proposed task, validation result, reviewer

This is intentionally plain. The value is not the table design. The value is that every row forces a decision into daylight before a generated workflow can hide it in a node setting.

If you do not know which workflow deserves this treatment first, start with the smallest recurring process that has clear handoffs. The weekly workflow audit is a useful way to find that slice before you automate the wrong thing.

Why n8n rewards a stricter brief

The brief is not separate from the tool. It maps directly onto the parts n8n already exposes.

A trigger becomes a trigger node. A destination record becomes an action node. Allowed changes become node settings and review rules. Test packets become manual runs before activation. The brief is useful because it speaks in the grain of the workflow canvas.

The AI-specific part matters most around tool parameters. n8n's $fromAI() function is available only to tools connected to the AI Agent node, and n8n describes its arguments as hints the model uses to populate parameters. That is powerful, but it changes the responsibility of the requirements doc. If a model can fill a parameter, the brief needs to say the allowed values, the default, and the point where the workflow stops instead of guessing.

Credentials are another boundary the model should never choose. n8n has a dedicated credential surface because keys, rotation, ownership, and sharing are operational decisions. A generated workflow may reference a credential shape, but the brief names the owner and the access boundary.

The final artifact should also be reviewed like code. n8n supports workflow export and import through copy-paste, the editor, and the command line. That gives teams a practical way to store the generated workflow, compare versions, and review the shape before activation. If the workflow handles customer data or private operational records, the self-hosting documentation is part of the same conversation about where the work runs and who controls the environment.

A small example: estimate request intake

Here is the difference the brief makes.

The vague request says: When a new estimate request arrives, qualify it, enrich the company, and create the follow-up task.

The compiler brief says:

• The trigger is a new website quote-form submission.
• The workflow may read the submitted fields and existing CRM account status.
• The workflow may create a draft CRM task, but it may not assign an owner or update the contact record.
• The model may classify lead type and urgency only from fixed allowed values.
• If the company domain matches more than one account, the run stops.
• VIP accounts, missing emails, and spam-looking submissions go to a person.
• The test packet includes five redacted examples before activation.

Now the generated workflow has a shape it can obey. It is no longer being asked to decide what the business meant by "qualify." It is being asked to assemble a workflow from declared parts.

That distinction becomes more important as n8n moves into customer-facing and multi-tenant projects. One builder recently described a multi-tenant SaaS on self-hosted n8n running a WhatsApp AI agent. In that world, hidden defaults are not harmless. They touch other people's data, timelines, and expectations.

The model question is still too late

There is still a model choice to make, but it should come after the brief. A separate r/n8n thread from a builder who stopped routing every n8n AI step to the biggest model points in the right direction: not every step deserves the same intelligence.

But the brief comes first. Without it, there is no stable job to route. You are comparing models against a foggy assignment.

With it, you can test whether a smaller model can fill allowed fields, whether a stronger model is needed for edge cases, and whether some steps should be ordinary rules instead of AI at all. That is where AI workflow controls become practical: validation, review, access, and records are tied to named decisions, not vague confidence.

The one thing to do this week

Pick the requirements doc you were about to paste into a model. Do not start by asking for a workflow. Start by filling the table.

If a row is easy, great. If a row is hard, better. That is the point where the business decision was hiding.

Then run the generated workflow against redacted examples before activation. A shadow week is still the cheapest way to find the mistake while nobody is waiting on the output.

If you want a second set of eyes on that brief before it goes live, this is the work we do inside process automation: make the workflow specific enough to build, narrow enough to test, and constrained enough to trust.

Bring one requirements doc. Turn it into a compiler brief before you ask AI to generate the workflow. Start here.