# Designing a tool that uses LLMs to negotiate SaaS prices. Looking for feedback on the architecture. > Source: > Published: 2026-09-28 17:08:04+00:00 One of the easiest ways to make an AI application difficult to use is to turn every capability into another screen. While building DealMind, we wanted to avoid that. The product has memory, evidence, strategies, what-if analysis, counteroffer guidance, customer history, and learning. But the user should not feel like they are navigating seven different applications. The solution was to organize everything around one object: the current negotiation. The main workflow is: Dashboard ↓ New Negotiation ↓ Analyze ↓ Recommendation ↓ Strategies / What-if / Counteroffer / Evidence / Customer ↓ Record Outcome ↓ Learning This keeps the user's mental model simple. The user starts with a deal. Everything else exists to help with that deal. The New Negotiation screen captures information that matters to the negotiation: • Customer • Industry • Segment • Deal value • Initial offer • Customer counteroffer • Requested discount • Objection • Competitor pressure • Contract length The user can enter their own negotiation. There is also a demo scenario for quickly understanding the workflow. The demo customer is not hardcoded into the product's identity. The system should work with arbitrary customers and negotiation values. After analysis, the user enters the deal workspace. Instead of creating separate permanent pages for every feature, the current negotiation contains tabs such as: **Overview Strategies What-if Counteroffer Evidence Customer** Hindsight should not be hidden behind the backend. One of the UX goals was to make memory visible when it matters. The user should be able to see that the recommendation is based on historical experience. Evidence identifiers help connect the recommendation to recalled memories. This gives the user a way to understand: **What did the system remember?** and: **Why did that memory matter?** A professional AI interface also needs to communicate when it does not have enough information. If Hindsight is temporarily unavailable, the system should not pretend that it recalled historical negotiations. Instead, the interface should indicate that historical memory is unavailable. Similarly, if the LLM is unavailable and the application uses a deterministic fallback, that should be clear. We considered this an important UX principle: **Uncertainty should be visible rather than hidden.** The same design philosophy applies to the short product demo. The demo should tell one story: Load a negotiation. Analyze it. Recall Hindsight memory. Show evidence. Show confidence and economics. Explore strategies. Record the outcome. Show the learning update. The user should be able to understand the entire memory loop without navigating through unrelated screens. The learning feature also changes how we think about the product. If the application only produced a recommendation, the workflow would end at the recommendation. But DealMind continues: **Recommendation → Outcome → Memory → Future recommendation** That means the UX needs to make the outcome step visible. The user should understand that recording the result is not just administrative work. It is how the system gains another piece of organizational experience. Another design decision was keeping technical system information separate. API health, memory configuration, and system status belong in Settings. They should not dominate the main negotiation experience. The salesperson's main concern is the deal. The system's technical implementation should support that workflow without getting in its way. DealMind is designed to support the salesperson rather than replace them. The interface presents evidence, calculations, strategies, and customer context. The user decides what to do. This makes the product feel more like a negotiation workspace than an autonomous chatbot. The UX challenge in DealMind was not simply making the interface look good. It was making the memory loop understandable. The user should be able to see: **What the system remembered. Why it mattered. What the system recommends. What happened afterward. How that outcome can become future memory.__**