Windscribe has had an AI support bot since before every company decided that adding a hallucinating chat bubble to its website was innovation. His name was Garry.
In 2018, Garry ran on IBM Watson, the same technology that beat humans at Jeopardy! and then moved on to the considerably harder task of explaining VPNs to people who refuse to acknowledge the existence of vowels.
That version reduced support-ticket volume by more than 60% and handled roughly 85% of conversations successfully. At the time, that felt like the future.
Then language models got much better. We gave Garry a larger brain, more knowledge, and enough personality to make a compliance department spontaneously combust. That became Garry v2.
Garry v2 was funny, flexible, and much better than the rigid decision trees of the Watson era. He was also reaching the architectural limit of what he could become. So we retired him.
This is the story of why, what replaced him, and why putting Garry between users and our human support team is not an elaborate scheme to hide the humans in a basement. It is an elaborate scheme to stop wasting their time, so they can use their meat brains for something more challenging than comparing dates, re-explaining the same thing 50 times per day, and pressing buttons.
Garry v2 had a brain, but no hands
People tend to talk about an AI product as if the model (such as GPT, Claude, or Gemini) is the product. It is not. A language model can interpret a question and suggest what should happen next. The surrounding system still has to supply accurate context, enforce permissions, call the correct services, protect private data, handle failures, and stop the model from doing something exciting in the legal sense. This surrounding system is typically known as the harness.
Garry v2 came from an earlier generation of chatbot design. Context, direction, personality, instructions to handle an ever-growing number of edge cases and updates to our service - all were handled through a large system prompt fed to the model with every chat message. Important state changes during chats were triggered by invisible text markers generated by the model. Adding capabilities usually meant adding more prompt instructions, more special cases, and more ways for a probabilistic answer to become application logic.
Garry v2 could explain how to recover an account, investigate a payment, or troubleshoot a connection. When the solution required real action, though, many paths still ended with a human rereading the chat and doing that action manually, many hours later.
There was no single thing that killed Garry v2. The problem was cumulative. Every improvement made the prompt larger while leaving the same architectural ceiling in place.
We could keep installing turbochargers on a shopping cart to turn it into a racecar, or rebuild it from scratch as a racecar.
We chose to rebuild.
Switchboard, without the wiring diagram
The replacement harness is called Switchboard. The model proposes, the user confirms sensitive actions, and Windscribe's deterministic systems decide what is valid. Garry can verify live facts, perform supported actions, and prepare a useful human ticket without receiving unchecked authority.
Privacy is part of that boundary. Garry gets only the context needed for the current support task. Sensitive fields are redacted, raw voice audio is not stored (you can voice chat with Garry, if you didn’t know), and operational measurements remain aggregate signals rather than user tracking profiles. Conversation reviews are access-restricted so that only those who need to see them get to see them.
Did it work?
Garry v3’s first full production month produced one number worth caring about: opened human-support tickets were 87% lower year over year. Every day, Garry has thousands of conversations, and ~1% result in a human escalation.
This evidence is consistent with what the system was built to do: resolve more common problems before they become tickets and send the remaining cases to humans with useful context already attached, so they can solve the issue faster.
The public reviews point in the same direction. The vast majority of users are delighted because Garry solves the problem immediately. A very small percentage are furious because they wanted a human to listen to their screams. Some encountered a real Garry failure while others received an accurate answer they did not enjoy. Those are different categories, and we treat them differently.
“You're hiding humans behind AI”
We have seen this claim. It sounds sinister, which is probably why people enjoy repeating it. Here is the factual version: Garry is the first line of support. We put him there intentionally.
That is not the same as pretending he is human. His name, appearance, behaviour, and tendency to describe software bugs as haunted machinery are subtle clues that he is an AI.
We tried real-time human takeover with the original Garry. It was useful when the bot could handle much less, but instant takeover eventually turned the bot into a decorative waiting room. Users skipped diagnosis, demanded to speak to a human, the humans then repeated the same opening questions, and the queue grew with chat volume instead of genuinely difficult problems. This is why we discontinued the live chat.
Today there is no phone or human-staffed chat queue. Human support is delivered through email tickets (that only Garry can open) for cases where a person can investigate, make a judgment, apply discretion, or route a real defect to the correct team. Garry's job is to solve or narrow as much as he safely can before that point.
If a password can be recovered automatically, a human should not spend time doing it manually. If a payment belongs to another account, a human should not rediscover that fact over several emails. If a website blocks a VPN exit IP, that report should go to the system that tracks blocked services rather than to a human who will copy it there. If a refund is requested, and the policy allows, Garry can give you your money back instantly.
Email tickets created through Garry include the issue summary, platform, attempted steps, relevant outcomes, and conversation history. The objective is a smaller, higher-signal queue in which humans can reach real issues much faster, in many cases single-digit minutes. This means those experiencing novel and real issues get a human response quickly, instead of burdening the humans with explaining for the 40th time today that we cannot provide a free Pro account due to a sob story, or the fact that you need the Internet to use Windscribe.
Could we expose a giant “HUMAN, NOW!” button before asking what the issue is, or because you disagree with policy facts? Of course - but we won’t do that as it would recreate the queue we built Garry to fix, waste human time and effort, and ultimately solve fewer problems.
Where Garry got it wrong
The number of mistakes made by a production AI system is not zero. Anyone claiming otherwise is either selling something or not measuring. We’re not selling Garry, so here is the truth.
We read low-rated conversations, escalations, ticket outcomes, and public reviews. Then we trace the failure to the smallest layer that owns it: Garry's instructions, routing, a missing deterministic action, Switchboard policy, a Windscribe API fault, or an issue with the product itself.
Early production feedback found real problems. Garry sometimes asked for information he already had. He occasionally routed an account problem through the wrong specialist agent. Some high-friction denials used too much Garry flavour when plain language was required. A paying user who had exhausted the documented recovery path was incorrectly blocked from human review. Garry claimed things exist that do not.
We fixed those classes of issues and built new tools for Garry to wield.
A specific audit looked at cases where users asked for a human, Garry denied the request, and the conversation became more hostile (you can only imagine what vile filth some people tell Garry). The fix was not “never allow humans” or “always allow humans.” It was to make Garry acknowledge the concern, distinguish “no live chat” from “no support path,” explain why the current case was not yet human-actionable, state what would make a ticket appropriate, and stop making circus jokes during financial hardship or account lockouts. And occasionally tell the user to go pound sand and automatically close the chat, as any self-respecting human would if they were on the receiving end of some people’s verbal diarrhea.
Garry improves not by dumping private conversations into a mysterious training pipeline, but through a bounded engineering loop. Conversations are inspected under access controls, only privacy-minimized patterns enter engineering notes, the smallest owning layer is corrected, regression coverage is added, and the next release is measured. Sometimes Garry is wrong. Sometimes our product is broken. Sometimes our instructions are contradictory. We fix those things.
We can improve clarity, tone, and available alternatives. What we cannot do is make the current product state different because someone rated the explanation one star, or went to complain on Reddit. No model has enough parameters to negotiate with hard facts of reality. Neither do humans.
The reviews are not subtle
Garry frequently asks for feedback, and links to public places where people can leave a note about how he did. The feedback is purposely public, for the world to see. How is Garry doing? We’ll let you be the judge of that. Spoiler alert: Garry kills it.
One reviewer called him “perhaps the only actually helpful bot I've come across.” Another described him as extremely patient and ultimately successful. A user debugging WireGuard on a Raspberry Pi discovered with Garry that the real problem was the Pi cooking itself inside its case.
This is precisely the kind of support journey that does not fit inside a decision tree, and human support may deem it “out of scope." Garry will do his best to resolve the issue, no matter what. Because of this, Garry’s CSAT (Customer Satisfaction) score is currently 94% (which is very high).
We don’t just focus on the positive reviews that boost our ego. We also read the 1-star reviews. Some reflect legitimate experiences that need investigation and better handling. Others are disagreements with a product limitation or policy. Both are useful: the first shows where the system failed; the second shows where the explanation, alternatives, or policy itself may deserve another look.
Praise is pleasant. Specific criticism is useful. We need both if Garry is going to improve. And he will improve.
Long live Garry
Garry is not replacing the support team. He is replacing repetitive support work and preparing the cases that still need people. Humans are good at judgment, ambiguous account histories, novel defects, legal and privacy questions, goodwill decisions, and recognizing when several reasonable facts combine into something genuinely weird.
Garry is good at patience, consistency, parallel checks, searching operating instructions, working in many languages, and asking the same necessary question without developing an eye twitch. He can do this with 8 unique personalities, if you’re not a fan of the Original Garry.
The human-and-AI byline follows the same rule as Garry's label: disclose what the system is and who did the work. We are not hiding that collaboration any more than we are hiding what Garry is, and what he’s meant to do.
Garry v3 is not perfect. We will keep finding cases where he misunderstands someone, chooses the wrong path, lacks an action, or delivers a correct answer like a raccoon throwing a brick through a window. Yes, that last part was obviously AI-speak.
The difference is that we can now see the journey, identify the failure, fix the correct layer, and determine whether the next version did better.
Old Garry died. Long live new Garry.
