AI Sales Agent

A clear picture of what we're building.

Based on our review of TruAbutment's prototype documentation, the call on April 27, and the technical walkthrough, we have a clear picture of what you are building and what it will take to get there.

The prototype validated the right instincts: an orchestrator-expert agent pattern, a proxy layer between the agent and your CP APIs, and a split between informational products (RAG) and catalog items (direct API). The gap between the prototype and a production system is well-defined, and this proposal addresses it directly.

What you are building.

A fully conversational interface for product discovery and ordering, embedded in your website and iOS app. Two fundamentally different types of data, served by two fundamentally different mechanisms: a distinction that shapes the entire architecture.

Who uses this system.

Four personas use this system. The Buyer is the primary design constraint: every architectural decision is tested against their needs first.

Proposed architecture.

Five layers. Every channel (web, iOS, future touchpoints) communicates through a Python FastAPI gateway built entirely by SoluteLabs. LangGraph orchestration, RAG retrieval, and all business logic run within this unified Python service. BotPress is removed entirely.

Technical approach.

5.1Dual user flow

The agent uses session state to route conversations to two distinct flows. The user sees one interface.

Lead capture does not require a full CRM. Initially: Google Sheets via API, or a minimal DB table (name, email, conversation summary, product interest, timestamp). Sales rep receives an email notification with the transcript. Upgradeable to HubSpot or similar without changing the agent logic.

5.2Order workflow, as a state machine

The LLM proposes. Application logic gates. No order can be created without passing through every state in sequence.

1. 01

   Idle → Intent

   User describes a need. Orchestrator detects order intent and routes to Cart Assembly.

2. 02

   Cart Assembly ⇌ Modification Loops freely

   Items extracted via structured LLM output (product_id, quantity, variant). Validated against CP catalog API before entering cart. Ambiguous items trigger clarification cards, never a guess. Phase 1 supports ordering by SKU lookup across the full 3,000+ catalog (buyer names the item, agent fetches and validates). Phase 3 adds conversational discovery ("find me a 4.5mm fixture compatible with this case") over the same catalog.

3. 03

   Estimate

   Read-only CP API call. Shows live account-discounted pricing. No order created yet.

4. 04

   Review

   Generative UI card rendered in chat: product list, quantities, total price. User can modify or confirm.

5. 05

   Submit Gated, explicit button

   Voice cannot trigger submit. The Submit button must be pressed explicitly. Idempotent: dedup key prevents duplicate orders on retry.

6. 06

   Confirmed Terminal

   CP order created. Confirmation shown in chat with order number.

5.3RAG & knowledge layer

The most important decision in the RAG architecture is what not to RAG. Category B catalog items are structured spec data: direct API lookups are faster, cheaper, and always accurate. RAG is reserved exclusively for Category A.

On vector store and embedding model selection: we commit to pgvector on PostgreSQL as the vector store: no new infrastructure, transactional consistency with the rest of the data layer, and proven at the volume of 8 KB products with sectioned chunks. The embedding model is benchmarked in week 1 of the discovery sprint against actual KB content and real user queries; dental and clinical terminology is specific enough that the right choice must be validated, not assumed.

On iterative improvement: we distinguish three things that are often conflated. (1) RAG iteration: improving chunking, retrieval, and re-ranking based on real query telemetry. Ongoing, high-leverage. (2) Prompt iteration: refining system prompts and few-shot examples. Also ongoing. (3) Model fine-tuning: retraining the LLM on TruAbutment's domain. We recommend against this. The gains are marginal when RAG is well-designed, and the maintenance cost is high.

5.4KB management dashboard

The admin dashboard is a blocking dependency for sustainable operation. Without it, every KB update requires an IT ticket. It is in scope for Phase 1.

Publish pipeline: Edit → Validate → Re-embed (changed chunks only) → Index → Regression eval → Live. Triggered by clicking Publish. No manual steps.

Quality gate is a soft warning, not a hard block. When a KB update causes a regression on the golden QA set, the publisher sees a warning and must explicitly override to proceed. Hard blocks cause operational friction: a product manager cannot fix a typo because an unrelated test regressed.

5.5Voice mode

5.6HITL escalation

The agent escalates when it detects: negative sentiment, three consecutive clarification failures, an explicit user request, or a high-value order threshold (configurable).

On escalation, the agent pauses the conversation and sends the sales rep a package containing: full conversation transcript, current cart state, retrieved KB chunks that grounded the last response, and the user's account profile (if logged in). Initial delivery via email. Upgradeable to Intercom or Zendesk without changing the agent logic.

5.7Performance targets

The following are design targets, not contractual SLAs. They represent the user-perceived latency we engineer toward. Production SLAs (uptime, error-rate guarantees) are scoped in the post-launch retainer once real load patterns are established.

Three phases plus a paid discovery sprint.

Phase 1 is the production foundation: everything else builds on it. Phases 1 and 2 overlap by ~2 weeks once the /chat API is stable.

Investment & pricing.

A fixed-price proposal. The price absorbs the discovery-phase risk on the open items in Section 8 (CP API documentation, SSO status, idempotency). No change orders on items resolved in the discovery sprint.

Pricing is based on our standard rates: $40/hr for developers and $60/hr for technical leads, 40 billable hours per engineer per week. Dev hours reflect a 25% efficiency gain from agentic tooling (Claude Code, Cursor). All team members carry US-hours availability.

7.1Phase schedule

00

Discovery Sprint

1 week · 1 dev (40h) + 1 TL (20h)

$3,000

01

Production Foundation

9 weeks · 2 dev + TL @ 50%

$39,000

02

Mobile, Voice & Sales Intelligence

9 weeks · 3 dev + TL @ 50%

$48,000

03

Scale & Personalisation

6 weeks · 2 dev + TL @ 50%

$24,000

Total

Fixed price.

22 weeks build · 23 weeks end-to-end

$114,000

7.2Investment by capability

Same total, viewed by what each capability delivers. Useful when prioritising features or evaluating ROI per surface.

7.3Operating costs (client-paid)

LLM, STT, TTS, and embedding inference costs are paid directly by TruAbutment via your own API keys (OpenAI or Azure for LLM and embeddings, ElevenLabs for TTS). This keeps data ownership, rate limits, and any enterprise-rate negotiations on your side. SoluteLabs configures the keys; we do not mark up inference.

7.4Post-launch retainer

After go-live, a monthly retainer covers RAG iteration (chunking, retrieval, re-ranking improvements based on real query telemetry), prompt iteration, KB content support, eval set expansion, monitoring, and minor feature work. Tier can be adjusted month-to-month with 30 days' notice. Unused hours roll forward one month.

Open items before SOW.

These items need to be resolved before we produce a fixed-price Statement of Work. We propose resolving them in a paid 1-week discovery sprint.

Engagement model.

Three steps from this proposal to Phase 1 kickoff. Discovery sprint runs first to lock the items in Section 8, then a fixed-price SOW per phase, then build.

Why SoluteLabs.

Next steps.

1. Review this proposal and flag any corrections or additions, particularly on the architecture and scope sections.
2. Confirm the open items list in Section 8: identify owners and any items already resolved.
3. Sign off on the discovery sprint engagement. We can start within 5 business days.
4. Introduce us to the CP API owner so we can begin documentation review during discovery.