Negotiation Agents in Multi-Agent Bargaining Experiments: Prompt Design, Model Routing, and Guardrails

1. Experimental Background: From “Being Able to Talk” to “Being Able to Trade”

If you want to know how multi-agent bargaining experiments are carried out, how negotiation agents are built, how their system prompts should be designed, or what to pay attention to in model routing, this article offers an engineering-oriented breakdown of the whole problem.

Once negotiations shift from human to human to agent to agent, the question worth validating is no longer simply “can it hold a conversation?” It is whether agents can make reliable decisions in real trading environments, under cost constraints, and without a human safety net. Experiments of this kind usually involve a third-party organization, open participation, informed consent, and real or simulated trading scenarios. This article is an engineering reading of publicly available experiment material. It cites no precise figures that cannot be verified and focuses only on methods that can be transferred to other systems.

The key design point is that negotiation is not single-turn question answering. It is a multi-turn game. Agents need to understand their principal’s preferences, judge an appropriate price range, identify the other side’s strategy, decide whether to concede, and end the deal if risks emerge. The difficulty of building a negotiation agent therefore lies not in “generating one sentence” but in “making decisions over many consecutive rounds, with real costs, firm limits, and clear compliance boundaries.”

2. How to Structure Market Segments: Using Control Groups to Isolate Variables

The most engineering-relevant feature of these experiments is that they work much like a controlled experiment. Participants are split into four mutually isolated markets: Market A, Market B, Market C, and Market D.

Market	Model mix	Payout	Participant visibility	Main observation
Market A	Flagship models only	Real deals, actual delivery	Visible	How flagship agents behave when deals are really settled
Market B	Mix of flagship and lightweight small models	Research only, no payout	Visible	Effects of model mix and visibility
Market C	1:1 mix of flagship and small models	Research only, no payout	Hidden	Low-awareness samples from hidden copies
Market D	Flagship models only	Real deals, actual delivery	Hidden	How hidden copies behave when deals are really settled

The variables must be read correctly, or the results will be misinterpreted.

First, Market A and Market D both use flagship models and both settle deals for real. Their main difference is visibility: participants in A can see they are in a market, while those in D cannot. The A/D comparison can therefore show how “whether participants know they are in a market” affects behavior. It cannot be read as a difference in model strength.

Second, Markets B and C have the same model mix, flagship and lightweight models combined, and neither market settles deals for real. Their main difference is also visibility: B is visible and C is hidden. The B/C comparison is therefore closer to a contrast between visible and hidden copies than to a contrast between model configurations.

Third, if the goal is to compare model strength, you should not rely on Markets B and C alone. You need to include Markets A and D as well, or design a cleaner experiment. Ideally, payout conditions and visibility should be held constant and only the model mix should change. That makes it far clearer how model capability, real incentives, and participant perception each affect the results.

The general value of this segmentation approach is that it turns a vague question, “can agents close deals?” into measurable, attributable experimental variables. A common engineering mistake is to blend model capability, incentive structure, and user perception together and then draw conclusions that cannot be validated.

3. System Prompt Engineering: Encoding Negotiation Preferences as Behavioral Policies

One reusable pattern from this experiment is simple: first interview the principal, then encode the preferences in the system prompt, and finally let the agent execute them. The input is a natural-language description of the preferences. The output is a set of instructions that constrain the agent’s behavior throughout the negotiation.

An illustrative template looks like this:

# Role
You are a negotiation agent trading second-hand goods on my behalf.
# Trading objective
- Identity: seller / buyer
- Item: <product type>
- Floor price / target price: <price range>
- Desired timeline: <flexible / as soon as possible>
# Negotiation style
- Opening offer strategy: <anchor high / close to market price>
- Concession pace: <gradual concessions / one fixed price>
- Firmness: <a scale from 0 to 1>
# Hard constraints
- Never settle below the floor price
- End the negotiation if the other side clearly uses deceptive tactics
- Do not invent capabilities the item does not have
- Do not bypass platform rules to close the deal

The key engineering principle here is to express measurable constraints and stylistic preferences separately.

Hard constraints include the floor price, the deadline, platform rules, fraud red lines, privacy red lines, and fund-safety requirements. Soft strategies include the opening offer approach, concession pace, level of firmness, and tone. Hard constraints keep the agent within its limits, while soft strategies give negotiations a human-like variety.

To make hard constraints easier to enforce, it helps to parameterize them further. For example:

