How to Brief an Agent So It Gets It Right the First Time

In short

Most "the agent did the wrong thing" moments aren't about the agent — they're about the brief. The model doesn't read minds: it fills the gaps with guesses, and guesses rarely match what you had in your head.

A good brief rests on four pillars:

1. Intent — what, and more importantly why. "A feedback form so people can report bugs" beats a bare "a form".
2. Scope — what's NOT included. "Email delivery only, no database and no admin panel" cuts out work you never wanted.
3. Definition of done — how you'll know it's finished. "Submit → email arrives → I see a thank-you message."
4. Context — where this lives. "It's a React project, the form goes on the /contact page."

The good news: the Quest engine is designed to fill in the missing pieces for you — but the better the input, the fewer rounds of clarification you'll sit through.

Why this matters

Every unsaid thing is a fork in the road where the agent decides for you. Without a definition of done, it stops wherever it thinks is good enough. Without scope, it builds extra things (and possibly breaks something on the way). Without a "why", it solves the wrong problem in a technically flawless way.

The Quest engine has built-in protection against this — the elicitation layer: it turns "I want a CRM" into a solid spec through short fork-in-the-road questions, each with a default recommendation ("here's what people usually do"). But the number of those questions is capped (the engine respects your time), so anything you say up front saves those questions for the forks that actually matter.

Bad → good (a template)

Bad: "Build me a login."

Good: "Add email + password sign-in to my React+Express project. Sign-in and sign-up only, no password recovery and no OAuth (those come later). Done = I can register, log out, log back in, and the protected /dashboard page is unreachable without signing in."

The second version sets intent, scope, definition of done and context — leaving the agent almost nothing to invent.

How it works in the engine: input → what the engine does → result

Input (deliberately incomplete, the way it happens in real life):

"I want a CRM for my repair shop."

What the engine does (the intake layer plus the product owner and analyst roles):

1. It doesn't write code right away. First it asks a batch of fork questions, each with a recommendation:
   • "Who keeps the records — just you or a team? (I'd recommend adding an 'owner' field, it barely adds complexity)"
   • "What's the main entity — customer, order, or both? (I'd recommend customer → orders, that's the most common shape)"
   • "Do you need order reminders? (I'd recommend pushing this to the backlog for v1)"
2. It turns your answers into an EARS spec — precise requirements with a happy path, edge cases and errors: WHEN a customer is added without a phone number, THE SYSTEM SHALL save them and flag the contact as incomplete.
3. It states the scope out loud — what made it into v1 and what went to the backlog — so you can agree before a single line is written.
4. Only then does it plan and build, checking every step against the definition of done.

Result:

Instead of "a CRM, generally speaking", you get an agreed spec with clear boundaries, and the team of roles predictably builds what you actually meant. One round of clarification instead of five rounds of rework.

A quick checklist before you send the task

• Did you say why, not just what?
• Did you mark what should not be done (scope)?
• Did you describe what done looks like?
• Did you give context (stack, where it lives, what it resembles)?
• Did you leave the engine room to ask at a real fork instead of guessing?

Straight talk

• Elicitation with recommended answers and the EARS spec are already part of the base engine's design, and they ship in the package as a text recipe.
• AI assembly "describe your goal → a ready engine" (from-goal) is about building the engine itself around your goal, and it's on the roadmap, still in development — don't confuse it with briefing a task inside an engine you've already installed (that part works).
• The engine is an instruction set, not a guarantee. A good brief sharply raises the odds of "got it the first time", but the final quality still depends on the target model too; the engine minimizes that dependency through the literalness of the recipe, without eliminating it entirely.