There’s a moment we see in almost every workshop. Someone proudly shows us how well ChatGPT rewrites an email. Two minutes later, the same person says: “But it just doesn’t work for our quotes.” The prompt is two pages long by now, it grows with every attempt — and the result is still a matter of luck.

That isn’t a user error. It’s a tooling error. A prompt is built for a task. Producing a quote isn’t a task, it’s a process.

Why long prompts break on processes

A prompt is one block of text. A process has order, branches, checkpoints — and it should deliver the same thing on the twentieth run as it did on the first. Press one into the other and three things happen reliably.

First: you don’t know where it went wrong. The output is off — but which sentence in your instruction caused it? All you can do is rewrite the whole thing and hope.

Second: the AI fills gaps silently. Whatever you didn’t write, the model invents. It doesn’t ask. It hands you something plausible, and you notice when the quote is already sitting with the client.

Third: none of it is transferable. Your colleague phrases it slightly differently tomorrow and gets a different result. The process still lives in one person’s head, now with a chat window in between.

But the real sticking point is somewhere else, and it’s psychological: most people don’t struggle with wording, they struggle with starting. Sitting in front of an empty prompt field and articulating a complex task in one pass is hard. Ask the same person “What happens first? And then?” and they’ll explain the whole process effortlessly.

Graph engineering: draw it instead of writing it out

Instead of describing the task, you draw it. Every step becomes a node, every dependency an edge. And each node gets its own short description of what it does — not everything at once, but one step at a time. That structure, not the prose, is what you hand to the AI.

The name for this is graph engineering. The full guide, with its principles and glossary, boils it down to one idea: the structure of a request matters more than its wording. Prompt engineering optimises a sentence. Graph engineering optimises the parts, their order and their dependencies.

One clarification, because the question always comes up: this has nothing to do with graph databases like Neo4j. It’s about the structure of your instruction, not about storing data. And you don’t need graph theory — boxes and arrows are enough.

The payoff is concrete. You can see which step is failing and change only that one. You can see the gaps, because an empty node is obvious and a missing sentence in a wall of text is not. You reopen the graph next month instead of rewriting it. And a colleague can read a diagram — she cannot read a 900-word prompt.

Six steps to your first graph

Let’s walk through a real example: producing a quote in a small company. Follow along with a process of your own.

1. Start with the outcome

The single most common gap. Ask first: what should come out at the end — specific enough that someone could check it?

Not “a good quote”. Rather: “A quote as a PDF, with line items, unit prices and a total, plus a short cover email in our house style.” That one sentence determines the quality of everything that follows.

2. Name the steps without writing them out

Names only, two to four words each: capture request → check completeness → determine service type → establish price → assemble quote → check quality → send.

Practically everyone manages this part without effort. That’s exactly why we start here and not with the wording.

3. Give every node a contract

Now you fill the boxes. Three questions per node: what comes in, what happens to it, what goes out?

For “check completeness” that reads: in comes the client request as text. The check is whether service, quantity, deadline and billing address are present. Out goes either “complete” or a list of what’s missing.

Three to five sentences per node is almost always enough. If you need substantially more, that step is really two steps. This unit is what nodalo calls a node contract — a node holds not just a heading, but the definition, the examples, the attached files and screenshots nobody usually passes along.

4. Label every branch

This is where most graphs break. “Determine service type” has two exits, and they need labels: a standard service goes to the price list, a custom solution goes to effort estimation.

An unlabelled arrow is an invitation for the model to invent the condition itself. It will. Also check that your branches are exhaustive: what happens with a request that is neither? If you don’t model that case, it will still occur — just uncontrolled.

5. Build in a checkpoint

This is the step that separates graph engineering from a pretty diagram. Put a review node before the outcome, with written-out criteria: does every line item have a unit price? Is the total correct? Is the salutation right? Is the delivery date within our standard terms?

And add a stop condition: if not, back to “assemble quote”, twice at most, then hand it to manual review. That backward edge turns your graph into a cycle — which is the heart of loop engineering. Without a definition of done, that loop can run forever.

6. Hand the graph to the AI

Finally the structure goes to the model — with a clear brief. Should it document the process? Build a prototype? Generate the automation? Or review your graph first?

That last one is our favourite starting point. Let the model tell you where your description is still vague before you let it build anything. There is no cheaper form of quality assurance.

The four most common mistakes

Oversized nodes. A box called “create quote” with twelve sentences of description is a prompt again, just with a frame around it.

Unlabelled branches. By far the most frequent mistake in practice — and the most expensive, because it stays invisible until the output is wrong.

No defined outcome. Without step 1, everything after it becomes a matter of opinion.

Review nodes without criteria. “Check quality” on its own means nothing. The model then checks against its idea of quality, not yours.

What to build it with

For your first graph, paper and a pen will do. Seriously — sketch your next process by hand before you go looking for a tool.

The moment you want to reuse the graph, share it with colleagues or hand it to an AI, you need something digital — and that’s where the difference from a whiteboard shows. A whiteboard exports a picture and wishes the reader luck. nodalo compiles a machine-readable specification instead: reading guide first, dependencies before dependents, a stable identifier on every node, edge and attachment.

In practice that means you can speak a node instead of typing it — the transcription knows the vocabulary on your board, and what comes back is a definition at instruction standard, without filler and without anything invented. Attached files land in the specification verbatim, not as “see attachment”. And the handoff happens as a compiled specification, as a ZIP bundle, or directly over the Model Context Protocol to Claude, ChatGPT, Copilot or Cursor.

Two things matter most for the walkthrough above. The roles — input, decision, review, outcome — are built in. And before the handoff, nodalo warns you about exactly the mistakes from the previous section: unlabelled branches, review nodes without criteria, nodes without a definition. The canvas itself is free to use; transcription and automatic definitions run on your own API key.

The takeaway

Prompt engineering isn’t wrong. It’s built for single tasks, not for processes.

As soon as something has multiple steps, branches, needs checking or has to be repeatable, you gain more by drawing it than by writing it out. And the best part: this shift also works for people who never got comfortable writing prompts. Almost anyone can break a process into steps — it’s the more natural way to think.

Pick a process that comes up regularly and annoys you regularly. Break it into the six steps above. You’ll find gaps while you’re still drawing that nobody had noticed before — with no AI involved at all.

Would you rather not think this through alone? In our AI workshops we take a real process from your company and break it down together, until it becomes something your team can still operate next week. Book a conversation or write to hello@einclick.com.

einclick® is an AI agency based in Zurich. We build AI solutions, run workshops and help companies structure their processes — tailored to Swiss businesses. More at www.einclick.ch.