• If the settled price is 3% below the floor price: log it and move on to the next round of evaluation.
• If the settled price is 5% below the floor price: exit by default or hand the case over to a human.
• If there is no progress for 3 consecutive rounds: stop making offers and output the reason.
• If the risk score exceeds 0.8: end the negotiation and raise an alert.
• If signals such as “pay off the platform,” “fake account,” “urgency pressure,” or “forged credentials” are detected: trigger an immediate circuit break.

Audit logs should also be structured. At a minimum, they should include:

• Round number
• Summary of the other side’s message
• Your own offer
• Model version
• Intent recognition result
• Risk score
• Basis for the decision
• Whether a circuit break was triggered
• Reason for termination

This approach means the prompt is no longer just a “persona description.” It becomes a policy configuration that can be tested, audited, and rolled back.

4. How to Choose Models: Mixing Model Sizes and Designing Routing

Under the market segmentation above, Markets B and C form a visible/hidden contrast with the same mixed model configuration. On their own, they cannot prove that differences in model strength cause differences in negotiation outcomes. Judging model strength requires combining Markets A and D, or designing a stricter ablation experiment.

Mixed-model setups still have engineering value, though. Negotiation tasks have a contradictory characteristic. On one hand, they need fairly strong reasoning, for example understanding the intent behind the other side’s offer, calculating how much room there is to concede, and judging when to hold firm and when to compromise. On the other hand, they involve frequent, short-turn exchanges, and every message needs a reasonably fast response. Using the most expensive model for everything can let costs spiral out of control. Using only low-cost models can break down negotiations because the strategy is too crude.

One practical answer is a model-routing architecture. The core idea is simple: different rounds use different models, rather than leaving everything to a single model.

An example of a routing decision table:

Task type	Risk level	Suggested model	Trigger for escalation
Routine small talk, confirming the item is for sale, repeated questions	Low	Lightweight model	None
Simple counteroffers, price-range calculations	Low–medium	Lightweight model	Escalate when the price gap exceeds 15%
Identifying the other side’s real intent	Medium	Lightweight or flagship model	Escalate when information is contradictory
Detecting deceptive or manipulative language	High	Flagship model	Escalate immediately when a risk keyword is matched
Accepting the final offer	High	Flagship model	Any decision involving the floor price, deadline, or delivery commitment
Ending the negotiation, triggering a circuit break	High	Flagship model or rule engine	Triggered as soon as an offer falls below the floor-price threshold

Common escalation triggers include:

• The other side’s offer is below 80% of the floor price.
• The other side asks to pay outside the platform.
• Tactics such as urgency, threats, fake identity, or forged credentials appear.
• Offers stall for several consecutive rounds.
• The risk score exceeds the threshold.
• The negotiation enters the final deal-confirmation stage.

Model routing should be built on task decomposition rather than leaving one model to handle everything. The general lesson, which applies to many systems, is this: identify the intent, calculate the price room, generate the message, and finally let the rule layer run a final check. This approach controls cost while also lowering the risk of model misjudgment.

5. What to Watch for in Fully Autonomous Operation: Boundaries, Risk, and Human Takeover

A key design choice in the experiment is that once an agent starts negotiating, no human steps in. Agents autonomously handle listing, quoting, counteroffering, and closing the deal. They do not go back to ask the principal for approval, nor do they ask for input during bidding.

This setup amplifies long-tail risk. For example, if the other side’s offer is far below the floor price, should the agent hold firm, counteroffer, or walk away? When several buyers bid at the same time, how should it trade off deal probability against price? Can it recognize manipulative tactics and end the negotiation? Fully autonomous operation is therefore not only a question of capability but also one of robustness and safety guardrails.

A responsible negotiation agent should have at least three types of mechanisms.

First, a hard constraint on the floor price. Agents must not accept a deal below the floor price beyond what they are authorized to do, and they must not bypass the rules just to “close the deal.”

Second, a circuit breaker for abnormal situations. It should cover offers below a set percentage of the floor price, detected deceptive tactics, repeated abnormal interactions, overly risky accounts, conflicts with platform rules, and payment-risk events.

Third, an auditable decision log. The basis for every round’s offer, every model call, every risk judgment, and the final reason for closing should all be replayable, traceable, and reviewable.

For real trading platforms or production environments, the following compliance checks should also be added:

1. Platform authorization and terms check
   Confirm whether the platform allows automated accounts, bot quoting, bulk listings, automated replies, or agent-based trading. Review the platform agreement, merchant agreement, API limits, and account-role permissions. Without authorization, the system should not run directly on a real platform.

2. Order fulfillment and risk check
   Check item authenticity, inventory accuracy, delivery timelines, shipping arrangements, return policies, and dispute-handling paths. Negotiation agents can only handle transactions within their authorized scope and must not make commitments they cannot fulfill.

