ReAct (Reason + Act) interleaves thinking and tool calls one step at a time: the model reasons about what to do next, calls a tool, observes the result, and reasons again. There’s no fixed plan — the next step is decided fresh each time, informed by what just happened.
Good for: tasks where the right next step genuinely depends on what you just learned — debugging, research, exploring an unfamiliar API, anything where step 3 can’t be known until you see the result of step 1.
Weak spot: it has no persistent plan, so on long tasks it can lose the thread, repeat work, or wander off course without anyone noticing until the end.
This pattern splits planning from execution: the model first produces an explicit multi-step plan, then a (possibly separate, cheaper) executor works through the steps, only going back to re-plan if something breaks the plan.
Good for: tasks with a knowable shape up front — “migrate these 12 files,” “run this checklist,” “generate this report” — where the value of a stable plan outweighs the cost of occasionally being wrong about step 4 before you get there.
Weak spot: if the environment is more dynamic than expected, the agent either stubbornly follows a stale plan or has to re-plan so often that you’re paying the planning cost repeatedly anyway.
A rough heuristic: if you could write the steps yourself before starting, use plan-and-execute. If you’d genuinely need to see step 1’s result before knowing what step 2 is, use ReAct. Most production agents end up as a hybrid — a loose plan for structure, with ReAct-style reasoning inside each step.
The mistake to avoid is picking a pattern because a framework defaults to it, then fighting the framework when your task doesn’t fit. Name the pattern you’re using on purpose, and it gets a lot easier to reason about why an agent is misbehaving.
“State of the art on coding” can mean anything from “solves competitive programming puzzles” to “correctly edits a real codebase across multiple files.” These are barely related skills. Before a benchmark result matters to you, check what the tasks in that benchmark actually look like — most benchmark papers publish sample tasks, and reading three of them tells you more than the headline number.
A model provider reporting its own model’s score on its own chosen benchmarks, using its own prompting setup, is not the same evidence as a third party running a standard eval with a fixed harness. Neither is worthless, but they deserve different amounts of trust. Independent leaderboards that publish their methodology are worth more than a bar chart in a blog post.
Watch for mismatched conditions: comparing a model with tool use enabled against one without, comparing different prompting strategies, or comparing against an old version of a competitor that’s since been updated. These aren’t always deliberate, but they’re common enough to check for.
A model can be genuinely better at math olympiad problems and no better — or worse — at the specific thing you need, like following your codebase’s conventions or handling your particular data format. General benchmarks are a filter for “worth trying,” not a substitute for testing on your own task.
Before switching models based on a release post: read one or two real example tasks from the cited benchmark, find one independent evaluation if you can, and — this is the part people skip — run your own small eval on the task you actually care about. It takes an hour and it’s worth more than any chart in the announcement.
Models are much better at hitting a target you’ve described than at guessing one. Instead of “summarize this,” say “summarize this in 3 bullet points, each under 20 words, focused on decisions made rather than discussion.” The output format is part of the task, not an afterthought.
If a colleague would need to know a constraint to do the task right — a deadline, an audience, a length limit, a thing to avoid — the model needs it too. “Don’t use marketing language” is a more useful instruction than “make it good.”
If you want a specific output shape (a particular JSON structure, a specific tone), one example is often worth several sentences of description. This is few-shot prompting, and it’s the single highest-leverage technique for format-sensitive tasks.
Use headers, delimiters, or XML-ish tags to mark where your instructions end and the content to work on begins:
1Summarize the text between the tags below.2
3<text>4{{content}}5</text>This prevents the model from confusing instructions in the content with instructions from you — especially important once your prompts get long or the content is user-supplied.
“List the 3 most important risks” beats “tell me about risks” — models default to the safe, generic answer unless you ask for the specific, opinionated one. If you want judgment, ask for judgment explicitly.
Politeness (“please”, “thank you”) has negligible effect on output quality. Elaborate role-play personas (“You are a world-renowned expert with 30 years of experience…”) help less than a clear task description with real constraints. Spend your effort on structure, not framing.
Every prompt in the Prompts library on this site follows these five habits — worth a look for concrete examples of the structure in practice.
A webhook receives form submissions. The workflow:
Add a Webhook node. Set the HTTP method to POST and give it a memorable path (e.g. /form-submit). n8n gives you a test URL immediately — use it to send a sample payload with curl before building anything else, so you know exactly what shape of data you’re working with.
1curl -X POST https://your-n8n-instance/webhook-test/form-submit \2 -H "Content-Type: application/json" \3 -d '{"email": "user@example.com", "message": "hello", "honeypot": ""}'Add an IF node right after the webhook. Condition: {{$json.email}} is not empty. Route the “false” branch to a NoOp node (or a Respond-to-Webhook node returning a 400) so incomplete submissions stop here instead of propagating.
Add a second IF node checking your honeypot field: {{$json.honeypot}} is empty. Bots that fill in every field get routed to a dead end; real users, who never see the honeypot field, pass through.
Add a Set node to shape the output into exactly what your downstream system expects — don’t forward the raw payload. This is also the right place to strip anything you don’t want to store or transmit further, like the honeypot field itself.
Add an HTTP Request node (or the Slack node if you’re using Slack) as the final step, pointing at your destination.
This IF → IF → Set → HTTP Request shape — validate, filter, transform, deliver — covers the large majority of “someone submits something, we need to act on it” automations. Once you’ve built this once, you can swap the trigger (form, email, database row) and destination (Slack, email, another API) and reuse the same skeleton.
Next in this series: adding retries and error notifications so a failed delivery doesn’t silently disappear.