How I Built Deepak: The 8-Phase Framework Behind the System

Dear Negotiation Explorer,

Welcome to issue 33 of our NegoAI series.

For the past few weeks, you've watched Sarah build an AI negotiation system, load it with her expertise, and use it to prepare for an $18.5 million deal. The Knowledge Base. The counterpart memory. The preparation prompt.

All of that came from somewhere.

This week, I'm stepping behind the curtain. Since I discovered Claude Code, I spent three months revamping my existing AI negotiation agents — including Deepak. Same negotiation expertise I've been encoding for years. Better methodology. I just published a research paper documenting the systematic process that produced it.

The paper introduces what I call the Collaborative Expertise Framework for Negotiation — an 8-phase process for building AI agents that deliver expert-level guidance. I want to walk you through it, because the principles apply whether you're building an agent or just trying to get better output from AI.

You can read the full paper here: https://dx.doi.org/10.2139/ssrn.6308259

Ask any general-purpose AI to help you prepare for a negotiation and you'll get something like: "Consider your BATNA. Think about the other party's interests. Look for creative solutions."

That's not wrong. It's just not useful.

It's the equivalent of asking a medical textbook for a diagnosis. The information exists, but the synthesis — applying multiple frameworks to your specific situation under pressure — is missing. That's what expert negotiators do. That's what generic AI doesn't.

The gap between "competent" and "expert" is enormous. Closing it took a methodology.

Building Deepak wasn't linear. It was iterative, frustrating, and full of surprises. But the process settled into eight phases that I now believe apply to building any serious AI agent for a knowledge domain.

Phase 1: Deep Research

Before building anything, I immersed the AI in negotiation theory. Not summaries — full engagement with foundational texts, competing frameworks, unresolved tensions. The goal wasn't for the AI to memorize definitions. It was for it to understand how expert negotiators think — when frameworks conflict, how they navigate ambiguity, what distinguishes adequate preparation from excellent preparation.

Phase 2: Discovery & Comprehension

Questions before answers. What does "good preparation" actually mean? When two negotiation frameworks contradict each other, which one wins? What does an experienced advisor produce that a textbook doesn't?

This phase forced me to articulate things I'd been doing intuitively for 25 years. That alone was worth the exercise.

Phase 3: Knowledge Base

This is where the expertise gets encoded — curated, structured, and organized for the AI to draw upon. Not an information dump. A synthesis of how expert negotiators think about their domain, organized by concept and application.

Here's the first architectural decision that changed everything: the Knowledge Base is separate from how the agent behaves. What it knows and how it operates are two different things. This means I can update the negotiation knowledge without breaking the agent's behavior. I can fix how it responds without touching the expertise. Modular. Debuggable. Portable across platforms.

If you built a Knowledge Base following issue 7, you've already done a version of this phase.

Phase 4: PRD (Product Requirements Document)

Before writing a single instruction for the agent, I defined what "expert-level" output looks like. What would a seasoned negotiation practitioner expect to receive? What sections, what depth, what quality?

This is the step most people skip — and it's the most important one for what comes next. The PRD is the compass for the System Instructions. Without it, you're building without a spec. You'll iterate endlessly because you don't know what "done" looks like. With it, every instruction has a purpose, and every output can be measured against a standard.

Phase 5: System Instructions

This is where you define how the agent behaves — its identity, its process, its output structure, its constraints. The System Instructions draw on the Knowledge Base (what it knows) and are shaped by the PRD (what it needs to produce).

I'll come back to this phase in a moment, because it's where the biggest surprises happened.

Phase 6: Self-Evaluation

Before testing against external cases, the agent evaluates itself against the PRD. Where does it fall short? What can't it do well? What's it uncertain about?

This step is cheap and fast. It catches the obvious gaps while context is fresh — before you invest time in formal testing.

Phase 7: Synthetic Validation

Test against designed scenarios — cases you create specifically to exercise the agent's capabilities. Does it handle multi-issue negotiations? Can it identify creative options? Does the output match the PRD?

Important: this validates that you built what you designed. It does not validate that what you designed actually works in the real world. That's phase 8.

Phase 8: Real World Iteration

Test against real negotiation cases. Not scenarios you designed — cases with the full complexity and ambiguity of actual situations.

