No-Code Automation Agent

Before writing any code you make a clean, isolated workspace. This block creates the project folder and a virtual environment (a private copy of Python for just this project) so the pytest tool you install here can't clash with anything else on your computer.

1. mkdir -p nocode-agent/tests makes the project folder and a tests sub-folder in one go. cd nocode-agent steps into it, so every later command runs in the right place.
2. python3 -m venv .venv builds the virtual environment in a hidden .venv folder. source .venv/bin/activate switches it on — the comment shows the different command Windows users type instead.
3. pip install pytest installs the test runner into that environment. pip freeze > requirements.txt writes down exactly what's installed so anyone can recreate your setup.

What the output means: The last line, Successfully installed pytest-8.3.4, confirms the test tool is ready. The (.venv) at the start of your prompt means the environment is active.

Try this: If a later command says command not found or a test can't find pytest, you probably forgot the source .venv/bin/activate line — run it again in that terminal.

This tiny file is the most important safety part of the whole project: it takes the LLM's decision and returns exactly one word — AUTO, HUMAN, or DROP. We write it in plain Python (not on the canvas) for one reason: a visual IF node can't be tested, but this function can. When the tests pass, you trust the matching canvas branch.

1. AUTO_THRESHOLD = 0.8 is the cut-off: the model must be at least 80% confident before anything happens automatically. Naming it once at the top means you change the rule in one place.
2. def route(decision): takes one dictionary holding three fields the LLM produced — intent (sales/support/spam), risk (low/high), and confidence (0.0–1.0).
3. The if checks run in order, top to bottom, and the first match wins. Risk is checked first: any "high" risk lead returns "HUMAN" immediately, no matter how confident the model is. Then spam is dropped, then confident non-spam auto-acts.
4. The final return "HUMAN" is the safe default: if none of the earlier rules matched (e.g. low confidence), the item goes to a person rather than being guessed at.
5. The if __name__ == "__main__": block at the bottom runs four sample leads through route() so you can see the decisions when you run the file directly.

What the output means: Running the file prints each example dict followed by -> and its decision — you should see AUTO, HUMAN, HUMAN, DROP for the four samples in order.

Try this: Change the high-risk example's confidence to 0.99 and re-run — it still returns HUMAN. That's the whole point: risk beats confidence.

These are the unit tests that lock in the safety rules. Each test feeds one hand-picked decision into route() and asserts the answer. They run with no API key and no platform — pure, fast, repeatable proof that the risky cases always reach a human.

1. from route import route pulls in the function you wrote in Step 2 so the tests can call it.
2. Each def test_...() is one scenario. assert route(...) == "HUMAN" means "if this isn't true, fail loudly" — that's how a test catches a mistake.
3. The tests deliberately cover the corners: high-risk-but-confident still goes to HUMAN, confident low-risk goes to AUTO, low confidence escalates, spam is DROPped.
4. test_high_risk_beats_spam_check is the subtle one: a message that's both spam and high-risk must go to HUMAN, proving the checks run in the right order.

What the output means: On the next block, pytest prints one PASSED line per test and 5 passed. Any FAILED line would name the exact rule you broke.

Try this: Temporarily swap the first two if lines in route.py (check confidence before risk) and re-run the tests — test_high_risk_always_goes_to_human will fail, showing you the test is really guarding the order.

This is the plan for building the exact same logic on the visual canvas. Each numbered line is one node you drag in; together they are the picture from the Architecture section, made concrete for n8n (Make and Zapier are nearly identical).

1. Node 1 [Webhook] is the trigger — it gives you a URL that fires the workflow whenever a new lead is POSTed to it.
2. Node 2 [Set] is the prep step: {{ $json.text }} is the platform's way of saying "grab the text field from the incoming data" so the LLM node gets just the message.
3. Node 3 [AI / LLM node] uses the system prompt from Step 5 and returns JSON — the same three fields (intent, risk, confidence) your Python code expects.
4. Node 4 [IF] is the branch. Its condition — low risk AND confidence ≥ 0.8 AND not spam — is route() rewritten in the platform's UI. TRUE flows to the auto node, FALSE to the human node.
5. Nodes 5a and 5b are the two endings: create the lead in the CRM automatically, or ping a human in Slack/email to review.

Try this: Notice node 4's condition packs all three of your Python rules into one combined AND. That's why anything high-risk, low-confidence, or spam takes the FALSE path — exactly like the function.

This is the text you paste into the LLM node so it behaves predictably. It's a prompt, not code — plain instructions telling the model precisely what to return. The magic word is JSON: the model must answer in a strict, machine-readable shape so the IF node can branch on clean fields.

1. The first line sets the job ("Classify the incoming lead message") and demands ONLY valid JSON, nothing else — no chit-chat, because extra prose would break the next node.
2. The JSON template shows the exact three keys and their allowed values — the same intent / risk / confidence your route() function reads.
3. The Rules section defines the fuzzy words for the model: what counts as high risk (refunds, legal, complaints) and what confidence means. Spelling these out makes results consistent.

What the output means: The sample shows two real messages turned into JSON, then the IF result: a clean sales lead scores high and flows to AUTO; a refund complaint is flagged high risk and goes to HUMAN — your safety rule working end to end.

Try this: Ask for a field the rules don't define (say "urgency") and you'll get inconsistent answers — models are only reliable about things your prompt actually pins down.