# One goal sentence against a 40-line flowchart From https://brinvik.com. A test you can re-run on your own inbound. Free to use and change, no warranty. ## What was tested Two inbound agents read the same 20 inbound form records for Vognlog, a fictional Danish company that sells job planning to service firms. Both got the same knowledge base (`knowledge.md`) and the same answer format (`harness.md`). Only the instructions differed: - `prompt-goal.md`: one sentence. - `prompt-flowchart.md`: a 40-step qualification flowchart of the kind many inbound playbooks use. Each agent decided, per buyer, which plan to recommend and the next step (buy on their own, sales call, account owner, support, or answer only). Every buyer ran as its own Claude sub-agent, twice per agent: 80 sub-agents in all. A third column, `literal.py`, runs the same flowchart as plain rules with no model behind it. The idea comes from Anthropic's post of 30 September 2026, "How Anthropic's sales team rebuilt inbound with Claude Managed Agents", which says a goal worked better for them than "listing out every qualification requirement in a flowchart". This test changes the company, the buyers and the scoring. ## What came out (facts.json) | | Run 1 | Run 2 | |---|---|---| | Claude, one goal sentence: buyers with plan and next step right | 20 of 20 | 20 of 20 | | Claude, 40-line flowchart: buyers with plan and next step right | 20 of 20 | 20 of 20 | | The same flowchart as rules, no model (`literal.py`) | 17 of 20 | same, it is deterministic | - The two Claude agents tied at the ceiling. The test cannot separate them, and it does not show that a goal beats a flowchart. - Each agent made the same plan and next-step decision on all 20 buyers in both runs. The reply text differed between runs. - The arms differed on one buyer only: buyer 9 (the non-profit). The goal agent sent them to buy on their own, the flowchart agent to support for the discount, in both runs. The key accepts both, and said so before either ran. - The rules got 3 buyers wrong (b01, b12, b18). Each one is a small buyer sent to a sales call for a plan that starts at 25 users. Claude, holding the same flowchart, decided differently from the rules on exactly those 3 buyers in both runs. On buyers 1 and 18 that meant not following lines 21 and 19, where the flowchart contradicts the knowledge base; Claude went with the knowledge base. - The goal agent wrote longer replies: 115.1 and 117.7 words on average, against 66.0 and 67.2 for the flowchart agent. Partly because step 37 caps a reply at 90 words and the goal sentence says nothing about length. ## Proof of order `answer_key.json` was committed in 8a4419a4f128b8b4b9dfd0164392edabe5f1f7ba at 2026-10-04 19:57:56 UTC, under `brinvik/lab/goal-prompt-vs-flowchart/` in the Brinvik repository, together with the buyers, the knowledge base, the harness and both prompts. The first recorded answer was written at 20:01 UTC. The key has not changed since: SHA-256 147ce09b5565d222a2b3f60f255c35f82fd8f2e0ecaee44b21a78bd0912087d6. Check it with `sha256sum answer_key.json`. The repository is private, so the commit itself is not public. The buyers were renamed on 2026-10-11. The first version used company names that turned out to belong to real firms, so every company got a coined name (and two people whose surname matched one got another), in commit 9943d03 at 19:54:44 UTC. Nothing else in a record changed, and the key, the prompts, the knowledge base and the harness did not change at all. All 80 agent runs were then recorded again on the renamed buyers; the files in `runs/` are those. The scores came out the same as the first time: 20, 20 and 17. ## How the runs were made, exactly Each sub-agent got one instruction: read one rendered file (`make_prompts.py` output for that buyer and that agent), use no other file, no search and no web, and write the JSON answer to one path. Each one reported three tool calls (read, write, hand back), except one flowchart sub-agent in run 1 that reported four. Sub-agents run inside a Claude Code session with its own system prompt, so this is not the same as an API call with `harness.md` as the system prompt. The model was configured as claude-opus-5-5 on 4 October 2026; the serving model per call was not recorded. ## Run it on your own inbound 1. Replace `knowledge.md` with what your agent should know: plans, prices, who handles what. 2. Replace `inbound.json` with 20 or more real inbound records, with personal data removed. Keep the CRM context a real agent would see. 3. Write `answer_key.json` BEFORE you run anything, and commit it, so nobody can say the key was fitted to the answers. 4. `python3 make_prompts.py out/in` renders the exact text each session gets. 5. Run each file in its own fresh Claude session (a new chat, a sub-agent, or an API call with your own key and no tools) and save the JSON answer to `runs/run1//.json`. Run it twice. 6. `python3 score.py` scores every run against the key and writes `facts.json`. 7. Optional: change `literal.py` to your own flowchart to see what it does with no model behind it. ## What it will not tell you - **The knowledge base already answers every trap.** It says who counts as a user, that Google sign-in is not SAML SSO, that Business starts at 25 users. So this compares two ways of instructing on top of a good knowledge base, not a goal against a playbook. The likely lesson is that the knowledge base did the work and the instructions mattered little, while rules with no model behind them did not. - **The same author wrote the flowchart and the traps.** Three of the flowchart's lines (16, 19, 21) are the lines the traps hit. A careful ops team might not ship them. Sending everyone who asks for the top plan to a sales call (line 21) is also a defensible sales practice; here it is scored wrong because the knowledge base sells that plan from 25 users only. - **`literal.py` is one literal reading.** It is handed the three judgement steps (who the sender is, whether something is broken) for free. It reads "users" as the first number in the message, so on buyer 12 it takes the 30 employees, not the 3 planners. With a stricter reading buyer 12 still goes wrong, but as Team bought on their own (line 23 fires on "sms"), not as a sales call. - **It scores two decisions, not the reply.** The third check, oversell, follows from the plan, so it is not an independent test. Replies were read but not scored. What a reader of `runs/` will find: four flowchart replies carry a placeholder such as `[trial link]` or `[link til prøveperiode]`, because step 30 says to send the trial link and the knowledge base has none; on buyer 4 every reply says SCIM works with Entra ID, which the knowledge base does not say; a few replies add small claims it does not hold ("uden binding", "We're not looking for SEO or traffic services at the moment"). Every price and every sum in every reply is correct. - **Claude wrote the buyers, the key, the flowchart and the knowledge base, and Claude was scored.** Twenty invented, single-turn, tidy records. Two runs. Real inbound is messier. ## Files `knowledge.md`, `harness.md`, `prompt-goal.md`, `prompt-flowchart.md`, `inbound.json`, `answer_key.json`, `make_prompts.py`, `literal.py`, `score.py`, `facts.json`, and `runs/` with every recorded answer verbatim.