Article · TypeScript
Let the model reason, not promise: building QuotePilot AI
QuotePilot AI splits flexible AI reasoning from business-critical commitments. Qwen structures the request, deterministic tools compute price and availability, and nothing reaches a customer without human approval.
The problem with "AI quoting"
Quoting looks like a perfect job for a language model. It has to read a messy request, work out what the customer wants, and write a friendly email with a price. It's also exactly where a model is most dangerous. A price or an availability date in an email is a commitment. If the model invents one, the business owns that mistake.
Our team, which included Aqeela Urooj, built QuotePilot AI for Track 4 (Autopilot Agent) of the Global AI Hackathon Series with Qwen Cloud on Devpost, around one rule:
The model may reason. It may not promise.
The shape of the system
- Reasoning (Qwen Cloud). A server-only route calls Qwen through its OpenAI-compatible API. Qwen turns an unstructured request into schema-constrained analysis covering the objective, requested features, timeline, budget, missing information, an allowed package recommendation and draft email content.
- Validation. Zod checks that output before any business tool touches it. If it's malformed, the app says so and doesn't invent a fallback.
- Deterministic tools. Price and availability come from code, working from a small controlled catalogue. The same inputs always give the same answer, and that answer can be tested.
- A clarification pause. If Qwen flags missing information, the workflow stops and asks rather than guessing.
- Draft, not send. The agent assembles a quote and a draft reply.
- Mandatory human approval. A person approves or rejects before the email and CRM steps run. A rejection leaves them untouched and records that nothing was sent.
- Deployment. It was deployed as an Alibaba Cloud Function Compute web function in Singapore, using Next.js standalone output.
The honest caveat: in this MVP the email, CRM, calendar and availability tools are simulations, and there's no authentication or quote history yet. The case study lists what was verified and what wasn't.
Why split it this way
- Auditability. Every number in a quote traces back to a tool call with known inputs.
- Testability. Pricing rules live in deterministic code that can be unit-tested, so prompts don't have to carry business logic.
- Safe failure. If the model misunderstands a request, the worst case is a bad draft that a human catches, not a wrong commitment sent to a customer.
- Visible state. Every stage is logged, so the approval boundary shows up in the UI and in the logs rather than only in a design document.
Giving the model less authority made a stronger product. Qwen could be flexible about language precisely because it had no power over the numbers.
What I'd carry into client work
The same pattern shows up in ScopeGuard AI, which turns instructions into an approved delivery plan, and in NeighborOps AI, which automates routine requests and escalates the judgement calls. The rule underneath all three: let AI do the reading and drafting, let code make the commitments, and let people make the decisions.
That's also how I approach agent work for clients through Teqprotech's AI agents service. More projects built this way are on the AI agents skill page, and I compared four of these builds in Human approval is an architecture decision.
A shorter version of this piece first appeared on LinkedIn (July 2026).
Project: QuotePilot AI · Stack: Qwen Cloud, Next.js, TypeScript, Alibaba Cloud Function Compute.
Work like this runs through Teqprotech · Custom Web Applications , AI Agents with Human Approval