AI Agent Negotiation Experiment: 186 Deals Reveal That Prompt Personas Matter Less Than Model Capability

Over the past few years, conversational AI agents have focused mainly on answering questions, summarizing content, generating code, and assisting with tasks. As agents have moved into real business settings, the industry’s central question has shifted from “can it understand instructions?” to “can it represent a user and accomplish complex goals?”

Business negotiation is one of the most representative scenarios for this shift. Unlike simple information retrieval or content generation, negotiation involves several steps at once: understanding goals, controlling budget, extracting information, formulating strategy, responding to offers, countering bids, deciding when to close, and handling exceptions. A complete automated negotiation is essentially a multi-step decision process driven by a large language model (LLM).

One internal simulated market experiment produced a notable result. In an environment where agents independently listed items, made offers, negotiated counter-offers, and closed deals, they completed 186 transactions with a total transaction value of more than $4,000. Participants only had to state in advance what they wanted to buy or sell and their general negotiation preferences. The agents then handled the rest of the process on their own.

The real value of the experiment lies not in how many deals closed, but in several key technical findings it exposed:

1. Negotiation styles set in prompts had far less impact on final results than expected.
2. The side using a stronger model generally achieved objectively more favorable outcomes.
3. Users represented by the weaker model often failed to realize in time that they had gotten a worse deal.
4. Agent monetization experiments must prioritize observability, reconciliation mechanisms, and risk controls rather than deal volume alone.

These findings are relevant to teams building agent-powered trading, intelligent customer service, intelligent procurement, or matching platforms.

Experiment Design: Using Multiple Markets to Simulate Real-World Uncertainty

The experiment’s design is worth examining in detail. Rather than simply having two agents talk to each other, it built a multi-round environment that more closely resembles a real market.

1. Participants, Budgets, and Goals

The experiment included 69 participants. Each received a $100 budget to buy or sell second-hand items or services. Before joining, every participant completed an interview covering the items they wanted to buy or sell, an acceptable price range, delivery method, time limits, and personal preferences.

The system then generated a task configuration for each agent based on this information. The key point is that participants did not hand-write complex prompts. Instead, the agents derived goals, constraints, and negotiation style from the interview content.

This reflects a common engineering pattern: users provide goals in natural language, and the system automatically converts them into an executable strategy.

2. Four Parallel Markets: Simulating Different Model Capability Distributions

The experiment ran multiple independent markets. Agents in different markets were configured with different capabilities. Some markets used only more capable models, some mixed more and less capable models, and some ran as control conditions used only for research, with results not actually settled.

This design is similar to canary releases or controlled experiments in software systems. It allowed the research team to examine several questions:

• How good is the quality of completed deals when every participant uses a strong model?
• When strong and weak models compete in the same market, does a clear information gap emerge?
• Do participants know which market they are in?
• Will deals actually be settled, and does that affect participants’ decision-making?

Notably, participants did not fully know whether their market’s deals would actually be settled, nor which tier of model was behind their agent. To some extent, this reduced behavioral bias caused by knowing they were being observed.

3. The Boundary Between Real and Simulated Transactions

The experiment was not a purely theoretical exercise. It tried to simulate a real trading environment as closely as possible. Agents had to search for items, negotiate prices, close deals, and confirm delivery within a limited budget. Trading targets included both standard products and non-standard services, such as second-hand sports equipment and everyday items. The experiment even included a non-physical trading intent similar to a dog-walking service.

This shows that agents are evolving from single-turn Q&A tools into multi-turn task executors. They must not only understand user intent, but also keep making decisions in uncertain environments.

Counterintuitive Finding #1: Negotiation Style Matters Less Than Information Structure

The conventional view is that negotiation style has a major impact on outcomes. An aggressive negotiator might secure a lower price, while a friendly one might close deals more easily. The experiment showed otherwise. Whether agents were configured as “aggressive” or “friendly”, the final deal outcomes showed no statistically significant difference.

This result is counterintuitive because it challenges a widely held assumption about personas. From an engineering perspective, it can be explained in several ways.

1. Style Is Only Surface-Level Expression and Does Not Change Underlying Constraints

Style settings in prompts, such as “be firmer”, “be more polite”, or “be more willing to concede”, mainly affect how the agent expresses itself. They do not automatically change the agent’s core decision constraints.

Negotiation outcomes are typically determined by the following factors:

• The user’s reserve price, meaning the lowest acceptable price when buying or the highest acceptable price when selling
• Market scarcity and the number of available alternatives
• The counterpart agent’s offer strategy
• Limits on the number of negotiation rounds
• Product descriptions and delivery conditions
• How accurately each side’s model assesses value

If these underlying constraints stay the same, changing only the tone usually affects the quality of the conversation rather than the price range.

2. Market Structure Offsets One-Sided Style Bias

In a market with many participants, agents do not negotiate only with a fixed counterpart. They keep encountering new parties with new offers. If an agent is too aggressive and loses trading opportunities, the system often rematches it with someone else. If it is too friendly and ends up with unfavorable prices, other competitors in the market provide new reference prices.

