Support that answers itself
Most support questions are not “what” — they are “where do I click”. So this one opens your customer’s own screen and highlights the control, one stop at a time, in your documentation’s words. It answers tickets and live chats from that same documentation, and hands anything it cannot ground to a human rather than guessing. No account to set up elsewhere, no per-seat pricing, and your customers’ data never leaves your server.
$2 of credit free on your first key · pay only for what it generates · cancel by deleting a key
Here is the whole design, in one sentence: your install searches your documentation, reads the customer’s own account, strips everything sensitive, and sends us a finished question. We send back an answer. We are a text-in, text-out service with no connection to your database and no ability to do anything on your behalf.
You are handling other people’s money. We built for that.
Every claim below is something you can check in the addon’s source, because you own it.
Your data stays on your server
Retrieval and account lookups both run inside your own install. The assistant is handed a question and the documentation excerpts your platform already chose for it, and it works from that text alone — your database is simply not part of the request.
Passwords, keys and wallet addresses are stripped
A field denylist runs before anything leaves your box: password hashes, 2FA secrets, API keys, wallet addresses, transaction hashes, KYC documents. Not redacted after the fact — never sent at all.
We do not keep your prompts
A question is held only for as long as it takes to answer it, then erased along with the answer. We keep token counts for billing and a thumbs up or down for quality. Not the conversation.
The assistant holds no authority of its own
It cannot call a tool, read a wallet, or name a user — it has no connection into your install at all. Every action a customer is offered was proposed by your own platform and checked against that customer's permissions before it appeared. A prompt injection in a hostile ticket has nothing to reach for.
The hard part isn’t answering. It’s knowing when not to.
A bot that invents a withdrawal limit costs you more than one that says “let me get someone”. So this one is built to escalate.
It cites, or it escalates
Every answer is checked against the documentation it was given. If the retrieved material does not actually support the answer, the customer gets a human instead of a confident guess.
It refuses the money questions
Withdrawals, KYC decisions, account compromise, anything where a wrong answer costs someone real money — those escalate to a person by rule, before the model is even asked.
A human can take over mid-sentence
An agent replying cancels the generation in flight. The customer never sees two answers, and you are never billed for the one nobody read.
It works the tickets you already have
Triage on arrival, a summary when a ticket reaches a human, a proactive message on a failed deposit — the parts of support that are volume rather than judgement.
It answers in your customer's language
Your documentation is in English and your customers are not. A question written in Spanish, Arabic or Japanese is read, matched against your English knowledge base, and answered in the language it was asked in — with the same refusals applying in every one of them.
The best ticket is the one nobody files
As a customer types a subject line, the article that already answers them is offered inline — no AI call, nothing billed, and the file-anyway button never hidden. It is the only deflection number here that counts tickets that genuinely never happened.
What those six rules look like on one ticket
The chip beside the answer is not decoration. An answer only ships with it once the sentences it makes have been checked back against the passages that were retrieved — and if they cannot be, the same ticket goes to your queue instead, with the conversation already summarised for whoever picks it up.
The dashed note underneath is the other half. Some questions never reach a model at all: they are routed to a person by rule, on the way in.
Most support questions aren’t “what”. They are “where do I click”.
Sending someone to the withdrawal screen is a teleport, not an answer — they arrive at a page full of controls with no idea which one was meant. So it goes with them.
21walkthroughs
one per journey a customer gets stuck in
82stops
each one sentence, in your documentation's words
56named controls
the other 26 open, close, or explain a step off-page
A form that reveals itself one rung at a time used to defeat it
Deposit, withdrawal and verification are progressive: rung two does not exist until rung one is answered. That is the right design for a money screen — a form that asks everything at once lets somebody pick a network that does not match their currency — and it was not going to change to suit a walkthrough.
Measured in a browser: all four stops of the withdrawal walkthrough drew a centred card with no highlight, because the customer had pressed Next four times instead of filling the form in. So a stop that is not on screen yet says why, and what to do about it:
“Choose a currency above and the methods that can pay it out appear here.”
Then the customer acts, the rung renders, and the spotlight snaps onto it. The walkthrough follows the customer through the form rather than racing ahead of them. Seven stops across the deposit and withdrawal walkthroughs carry one of these sentences.
It never types into a form on a customer's behalf
It says which box, and the customer types. That is not a limitation waiting to be lifted — 'put your wallet address here' pointed at the wrong field is a lost deposit, and it would be the assistant's sentence rather than yours. A walkthrough highlights controls somebody is already looking at, on a page their own session already opened.
A guide that your page cannot draw fails the build
A stop names a control by name, never by CSS selector, and a build gate reads both ends off disk: every anchor in the catalogue, and every anchor your pages actually carry. It fails on a missing one — and on a duplicated one, which is the worse failure, because the first match on a page with a hidden desktop copy has no size and paints the spotlight in the corner.
Every walkthrough, by name
Deposits, withdrawals, transaction history, wallets, verification and two-factor on every install — then staking, P2P, investment plans, futures, token sales, referrals, NFTs, the store, copy trading and trading bots wherever you run the addon. The four trading terminals each shipped their own onboarding tour years before this existed; the assistant offers those rather than re-writing a worse second copy of them.
And a page a particular customer’s verification level cannot enter is never offered to them: every walkthrough is pre-flighted through the same check that would run if they pressed it.
It starts the journey. Your server carries it.
A first deposit is not one screen. It is check your wallets, then the deposit form, then confirm it arrived — and the assistant has no part in it after the first step.
19processes
8 of them need no addon installed at all
46steps
23 walkthroughs, 20 navigations, 3 actions
7days
how long a half-finished process stays resumable
Advancement is server-side, and that is the whole security property
When a step completes, your own server writes the next step’s proposal itself. The model is not asked, is not shown the result, and cannot influence what comes next. It opened the sequence; it does not steer it.
Each step is still the customer’s to take, under their own session, and a half-finished process stays resumable for seven days — long enough that a verification that took the weekend does not start again from nothing.
Of the 19, eight need no addon installed at all. Nine are gated on an extension you run and two on a platform setting, so a process for a product you do not sell is never offered, never started, and leaves no row behind.
Three actions. That number is the product, not a gap.
The model may only propose one of a fixed three, and it supplies no value of any kind — it picks a key from a list and nothing else. Your customer’s click is what executes it, through an ordinary authenticated route under their own session, and the proposal expires after 24 hours if nobody presses it. A misread question, or an injected instruction in a hostile ticket, has nothing to address a write with.
Resend the verification email
The single most common ticket on any exchange, and the one where a customer waiting for a human is pure waste.
Withdraw my verification submission
Someone who uploaded the wrong document needs the old one out of the queue before they can replace it.
Mark my notifications as read
Reversible, worthless to an attacker, and the only third one that survived a sweep of roughly forty user-facing mutations.
Two we wanted and did not ship
Sign out my other devices takes no parameters and is correctly scoped — and is still not here, because it is not reversible and the step-up path it would need refuses rather than challenges. Open a P2P dispute needs free text the model would author, which is then persisted and shown to a counterparty. Both are exactly the kind of thing a longer list is made of.
Walkthroughs and processes are on your switches, one at a time
Walkthroughs write nothing at all, so they are on by default and narrow to a list if you want. Anything that can act is off until you turn it on and tick the individual processes you accept — the process list means none when it is empty, deliberately the inverse of the walkthrough list, so an upgrade that adds a process never grants it.
Why actions and processes need our gateway — and walkthroughs never will
Answering never depends on us. An install that has not switched MashDiv AI on still gets the same retrieval, the same grounding gate and all 21 walkthroughs. The 3 actions and the 19 processes built on them are different in kind, and here is exactly why.
The audit trail is double-entry
Every action leaves a row on your install and a job row on the gateway. The invariant — no completed or failed action may have an empty confirmation time — is checkable against both sides at once, so a single corrupted ledger cannot agree with itself.
Spend is bounded by something you cannot edit
A budget ceiling in your own settings table is a number your install can change. The gateway's allowance is not. That difference is what makes a write-capable assistant an accountable one.
The catalogue is versioned centrally
If an action is ever found to be unsafe it is withdrawn for every buyer at once, rather than whenever each of them next upgrades. That is not something an install pointed at a raw API can be given.
An action is the only thing here that writes
What stands behind it is not a model — it is the gateway’s own accounting. Every action lands twice, once on each side, and the two ledgers are reconciled against each other rather than each being trusted alone.
The rule is derived in one place and read by six enforcement points — the tool spec, the tool runner, the process catalogue, the confirm route, the pending-actions reader and the admin console. Restating it at each is how five of them end up agreeing and the sixth becomes the way in.
This is a line along a real seam, not a paywall
The proof is which catalogue is not gated. A walkthrough writes nothing and needs no accounting, so every one of the 21 runs whether or not you ever switch MashDiv AI on — with us earning nothing from it. Withholding them would be a paywall dropped across an arbitrary feature, and we would rather say that out loud than have you find it out.
A support desk is more than the reply
It answers in your customer’s own language and heads off the ticket before it is filed, as above. It also knows your hours, says so, and answers from documentation newer than your install.
It knows when your team is actually there
A proper weekly schedule, per day, with more than one window if you close for lunch — written as plainly as 'mon 09:00-17:00' and 'sat closed', in your own timezone, and correct across a daylight-saving weekend. Off until you say so, because inventing hours is worse than having none, but the shipped schedule is already Monday to Friday, 09:00 to 17:00 — so switching it on is one toggle rather than a syntax lesson.
'Someone will reply' stops being a lie at 02:00
Out of hours, a handover says when the desk is back — today at 14:00, tomorrow at 09:00, Monday at 09:00. That one sentence is the difference between a customer waiting and a customer chasing, opening a second ticket, and complaining they were ignored.
Documentation that is current today, without upgrading
The knowledge that ships with a release is frozen at that release. Your install also asks our live documentation index at answer time and fuses the two by rank, so a page we improved this morning reaches an install built months ago. It is an enhancement and never a dependency: if the feed is slow or unreachable it is dropped after 2.5 seconds and the answer comes from your own index alone.
“Back Monday at 09:00” is a schedule, not a guess
The next-open sentence is computed from your schedule, your timezone and the actual moment the customer wrote — a pure function of the three, which is why it survives a daylight-saving weekend rather than drifting by an hour twice a year. Days can carry more than one window, so closing for lunch is a schedule rather than a workaround.
It reads your settings, deliberately not the assistant persona’s own working hours — the persona is optional, and a desk that only knows its hours when somebody has written a personality for the bot is a desk that does not know its hours.
Multilingual ships off, and that is load-bearing
With it off, behaviour on every existing install is byte-identical to before it existed. With it on, the question is rendered into English on the cheapest tier before retrieval — because your corpus is English and word matching is what finds the passage. It is a safety gate as much as a reach one: the rules that decide a question is about your fees, your limits or your review times read English, so a fee question in Spanish that skipped this step would be answered fluently, in your voice, from numbers that are not yours. A translation failure stops the turn rather than degrading it.
Deflection ships on, because it costs nothing
It is the only new capability here that is on out of the box: no model call, no metering, no budget. It fires once a subject line passes twelve characters and de-duplicates over half an hour, so the number it reports is a count of tickets and not of typing speed. Only your own articles and FAQs can be offered — our shipped documentation cannot appear in your customer's face — and the file-anyway button is never removed or de-emphasised.
Pay for answers, not for seats
Metered per token, drawn from your store wallet. No per-answer fee, no monthly minimum, no contract, and two separate limits so it can never surprise you.
Nothing to set up elsewhere
Standing up a production AI service usually means a separate account and billing before anything works — every hour of which is an hour the feature isn't working. With MashDiv AI there's none of that: create a key here and paste two lines into your .env.
Two limits, not one
A wallet balance and a monthly cap, shown separately — because they run out for different reasons and the fix differs. Your install ships with its own daily and monthly ceilings already set, and zero means unlimited only if you choose it. A reply that has already started is paid for and delivered; the next one waits for headroom.
Cheaper as it learns
Answered questions become documentation. Documentation gets cached. A repeat question can arrive carrying no billable tokens at all, in which case the four-tenths-of-a-cent floor is the entire bill — and you can see exactly what each conversation is costing you.
Three tiers, five efforts, and a ceiling that clamps rather than refuses
A tier is a promise about the job, in both directions. Ask for more deliberation than your tier sells and you get the most it does — your conversation is never failed over a tier difference. Ask for nothing and you get the tier’s own default, which for support answers is deliberately low: short, grounded, fast is what the promise means.
mashdiv-lite
default effort low · ceiling medium
Cheap and fast, and honestly so. It is also where triage, handover summaries and drafts are served whatever tier you bought — see below.
mashdiv-core
default effort low · ceiling high
The answering tier. Support answers are short, grounded and drawn out of documents you supplied; low effort is what that promise means.
mashdiv-max
default effort medium · ceiling max
For desks where an answer is a judgement call. A buyer paying for the top tier is buying deliberation, so its default sits a rung higher.
Half of what an assistant generates is machinery. You should not pay answer rates for it.
Measured on the live gateway across 104 billed generations: 50 were answers and 54 were triage and handover summaries — 52% of everything, and none of it text a customer read. Triage classifies a ticket. A summary compresses a conversation for the human taking over. Neither is a judgement call, so both are served and billed on the cheapest tier whatever you bought. The downgrade moves routing and pricing together, applied at admission, so what you are charged and what ran cannot disagree.
Priced per answer, and the price is pinned
Answers start from about $0.02 on the lightest tier, with a four-tenths-of-a-cent floor on a delivered answer and no floor at all on the triage and summaries around it — you are charged for what your customers actually got. A one-line question bills less than a twenty-turn escalation, because it is less work. The rate card is versioned and the version is stamped onto every usage row, so any invoice can be re-derived line by line from the prices that were in force when the work ran, not from today's.
Your support never depends on it
If MashDiv AI is ever slow or unreachable, your install quietly falls back to your human queue rather than showing your customers an error. It speeds your support up — it’s never a single point of failure for it. Turn it on or off with a switch.
Running in about five minutes
And nothing speaks to a customer until you say so: the addon ships switched off, and switched on it starts in copilot — a human presses Send on every reply until you have seen enough.
- 1
Create a key
From your dashboard, on any active licence. You get a token and a signing secret, shown once. Your trial credit is added at the same moment.
- 2
Paste two lines into your .env
Then enable MashDiv AI in Admin → AI Support and press Test connection. It tells you your balance if it worked.
- 3
Point it at your documentation
The addon indexes your docs locally and builds its own search index. Nothing is uploaded — the index lives on your server, alongside everything else it reads.
- 4
Turn it on for tickets, chat, or both
Copilot is where it starts, so you read its answers before customers do. Promote it to autonomous when you have watched enough of them, and turn on walkthroughs, processes and actions one switch at a time.
Try it on your own tickets
$2 of credit, no card, no commitment — enough to watch it work through a couple of dozen real conversations against your own documentation. That is the only demo worth anything.
Requires an active Bicrypto licence · browse products · questions to support@mashdiv.com