This is where the framework lives or dies. My controlled tests (Phase 7) gave Deepak a 93 out of 100. I thought I was done.

I wasn't.

Real cases revealed gaps I hadn't thought to test for. One case involved a property transaction where a timing constraint could have been reframed as a negotiation variable — the kind of creative insight that distinguishes expert preparation from competent preparation. Deepak missed it completely. My tests hadn't probed for it because I hadn't thought to ask.

The diagram shows a feedback loop between Phase 8 and Phase 5. That loop is the heart of the process. Real-world testing sends you back to refine the System Instructions. Then you test again. Then you refine again. It took eight iterations before Deepak consistently met the expert bar.

Phases 6, 7, and 8 form a validation chain. Each catches what the previous one can't:

Skip any of them and you'll ship an agent that looks good in demos but fails when it matters.

Building Deepak taught me three lessons that contradicted my assumptions. They apply to anyone using AI for serious work — not just agent builders.

1. More instructions made the AI worse.

When Deepak's output had gaps, my instinct was to add more instructions. Be more specific. Cover more edge cases. Describe the desired output in more detail.

Three rounds of this. Each time, the instructions grew. Each time, the output quality stayed flat — or degraded.

I call this instruction saturation. Beyond a certain point, more instructions don't produce better compliance. They produce confusion. The AI has to navigate an increasingly complex set of directives that interact in ways you didn't intend. The solution to inconsistent output is not more elaborate descriptions of what you want.

If you've ever written a long, detailed prompt and gotten worse results than a shorter one — this is why.

2. Templates beat long explanations. Every time.

The fix for instruction saturation wasn't better prose. It was structure.

Instead of describing what the output should look like in paragraphs, I gave the agent templates. Required sections. Checklists. Structural mechanisms that made non-compliance impossible.

The shift was immediate. Format compliance, output consistency, quality — all improved when I stopped describing what I wanted and started structuring it.

The principle: when you need consistent, high-quality output, impose structure rather than elaborate instructions. A template with required fields outperforms three paragraphs explaining what good output looks like.

3. The right question beats the right checklist.

Structure solved the consistency problem. But the output was consistently competent — not consistently excellent. The agent covered all the bases without surfacing the creative insights that distinguish expert preparation.

The fix was what I call catalytic questions — questions designed to force reframing rather than ensure coverage. Instead of "did you consider value creation options?" (a checklist item), the instruction became: "What assumption are we treating as fixed that might actually be variable?"

That single shift — from coverage questions to reframing questions — transformed the output. The agent started generating the kind of constraint-inversion insights that I'd been teaching for years but hadn't known how to encode.

Checklists ensure you don't miss anything. Catalytic questions ensure you see something new.

You don't need to build an agent to apply these lessons.

Instruction saturation: If your prompts are getting longer and your output isn't getting better, cut back. Focus on what matters most. Less can genuinely be more.

Structural enforcement: When you need consistent output, give the AI a template — not a description of what you want. "Fill in these seven sections" beats "provide a comprehensive analysis."

Catalytic questions: Add one reframing question to your prompts. "What assumption am I treating as fixed that might be variable?" or "What would I prepare differently if I learned my counterparty's priority ranking was the opposite of what I expect?" These questions produce insights that checklists never will.

The full paper is available here: https://dx.doi.org/10.2139/ssrn.6308259

Take a prompt you use regularly — for negotiation or anything else.

Step 1 (5 minutes): Is it suffering from instruction saturation? If it's longer than a page, try cutting it in half. Keep the structure, remove the elaboration.

Step 2 (5 minutes): Add structure. If you're describing what you want in prose, convert it to a template with required sections.

Step 3 (5 minutes): Add one catalytic question. Not "did you consider X?" but "what am I not seeing?"

Run both versions. Compare. The difference will tell you more than this article can.

The system you've been building — Knowledge Base, counterpart memory, preparation prompt — does one thing very well: it analyzes the deal.

But there's another dimension to every negotiation. The person sitting across the table. How they process information. How they handle conflict. What builds trust — and what breaks it.

Next week: a second agent running in parallel. Not analyzing the contract — analyzing the human. Behavioral profiling for negotiation.

Questions? Reply directly — I read every response.