This means the market itself has a degree of self-correcting ability. The style bias of a single agent can be diluted by multi-round feedback and competition from multiple counterparts.

3. LLMs Are Better at Executing Goals Than Performing a Persona

LLMs generally perform well on task execution, but they are not necessarily reliable at consistently maintaining complex persona settings. For a trading task, what users really care about is not whether the agent sounds tough, but whether it can accomplish the goal within the given constraints.

For this reason, spending too much effort tuning a “character persona” may be less valuable than optimizing these engineering elements:

• Clearly defined upper and lower budget limits
• Step sizes for offers and counter-offers
• Hard constraints that cannot be crossed
• Fallback strategies when a deal fails
• Teaching the agent to adjust prices dynamically based on the counterpart’s responses

From a system perspective, prompt style is more like an interaction-layer parameter, while trading strategy is the core of the decision layer.

Counterintuitive Finding #2: The Weaker-Model Side Often Fails to Notice It Is at a Disadvantage

Another important finding is that the side represented by the stronger model generally achieved objectively better outcomes, such as a higher selling price or a lower buying price. However, the side represented the weaker model often showed no clear awareness that it was at a disadvantage.

This phenomenon deserves close attention because it reveals a “capability asymmetry risk” in agent-based trading.

1. Closing a Deal Does Not Mean Making the Optimal Decision

Ordinary users tend to view “the agent eventually bought or sold something” as a success. But real business goals also include whether the price was reasonable, whether the conditions were met, and whether a better alternative existed.

If users can only see the final deal and not the agent’s decision process, they easily fall into “deal bias”: as long as a transaction closes, they assume the task succeeded.

From an engineering perspective, it is essential to distinguish among these outcomes:

• Whether a deal closed
• Whether it closed at a reasonable price
• Whether the budget constraint was satisfied
• Whether a better offer was missed
• Whether insufficient information led to a suboptimal decision

2. Weaker Models Are More Prone to Judgment Errors

More capable models are generally better at tasks such as:

• Extracting key information from unstructured descriptions
• Assessing an item’s true value and a reasonable price range
• Identifying hidden intent in a counterpart’s offers
• Weighing trade-offs among multiple options
• Flagging risks under abnormal conditions
• Making trade-offs among budget, time, and delivery conditions

Weaker models are more easily misled by surface-level information. For example, they may focus only on a low price, overlook delivery costs, misunderstand the scope of a non-standard service, or concede too quickly during repeated rounds of counter-offers.

3. Users Lack the Ability to Attribute Outcomes, Which Amplifies the Risk

Ordinary users find it difficult to tell whether a transaction reflects normal market fluctuation, a sound strategy, or a shortcoming in the agent’s capabilities. Without clear decision records and reconciliation reports, users cannot review what happened.

For this reason, an agent trading system should not output only “deal closed.” It should also provide:

• Why this price was accepted
• How the outcome compares with the initial goal
• What the current market price benchmark is
• Whether a better alternative existed
• Whether there were any abnormal risks or a recommendation for human intervention

Otherwise, capability gaps are masked by completed deals, which may damage user trust over the long term.

From an Engineering Perspective: Agent Negotiation Is a State Machine, Not a Chat

To turn this kind of experiment into a reusable system, you cannot rely on a single LLM prompt. Instead, it should be designed as a complete decision system.

A typical architecture for agent negotiation usually includes the following modules:

1. Goal Understanding Layer

This layer converts a user’s natural-language needs into structured goals.

Example:

user_goal:
  action: buy
  item_type: second_hand_snowboard
  budget: 80
  constraints:
    - must_be_used_condition_good
    - local_delivery_preferred
    - no_urgent_delivery

The key to this layer is eliminating ambiguity. Vague expressions such as “make it cheaper,” “close the deal as soon as possible,” and “good quality” all need to be converted into quantifiable conditions.

2. Strategy Configuration Layer

This layer defines the boundaries of the agent’s behavior during negotiations.

Example:

negotiation_policy:
  opening_price: 65
  reserve_price: 80
  max_rounds: 6
  concession_steps: [3, 2, 1, 0]
  allow_counter_offer: true
  fallback_action: request_human_review

This layer should not simply state “friendly” or “aggressive.” It should clearly define price step sizes, the maximum number of rounds, concession rules, and exit conditions.

3. State Management Layer

Negotiation is not a single-turn conversation but a series of multi-turn state changes. The system needs to track:

• The current offer
• The history of offers
• How much the counterpart has conceded
• The remaining budget
• The current time limit
• Whether a risk warning has been triggered
• Whether the reserve price is close to being reached
• Whether human intervention is needed

This is similar to the order state machine in an e-commerce transaction system. The difference is that agent negotiation involves more states and more uncertainty, and it requires more real-time judgment.

4. Tool Invocation Layer

Agents need to call external capabilities, such as product search, offer generation, message sending, deal confirmation, and log recording. Tool calls should be governed by access controls to prevent agents from exceeding their authority and performing high-risk operations.

For example, in high-value transactions, the system should allow the agent to make recommendations but not to close deals directly. In low-value, low-risk transactions, it can allow automatic execution.

5. Evaluation and Audit Layer

