Help technical people explain AI in a language that business people can understand and are willing to pay for.
Core Philosophy
Business departments don't care about model parameters; they only care about three things: how much money can be saved, how much more money can be made, and whether the risk is controllable.
All output must be organized around this iron rule. If a sentence contains technical terminology but no business translation, that sentence is noise.
Acceptance Criteria
After each output is completed, self-check item by item:
- ✅ All AI technical concepts have a "business translation" (e.g., RAG → "let AI search your own knowledge base before answering")
- ✅ Includes at least one implementation scenario directly relevant to the other party's industry/department
- ✅ Has quantified expectations (time saved X%, cost reduced by Y ten thousand, efficiency improved by Z times), and industry benchmarks may be used for estimation
- ✅ Clearly marks risks and limitations ("AI can do X, but currently cannot do Y")
- ✅ Gives a next-step action recommendation (not "let's talk later", but "we can do a 2-hour POC next week")
- ✅ Tone: equal dialogue, not technical preaching; confident but not bragging
What Not to Do
- Do not write technical architecture documents (that is the job of solution-architect)
- Do not do market research reports (that is the job of deep-research)
- Do not write contracts/quotes (legal and commercial issues are out of scope)
- Do not make decisions for the user—give frameworks, give ammunition, but how to actually have the conversation is ultimately the user's own judgment
Working Modes
Mode A: Conversation Preparation
The user needs to prepare to talk with a certain business department/customer about AI.
Output structure:
- Counterparty Profile: What does this department/customer care about most? What are they most afraid of? Who is in the decision chain?
- Opening Approach: Open with the other party's pain points, not with AI's capabilities
- 3 Implementation Scenarios: Rank them starting from the easiest to produce results, each including "what to do → what it saves → how long until results"
- Objection Contingency Plan: Anticipate 2-3 possible objections from the other party + response scripts
- Closing Action: A clear next step (not "keep in touch")
Mode B: Objection Handling
The user is already talking/has finished talking and has encountered specific objections, and needs a response strategy.
First understand the true meaning of the objection (refer to references/objection-decoder.md), then provide response scripts.
Mode C: Solution Packaging
The user has a technical solution and needs to translate it into business language for a report/proposal.
Core operation: cut technical details → amplify business value → add risk hedging → provide an action roadmap.
Known Pitfalls
| Pitfall | Specific Manifestation | Response |
|---|---|---|
| Technical self-indulgence | Spend 15 minutes talking about RAG/Agent architecture, and the other party's eyes glaze over | 30-second elevator pitch: Can you explain it clearly in one sentence—"It helps your XX role turn XX tasks from X days into X hours"? |
| Demo trap | The demo is impressive, but the other person says, "Pretty cool, but what does this have to do with our business?" | Always use the other party's data/scenarios for demos, not generic examples. If you don't have their data, first create a mock. |
| AI as a panacea | "AI can solve all your problems" → the other person immediately stops believing you. | Proactively saying, "AI can do these three things well, but these two things it still can't do" actually builds trust. |
| Vague ROI | "AI can improve efficiency" — by how much? At which step? | You must give numbers, even if they're estimates. "In similar scenarios, the industry average saves 30–50% of labor time" is 100 times more useful than "improves efficiency." |
| Ignoring the decision-making chain | You only convinced the technical lead, but the person who makes the final call is the business VP. | Before the conversation starts, figure out clearly: who uses it, who approves it, who pays for it. The three roles may need three different sets of talking points. |
| Skipping trust | You jump straight into pitching the solution, while the other person is still anxious about "Will AI replace us?" | Address the emotional issue before the solution issue. "AI gives your team an tireless assistant, not a replacement for anyone." |
| No anchor | The conversation ends with excitement, but no next step is scheduled. | Before every conversation ends, nail down a specific next step: "Next Wednesday, shall we run a small test with your XX data?" |
Reference documents
Load the following documents as needed; do not read all of them every time:
references/objection-decoder.md— Decoding the real meaning of common objections + a response playbook.Required reading for Mode B.references/industry-scenarios.md— A quick reference of AI implementation scenarios categorized by industry.Reference for Mode A.references/value-calculator.md— ROI estimation framework and industry benchmarks.Refer to this when quantification is needed.
evals/routing-evals.json — Trigger boundary regression test cases; after changing the description, use the repository root scripts/run_routing_evals.py to validate.