Product · Nagent AI
Convexa
A conversational execution agent. It does not just answer questions: it qualifies a lead, writes the result back to the CRM and hands off scheduling, inside one conversation.
I own it end to end at Nagent AI: direction, system-prompt architecture, evaluation, onboarding, pricing and go-to-market.
Results so far
Early production, real numbers.
First paying enterprise customer, a deal I ran from proof-of-concept through security review. The sample is early and the unanswered rate will move as query diversity grows. I would rather report a real number on a small base than a projected one.
Why it exists
From "answers questions" to "finishes a job."
When I took Convexa over it was positioned as a RAG knowledge chatbot: upload documents, get a bot that answers from them. That category is crowded, it is commoditising fast, and its buyers churn the moment a cheaper option ships.
The two competitors we lost deals to shared one repeated complaint in their public reviews: the bot confidently makes things up. So I made two bets, and everything on this page follows from them.
Reposition around a finished job
Qualify, sync, hand off. A measurable outcome, not a transcript.
Make not-hallucinating the wedge
Turn the thing customers complain about into the thing we are unambiguously best at.
Architecture
One compiled prompt per customer.
A customer never writes a prompt. They answer functional questions in a one-screen onboarding flow, and the backend assembles a single system prompt from fixed blocks at deploy time. Every version is stored, so a deployment is an inspectable artifact, not a text box someone edited live.
- Core guardrailsIdentical for every customer, never edited
- Brand and toneMerge fields from onboarding: name, voice, languages
- Admin's custom guardrailsFree text, validated against core before it is accepted
- Intent modules1 to 3 from a fixed set of 8, plus custom modules compiled on demand
- Fallback and engagement policiesA few admin toggles per active job
- Intent routerAdded only when two or more intents are active
- One system prompt per customerCompiled, versioned, stored. A new customer goes live in about 10 minutes.
Why modules instead of a bespoke prompt. Tuning a prompt by hand for every customer does not scale and does not stay safe: each one is a place a guardrail can be dropped by accident, and every change is a regression risk nobody can see.
The trade-off I accepted. A module system is less expressive than a free hand. A customer with an unusual job has to fit one of the eight intents or get a custom module compiled, which is validated the same way. In practice a real deployment uses one to three intents, so the ceiling has not bitten yet. What I bought: a new customer goes live in about ten minutes, and no customer can ship a prompt that breaks a core rule.
Integrations. CRM sync is bi-directional and runs through Composio instead of a hand-rolled integration: routing rules, a deal-versus-ticket split, and sentiment and lead-quality scoring written back to the CRM.
Decisions
The calls I had to defend.
The reasoning behind each one, in brief. The full teardown has the detail.
A three-level guardrail precedence
Core guardrails outrank an admin's custom guardrails, which outrank intent module defaults. An admin can tighten core for their workspace but never loosen it, and every custom rule is checked against core before it goes live. That keeps the demo that wins deals ("type your own rule and watch it take effect") without the outcome that loses renewals.
Strict grounding, no dead ends
The agent answers only from the connected knowledge base, the conversation and connected tools. If the answer is not there, it says so and names a next step in the same breath: another source, a handoff or a clarifying question. A bare "I don't know" counts as a failure, which is the difference between safe but useless and safe and still moving.
An eval gate on every release
Modules are shared, so one change can regress every customer that uses them. A golden dataset of representative conversations, scored by deterministic checks and an LLM-as-judge rubric, blocks regressions. A separate adversarial set (prompt injection, jailbreaks, out-of-scope asks) has to pass clean. It is the least glamorous part of the system and the one that lets me change a shared module with confidence.
Onboarding is questions, not prompt writing
The inherited version was an eight-step wizard that most people did not finish. I cut it to a single intent-capture screen and moved everything else to later, in context, with a working assistant already in front of the user. I benchmarked 16 competitor onboarding flows first: the ones that converted best deferred configuration until after first value.
Price the outcome, gate only the outcome
Three self-serve tiers plus a custom Enterprise tier, billed per conversation and not per seat, so adding teammates is never punished. A $1 trial gives the entry plan for 14 days. Engineering proposed locking every page for an unpaid workspace; I scoped the paywall to one action, pushing the assistant live on the real site, so prospects reach the value before they hit the wall.
Say what is not live
The roadmap is named as roadmap, below, and not implied in the product story. Saying so plainly is part of the grounding pitch: the product should not over-claim any more than the agent should.
Latency
4.7 seconds to 1.2, as a product feature.
In a chat product the gap before a reply is felt the way a person going quiet mid-conversation is felt. The metric that matters is time to first token: how long before the visitor sees anything happen. Early on the median was 4.7 seconds, correct answers that felt broken. Four changes fixed it.
Structured knowledge base
Moved from plain PDF and TXT to JSONL with metadata tags, so hybrid BM25 plus semantic retrieval filters precisely instead of scanning loosely. Answer quality improved at the same time as speed; here they were not a trade-off.
Bounded context
Only the last 5 turns are replayed on each message. Older context that still matters lives in the knowledge base, not in raw chat history.
Cached system prompt
Guardrails, brand and tone and intent modules are compiled once per deployment and reused, not reprocessed on every message. This is the one change that cut cost as well as time.
Streaming responses
The reason first-token time, and not full-answer time, is what a visitor actually feels.
Honest status
What is not live yet.
Named as roadmap, not implied:
What I would do next
- Close the loop on unanswered conversations. Route every "I don't know" into a weekly knowledge-base gap report, so the number that matters most has an owner and a workflow, not just a dashboard tile.
- Ship the autonomy selector. The agent's boldness is fixed per job today; customers in regulated spaces want a dial and an approvals queue behind it.
- A second CRM. The integration layer makes it mostly a config and eval problem rather than a rewrite, which was part of why I chose it.
What I owned
Repositioning and the platform's system-prompt architecture; the guardrail precedence and validation model; the eval suite; onboarding; the latency and cost work; pricing, packaging and the product-led growth motion; the go-to-market source of truth (competitor matrix, ICP, positioning, launch plan); and the CRM integration spec. A cross-functional team of engineering and design, at a pre-Series-A company.
Customer names and anything under NDA are left out. The numbers here are ones I am cleared to share.
Want the long version?
Read the full teardown, or talk to me.
The teardown has the diagrams and the reasoning behind each decision. I am open to senior AI product roles, especially agents and conversational products.