The Plan-First Research Prompt

# The hedge fund's AI is not allowed to start working

Bridgewater built itself an AI research analyst. The first thing it does is refuse to do
anything.

The tool is called PAT — the Pocket Analyst Tool. Bridgewater's applied-AI team described
it in a talk published by LangChain on 2026-07-24, and Bridgewater has its own page for it.
It is not a prototype: it has been deployed inside the firm for months, and hundreds of
their own analysts open it every day. It performs research. It is explicitly not a trading
tool, and it is a separate thing from the firm's AIA Macro Fund. Worth keeping those
apart, because "AI does the research" and "AI runs a multi-billion-dollar fund" are very
different sentences and only one of them is about this.

The rule worth stealing is the strange one. Once PAT has gathered its context, it does not
answer. It produces a structured plan — what it intends to check, and how it intends to
check it — and that plan is the thing a person approves before any work happens. The team's
own phrase for it is that the plan is the analysis.

Copied down to a single chat box, the habit is: before you ask any AI for real work, make
it restate your question, name what it will check, say how it will decide what counts as
right, list what it is assuming about your situation — and then stop.

Most people who try this get nothing out of it, and it is almost always the last clause
they left off. A model asked for "a plan and then the answer" will write a plan and then
immediately answer, which gives you no decision point at all. You still have to read the
whole 900 words to discover it checked the wrong year.

Stopping is what converts a long output you have to audit into a short one you have to
approve. That is the entire mechanism, and it is why the instruction in the kit is blunt
about it: *do not start the research, do not give me a preliminary answer, wait.*

The arithmetic is unglamorous and it is the reason to bother. You approve a plan in ten
seconds. You untangle a wrong answer for an hour. Those are the two ways your next hour can
go, and the only thing that decides which one you get is whether you looked before the work
started or after.

There is a second benefit that shows up immediately and that nobody expects: the plan
surfaces the assumption you did not know you had made. Ask an AI whether you should move
your team off some tool, and a good plan comes back saying *I am assuming you have not
already tried reorganising it; if that is wrong, it changes the answer most.* That
question was worth more than the research would have been.

The part of PAT that is genuinely hard to imitate is what happens when it gets something
wrong.

Nobody corrects it and moves on. The mistake is turned into a benchmark the system is
expected to fail. The harness is then iterated until that benchmark passes without breaking
the rest of the suite — and then a human is sent a pull request and signs the fix off. The
correction stops being a note in one conversation and becomes a permanent test.

It does not repeat mistakes. It collects them.

You cannot rebuild that with custom instructions, and I am not going to pretend otherwise.
There is no benchmark suite in your chatbot and nothing blocks a bad answer. What does
transfer is the *shape*: write each mistake down as a rule with a trigger, a behaviour and
a one-line reason, put it where your tool keeps persistent instructions, and keep the list
short enough that you actually re-read it.

The reason "remember not to do that" fails is that it records a feeling about one output. A
rule that sticks records a situation and a behaviour, written so that a stranger could
apply it without having seen the conversation that produced it.

Two things worth saying before you go and try it.

The plan step costs you a round trip, so it is a waste of time on short lookups, rewrites,
formatting, or anything where a wrong answer would be obvious the moment you read it. It
only pays when the work is long enough that auditing the output would cost more than
approving the plan. Rough line: if you would not read the answer carefully, skip the plan.

And some models will write the plan and then keep going anyway, especially on questions
they judge to be easy. That is the single most common way this fails on the first try. One
correction fixes it: tell it that it did not stop, and to write only the plan and wait.
That generally holds for the rest of the conversation.

The team stated some striking figures on camera: a jump in search accuracy after adding a
sanity-checking layer, and a high rate of identical code across independent runs. Those are
their numbers, and no genuinely independent party has re-measured any of them; every
write-up that repeats them traces back to the same talk. So they are not in the video and
they are not quoted here as fact. The habit does not need them.

What is well supported is the plain part: Bridgewater is real, PAT is real, it has run
internally for months, hundreds of their own analysts use it daily, and it plans before it works.
That is enough.

Comment ANALYST on the video, or grab it at sharpendaily.co/kit/analyst.

Three files, no install, nothing to sign up for:

- The plan-first prompt, copy-paste ready, plus the line for deciding when it is worth
the round trip and when to skip it.
- A worked example, start to finish, including the failure mode to expect and the exact
wording that fixes it.
- Teach it a mistake: the rule format, three worked rules, and how to keep the list
from rotting.

Every word of it is our own writing. Nothing there is Bridgewater's code, prompt or system,
and none of it is affiliated with them. The idea is theirs; the wording is ours, so use it
however you like.

---

Sources. The talk: <https://www.youtube.com/watch?v=lXZb21CfeIY> (LangChain, published
2026-07-24, recorded at Interrupt 2026). Bridgewater's own write-up:
<https://www.bridgewater.com/aia-labs/how-bridgewaters-aia-labs-built-pat-the-ai-pocket-analyst-tool>.