The experiment produced valuable conclusions because it had data on completed deals, prices, and model configurations available for analysis. Production systems need an evaluation framework as well.

Core metrics can include:

• Deal completion rate
• Average deal price
• Deviation between the deal price and the target price
• Number of negotiation rounds
• Average time to close
• User regret rate
• Human intervention rate
• Share of abnormal transactions
• Number of budget overruns
• Differences in returns across models or strategies
• Ablation results for different prompt versions

Without these metrics, an agent system easily becomes a black box that “seems to run but nobody knows whether it actually works.”

Why “Prompt Style” Is Not the Most Worthwhile Investment

When building agents, many teams spend a lot of time tuning prompts to make agents more professional, more polite, more assertive, or more like salespeople. This experiment suggests that the marginal returns of style tuning may be limited.

The directions most worth prioritizing are:

1. Structuring Goals

The vaguer the user’s expression, the more easily the agent drifts from the goal. The system should first help users clarify their budget, delivery conditions, acceptable alternatives, and bottom line.

2. Designing Price Anchors

Agents need to know what counts as a reasonable price. You can introduce historical deal prices, quotes for similar items, market averages, or user-defined benchmarks. Without price anchors, negotiation easily turns into blind bargaining.

3. Designing a Concession Strategy

Negotiation is not a one-time offer but a dynamic process. The system should define clear concession rules, such as decreasing the size of each concession, stopping once the reserve price is reached, and triggering a review when a counterpart’s offer is abnormally low.

4. Building an Exit Mechanism

Not every deal should go through. When conditions related to budget, delivery, compliance, or risk control are not met, the agent should be willing to walk away and clearly explain why to the user.

5. Identifying Risks

Risk checks should be triggered for high-value items, non-standard services, suspected fraud, obviously abnormal low prices, or transactions that exceed the budget.

Three Takeaways for Agent Monetization

Although the experiment took place in a controlled environment, it revealed several key trends as agents move into commercial settings.

1. The Key to Agent Trading Is Being “Constrainable,” Not “Human-Like”

An agent that can negotiate is nothing unusual. The hard part is keeping it acting within the scope the user has authorized. Commercial systems care more about whether the agent:

• Stays within budget
• Stays within its authority
• Does not hide key information
• Does not keep closing deals under abnormal conditions
• Can pause at critical points and ask for confirmation

The closer agents get to real transactions, the more important safety boundaries become.

2. Differences in Model Capability Become Real Economic Differences

In ordinary Q&A scenarios, insufficient model capability may only mean a drop in answer quality. In trading scenarios, it can directly lead to financial losses. This means agent systems must clearly define capability tiers and the scenarios each tier is suited for.

High-risk tasks should not simply be handed to a low-capability model. The system should dynamically switch models or add human review based on task value, budget, and risk level.

3. Users Need “Explainable Deal Reports”

A completed deal is only the result. Users also need to know whether the process was sound. A well-built agent trading system should provide a decision summary, such as:

• What the initial goal was
• How many rounds of negotiation took place
• How the final price compares with the market benchmark
• Whether budget protection was triggered
• Whether any offers were declined
• Whether there are potential risks
• Whether the user is advised to review the deal further

This not only builds trust but also helps the platform keep improving its strategies.

From Experiment to Production: Capabilities Still Needed

To move from the lab into real business operations, an agent negotiation system needs several more capabilities:

1. Access isolation: Different users, markets, and budgets must be strictly isolated from one another.
2. Data masking: Interview content, product descriptions, and negotiation records may contain sensitive information and need to be masked and access-controlled.
3. Audit logs: Every offer, counter-offer, acceptance, rejection, and completed deal should be traceable.
4. Anomaly detection: Identify behaviors such as fake transactions, fraudulent listings, malicious offers, and deal manipulation.
5. Human fallback: Introduce human review for high-value or high-risk transactions.
6. Compliance checks: Verify product categories, service scope, delivery methods, and transaction conditions for compliance.
7. Monitoring and alerting: Trigger real-time alerts for abnormal deals, abnormal prices, sudden spikes in failure rates, and budget overruns.
8. Canary experiments: Before rolling out a new strategy, validate its effectiveness with a small-traffic controlled experiment rather than releasing it to all users at once.

These capabilities are independent of any specific model. They are fundamental engineering requirements for commercializing agents.

Conclusion: The Core Competitiveness of Agent Negotiation Lies in Decision Quality

The most counterintuitive aspect of this experiment is twofold. People assumed negotiation style mattered a great deal, but the results showed its impact was limited. People also assumed that a completed deal meant success, but the results exposed that the weaker-model side might not even realize it had lost out.

For developers and businesses, the real focus should not be making an agent “more like a certain negotiation expert.” It should be giving the agent reliable decision-making, clear goal understanding, strict budget constraints, explainable process records, and a complete risk-control mechanism.

Once agents enter commercial markets, the focus of competition will shift from “can it talk?” to “can it be trusted with the task?” A qualified agent must not only complete transactions, but also demonstrate that those transactions were reasonable, the risks were controlled, and the process can be audited. This will be the key dividing line that takes agents from demos to production systems.