A Manager With No Coding Experience Built an AI Negotiation Sparring Partner on Codex: What Worked in the Prompts

If you have tried building a role-playing AI conversation partner, you know the main problem: after two exchanges, it starts agreeing with everything. The team at the KORUS Consulting corporate university solved this problem for a negotiation trainer. What makes it more interesting is that it was built by Ksenia Kalabushkina, a learning manager who, by her own account, has never written a single line of code. Let's look at which techniques work there and which of them you can take into your own products.

Why the trainer was needed

The idea is simple. Negotiation skills are only reinforced through practice, but practicing on a real client is too risky: a poorly chosen phrase costs deadlines, scope of work and trust. Training with colleagues doesn't help either: people know each other, play along and don't present a tough, evasive or hurried opponent.

So you need an opponent who is available at any moment, holds the assigned role and delivers a debrief after the conversation. The user picks a case, a role, a duration, an evaluation methodology and a style: cooperation or competition. Then a ten-minute voice bout begins. The AI replies by voice, names a winner at the end and breaks down the strong moves, risks and turning points. Scoring uses five criteria: progress toward the goal, control of the conversation's flow, work with interests, argumentation and trade-offs, and quality of the agreements.

How the model was taught not to give in

This is the most useful part for developers. The authors used several techniques.

First: separate the roles. During the bout, the model plays only the opponent and does not give the user hints. When it ends, a separate request receives the full transcript and works as an evaluator with the instruction "evaluate only what the transcript supports." It is hard for one model to haggle and be an objective coach at the same time, so these are two different prompts.

Second: behavior changes over time. At the start, the opponent reveals context and resists a premature deal. Closer to the end, it proposes package solutions and tests commitments. After ten minutes, it helps lock in an agreement or honestly acknowledges that there is no deal. This keeps the model from closing the exercise after two polite exchanges.

Third: don't feed the methodology in whole. Vladimir Tarasov's book "The Art of Managerial Struggle" was split into meaningful fragments: working with interests, questions, conditions for concessions, recording agreements. Before answering, the service selects several fragments close to the current utterance and passes them to the model. In essence, this is ordinary RAG, and it lowers the risk of generic advice in place of a reaction to the specific words.

Fourth: test behavior, not the elegance of the prompt. The authors advise preparing a set of provocations: "let's just agree," "I agree to everything," "let's finish now." A good opponent does not break the role, does not reveal hidden interests and steers the conversation back to the terms.

Building without a programmer

The stack was deliberately kept simple: a web page, a small Node.js server, the OpenAI API for text and voice, Supabase for storage, GitHub for versioning and Vercel for publishing. The work was done through Codex. The order was this: first a one-page description of the user's path, then a split of the requirements into mandatory, convenient and future ones. The first step with an AI developer is to ask it to retell the task and ask questions rather than write code right away. Each stage is checked by running it: first a text bout without a database or voice, then everything else.

One point about the API key is worth remembering. It is stored in an environment variable on the server and does not end up in GitHub, screenshots or correspondence. If you use internal methodology materials, remove personal data, client names and commercial terms from them before sending them to an external model.

Limitations and takeaways

The story comes with caveats. This is the authors' own account, without independent measurements: how many people actually improved their skills is unknown. The winner is determined by the model itself, and such evaluations tend toward subjectivity. In addition, the whole service depends on a single external API. Part of the material in our source is cut off at the section on connecting the model, so deployment and vibe-coding tips are not covered here.

The practical takeaway goes beyond negotiation. If you are building any AI trainer or role-playing agent, separate the "player" from the "evaluator," mix in knowledge in portions and test the system on provocations rather than on successful dialogues. For a product manager, it is also an example of how a non-technical employee can test a hypothesis in a couple of evenings: scenario first, tools second.