AI agents don’t lack knowledge. They lack judgment.

The pilot that answers everything and decides nothing

This pattern shows up in a lot of first AI agent projects. A team gathers its product documents, connects them to a chat, and asks the questions colleagues ask every day. The answers are accurate. People try it for a week, then go back to asking the person down the hall.

Nothing in that answer is wrong. It is a well-summarized search result. The rep asked for a recommendation and got the catalog back, so the hard part of the job, deciding, is still theirs.

The usual response is more documentation: longer guides written for the agent to read, sometimes generated by another AI. That tends to produce bigger documents and the same kind of answers, because the missing piece was never in the documents to begin with.

What’s missing is judgment, and nobody wrote it down

Ask the colleague who always knows, and the answer sounds different: “Full Service. Cold storage is hard on batteries and hydraulics, and when a truck stops, the loading dock stops. Check how many shifts they run, though. On one shift with a spare truck, Plus is enough.”

That answer uses the same facts as the agent’s. What it adds is judgment: which question to ask first, which detail matters, which option wins, and when the usual answer doesn’t apply. What an expert knows sits in roughly three layers, and only the first is reliably on paper.

The philosopher Michael Polanyi put the problem in one line: “we can know more than we can tell.” Ask your best rep for their rules and you’ll get a short, tidy list. Watch them handle twenty requests and you’ll see the exceptions the list left out.

So the goal changes. You aren’t building a knowledge agent that finds facts. You’re modeling how your team decides: the consulting service your experts give everyone else, made available to every rep, at any hour, the same way each time.

Make every answer a decision you can check

A good recommendation has a shape. It is worth writing down, because it tells the agent what a complete answer looks like and tells you what to test. We use five parts:

1. The decision. Restate what is actually being decided. “Which contract to quote” is a different job from “what contracts exist.”
2. The inputs. Name what the answer depends on, and ask for what’s missing before answering. Asking about shifts is part of the answer, not a delay.
3. The governing source. When two sources disagree, say which one wins: this year’s price list over last year’s sales deck, the contract over the FAQ.
4. The evidence. Tie every fact to where it came from, so the person can check it instead of trusting it.
5. The recommendation. One choice, the reason, and what would change it. “Would change if” is what makes the answer safe to act on.

Sometimes the governing source isn’t a document at all. Whether the account already has a contract, what’s in stock, what this customer paid last time: those facts sit in a CRM or a partner portal, often with no API. Your rep would log in and look. An agent should be able to do the same, so the answer rests on today’s record rather than a guess.

The shape also covers the answers people forget to design for. “I can’t recommend one until I know where the trucks will run” is a good answer. So is “this needs a specialist,” when the request falls outside what the team has taught. A confident guess is worse than either.

Capture judgment from real cases, not rule lists

Decision researchers learned long ago that asking experts to list their rules doesn’t work well. The Critical Decision Method, developed by Gary Klein and colleagues, interviews experts about specific, non-routine incidents they actually handled, and probes for the cues they noticed and the options they rejected. The judgment comes out in the story of a real case.

You can run a lighter version in an afternoon:

• Collect 20 to 30 real requests. Take them from chat history, email or the team’s own memory, with the answer the expert gave and why. Include the ones where the right answer was “ask first” or “don’t.”
• Let the agent try them. Its wrong answers are the most useful material you’ll get: each one points to a rule the expert never thought to mention.
• Have the expert correct it in plain words. “Ask how many shifts before you recommend anything.” That sentence is a rule. Capture it where the agent will find it next time.
• Write the rule into a procedure. A procedure is the agent’s playbook for one kind of request: when it applies, the steps, and what to check. Fixing one step in plain text is easier than untangling logic buried in a flow chart or a long prompt.

New kinds of requests can teach the agent too. Let it work out the first one carefully, then write down what worked as a procedure, so the next request of that kind follows the playbook instead of starting from scratch. Your experts review it the way they’d review a new hire’s notes.

This changes the expert’s role. They aren’t writing prompts or documentation. They’re coaching, as they would a new hire: flag the wrong answer, say why, check the fix. Each correction moves a little more of their judgment out of their head and into something every rep can use.

Grade the decision, not the prose

A fluent answer can hide a bad decision, so test the decision itself. Turn the real requests you collected into test cases, and judge each answer against the five parts:

Agents don’t answer the same way every time, so run each case more than once. Anthropic’s guide to agent evals recommends several trials per task for that reason; we run each case three times. A case that passes once in three isn’t ready for a rep to rely on.

Then read the traces, not just the scores. An answer can be right by luck, with the agent guessing the recommendation without opening the price list. Check that each answer is grounded in what the agent actually found. Hamel Husain’s advice on evals puts looking at real data at the center of improving an AI product, and it applies here too.

Finally, re-run the whole set after every correction. A new rule for cold storage shouldn’t break the answer for a single-shift retailer. The set becomes your regression test: a record of what your team decided, checked against what the agent does today.

Train an agent on your team’s judgment with Eager

Eager is where you train AI agents like new hires. Hand an agent your files as they are (spreadsheets, PDFs, slide decks, whole folders) and it reads them directly. Then switch to Coach and talk to it as its manager, in writing or by voice: what to ask first, what to recommend, when to say no. It changes its own draft and shows each change in place to keep or undo.

Rules go into procedures, plain-text playbooks the agent finds when a request fits. When a browser or computer task works without one, Eager writes the procedure for next time, and you can fix any step by hand. The same browser and computer tasks let the agent check the live answer in portals that have no API.

Evals test it on your team’s real requests. Write what a good answer does in plain language (“Asks how many shifts before recommending”), run each case several times, and a judge checks that the answer is right and grounded in what the agent found. Every attempt keeps its conversation and the replay of any task it ran. After Coach changes the agent, it can run the evals on the draft and tell you how it did against the last run.

Start with one decision your team makes every day, twenty real cases, and an hour of your best expert’s time. That is enough to find out whether the agent can recommend, not just look things up.