3. Funds and anti-fraud check
   If real payments are involved, evaluate payment channels, escrow transactions, refund rules, abnormal-order monitoring, and anti-fraud strategies. High-risk transactions should require human review or delayed payout.

4. Privacy and data compliance check
   Negotiations involve user information, chat content, item details, and transaction records. Follow the principle of data minimization. Define retention periods, access permissions, anonymization methods, and deletion mechanisms so that sensitive information is not written into logs you cannot control.

5. Human takeover and incident response
   Production environments should keep a manual takeover switch. If abnormal offers, fraud complaints, platform warnings, user reports, or system misjudgments occur, you should be able to pause the agent immediately, switch to human handling, and keep a complete record of the incident.

Common engineering mistakes include writing only the prompt without a circuit breaker; chasing deal rates without checking compliance; shipping the model without keeping audit logs; and automating everything without a manual takeover option. For negotiation agents, the reliability floor often matters more than the capability ceiling.

6. Counterintuitive Directions: What the Experiment Can Validate

What follows are hypotheses based on the experiment design, not conclusions already verified in the original report. Three directions are worth testing, but each still needs confirmation against the raw experimental data and a stricter control design.

Hypothesis 1: Agents may hold the floor price more reliably, but they may also be more mechanical.
Human negotiation is often swayed by sunk costs, saving face, and emotional swings. If an agent strictly follows the constraints in its prompt, it may be less easily thrown off course by emotion. However, if its strategy is too rigid, it may also miss clearly worthwhile deals, because it does not necessarily understand implicit factors beyond its prompt, such as “long-term value” or “customer relationships.”

Hypothesis 2: Model strength and deal outcomes may not be linearly related.
Intuitively, the stronger the model, the better the negotiation performance. In reality, negotiation results also depend on the quality of the system prompt, how the principal’s preferences are defined, the other side’s strategy, and the incentive structure. The mixed configurations in Markets B and C can show how mixed deployments behave, but proving differences in model strength calls for a cleaner model ablation experiment.

Hypothesis 3: The credibility of commitments may influence negotiation behavior.
When participants know that their deals may really be settled, their agents’ pricing strategy may differ from that in research-only markets with no payout. When analyzing agent behavior, therefore, you need to treat whether the incentive structure is real as a key variable, rather than looking only at model output.

7. Engineering Checklist: Practical Recommendations for Building Negotiation Agents

Taken together, these findings translate into an engineering checklist.

Priority	Recommendation	Acceptance criteria
P0	Set a hard constraint on the floor price	Zero out-of-bounds deals, zero floor-price violations
P0	Build an audit log	100% log completeness, all key decisions traceable
P0	Complete platform authorization and compliance checks	100% completion of platform terms, funds, and privacy checks
P0	Keep a manual takeover switch	Takeover drills pass, alerts can reach the responsible person
P1	Configure circuit-breaker thresholds	Circuit breaks are explainable, false triggers stay within a controlled rate
P1	Design a model routing strategy	Costs stay under control, escalation paths for key tasks are clear
P1	Adopt a controlled-experiment mindset	Variables such as model, payout, and visibility can be separated
P2	Observe counterintuitive behavior	A closed loop of hypothesis logging, experiment review, and strategy iteration

From a practical standpoint, four things should be prioritized.

First, move personalization up front. Human-like agents for negotiation, customer service, sales, and similar tasks should place user preferences, style, and hard constraints in the system prompt up front, rather than relying on repeated adjustments at runtime.

Second, think in terms of controlled experiments. Before launch, use isolated markets, blind test copies, and contrasts between real and simulated payouts to turn vague product assumptions into measurable experimental questions.

Third, route requests across model tiers. Match models of different sizes to the difficulty of each subtask to balance cost against effectiveness, and avoid leaving one model to handle everything.

Fourth, prioritize guardrails over capability. Before letting an agent run fully autonomously, first put in place hard price constraints, abnormal-situation circuit breakers, and decision logs. The reliability floor of an agent determines whether it can truly be trusted with a task.

The bar for multi-agent negotiation systems is not whether agents can hold a conversation. It is whether they can make decisions reliably in a real environment, with cost constraints and no human safety net. The value of the public experiment material described here lies not in any single number but in a reusable methodology: use rigorous experimental design to isolate variables, system prompts to encode preferences, model routing to control cost, and compliance guardrails to define boundaries. Together, these practices turn “agents bargaining” from a demo into an engineering system that can be evaluated, governed, and deployed.