Most website chatbots will answer anything. That's the problem. A revenue agent that invents a price or a policy is worse than no agent at all.
I built Sadyr to do the opposite: it answers pre-sales questions from approved sources only, qualifies the visitor, and hands a sales rep a briefed lead. It supports the rep — it doesn't stand in for one. The platform is live; it has run in production since 30 June 2026. Two working demonstrations are running for prospects: a plan explainer for an insurance provider and a rulebook assistant for a national amateur sports league's managers. Nobody pays for it yet.
Why it exists
The principle behind Sadyr is simple: own the center; wrap, rent, or swap the edges. A small kernel owns the business logic — qualification, routing, scoring, policy, audit. The CRM, the scheduler, the chat channel and the knowledge store sit behind adapters, each with a mock. HubSpot is the first adapter, not the spine. Each client is one configuration file.
That architecture is why one platform can serve both demonstrations. The public insurance explainer and the gated managers' assistant differ only by configuration. Documents carry an audience, surfaces carry a policy, and public surfaces decline cleanly on manager-only content. The insurance demo runs on 95 approved documents synced one-way from a knowledge base; the league demo holds 98 real rulebook documents, with nine tagged for managers only. The managers surface answered real ruling questions from manager-only content with titled sources; the public surfaces abstained, with no manager-only content leaking across the boundary.
Standing up the second, sign-in-gated audience did not require a second platform or a fork of the codebase. It required a data model change — an audience field on each document — and a configuration block: surfaces per client. If a knowledge platform needs a schema change and a new codebase every time an audience is added, the platform boundary is in the wrong place. The audience control belongs on the document, not on the deployment.
Both demonstrations run on the same production API process, through what I call the chat fleet: every active client's visitor chat is mounted at its own path in one process, with tenant isolation verified live. One client's widget answers only from its own knowledge base and abstains on another client's questions.
Blueprint to production in twelve days
First commit 18 June 2026, live 30 June, 63 commits on eight working days. Day one was the blueprint, the scaffold and the first sprints. The agent writes the code, tests and documentation; I direct, decide and validate. It's three apps — API, operator console, website widget — and 17 packages. The platform carries 2,816 automated tests, a figure recorded from the architecture documentation and not re-run for this article.
Tests run on mocks by default, so I also built a headless evaluation battery that pressure-tests the hosted agent with realistic conversations. The battery runs real embeddings and real retrieval against the live knowledge base, checking every abstention and every citation.
What broke and how I fixed it
The answer gate that divided by word count. Sadyr decides whether it's confident enough to answer by checking a retrieval confidence score against a threshold. The gate divided the best retrieval score by the number of words in the question. Against the mock adapter, which returned a raw count of matched words, that looked right, and every test passed. With real embeddings, real scores around 0.4 to 0.6 became 0.03 to 0.05, under the 0.62 threshold, and every multi-word question abstained. Found on the first live run; fixed the same day, 15 lines added, 6 removed.
The booking that wasn't. My first chat on staging got a confident "You're booked" with no email, no calendar and no choice of time. The rule since: a scheduler that isn't real never confirms a meeting, and nobody gets booked without leaving an email. Booking now runs through HubSpot Meetings and offers real open slots in production; the first real booking is still waiting on a CRM permission fix, so it is not called live yet.
How it fits Adroit
Adroit is a growth partner for businesses competing against bigger money — not the biggest company in its category, but the one that has to be smarter than the organizations outspending it, because outspending isn't on the table. Sadyr is part of the method stack: revenue operations, delivered with frontier precision at boutique cost. The agent compresses time — twelve days from blueprint to production — not headcount.
The multiplier is what makes the economics work. I run my own company on the systems I sell. Sadyr answers visitors on Adroit's live site from Adroit's own approved knowledge base, published from Content Ops. The widget has been answering on adroitmktg.com since 23 September 2026.
Outperform. Don't outspend.
What's next
The booking fix is in flight; once it clears, the first real meeting will land in my calendar and booking moves to live. After that, the first paying client. The platform is ready; the demonstrations prove it works; the next milestone is sold.
If you're building with agents or thinking about it, DMs are open.