Use the proposal as the conversation's anchor
Attach incoming questions to the correct proposal version and customer account. A conversation about ongoing support should not inherit the assumptions from an earlier website-build proposal. Keep the current scope and the history of revisions available together.
Separate questions about the written offer from requests to change it. 'Does this include the migration described on page three?' may have a documented answer. 'Can you also migrate our older system for the same price?' changes the work and needs someone with authority.
Design a useful engineering handoff
A handoff should contain the actual question, relevant proposal text, known constraints, and the decision needed. Avoid asking an engineer to read an entire sales thread just to discover that the customer wants to know whether a data import is included.
Use separate owners for separate decisions. Delivery dates may belong to a project lead, commercial changes to sales, and security questionnaires to the security team. An agent that routes everything to one shared inbox can simply relocate the bottleneck.
Customer question: Can the import include five years of archived records? Current proposal: migration of active customer records only. Known constraint: archive format has not been inspected. Decision needed: assess scope and effort before sales sends revised terms.
Build predictable steps before flexible ones
Use fixed rules for steps such as choosing the account, checking whether a proposal is current, or deciding whether a message has already been processed. Reserve language interpretation for work such as identifying the question and drafting an explanation from approved material.
Anthropic's agent guidance describes the tradeoff between predictable workflows and more flexible agent-driven processes. For a proposal workflow, this suggests a practical architecture: explicit permission checks around any step that changes a customer-facing commitment.
Keep sensitive answers tied to approved evidence
A security answer should come from current, approved documentation. Do not let an agent infer a certification from a marketing phrase such as 'enterprise-ready.' Likewise, a public roadmap is not authorization to promise a delivery date or a feature in the customer's contract.
Limit the information available to the customer's own account and the relevant approved company material. Include account boundaries in your tests. A fluent answer is a failure if it contains another customer's private implementation details.
Test messy conversations, not just clean questions
Create tests with several questions in one message, a changed requirement halfway through the thread, and an attachment that contradicts the proposal. Include a customer who accepts only one option and a customer who asks to postpone the decision.
Anthropic's evaluation guidance treats agents as systems whose behavior must be tested across tasks and outcomes. Apply that idea by checking both the reply and the resulting records: correct account, correct owner, no duplicate action, and no unauthorized change.
Measure a shorter path to a decision
Track time spent finding context, time waiting for an internal answer, and how often a customer has to repeat a question. Those measures identify whether the agent improves the handoff even before you have enough completed deals to discuss sales outcomes.
The useful result is a customer conversation that keeps moving with accurate information. Engineering still owns technical commitments, commercial owners still approve changes, and the customer receives a coherent answer instead of a tour through your internal departments.