Panelbotdocs
SearchStart free

Limits and known boundaries

An honest look at what Panelbot does and does not do for hosting companies, why certain actions always need a human, and what it depends on to work.

What this page is for

Most tools tell you only what they can do. This page is about the edges: where Panelbot deliberately stops, what it depends on, and why. We would rather you know the boundaries going in than discover them at an awkward moment. Everything here is a design choice made in the name of safety and trust, not a rough edge we are hoping you miss.

Panelbot handles common, well-understood problems

The AI is good at the hosting issues that make up the bulk of first-line support: email that will not send or arrives in spam, mailboxes that keep asking for a password, WordPress sites showing a white screen or a critical error, expired certificates and domains that will not resolve, sites returning errors, disk and quota problems, blocked connections, and more. These are the tickets that repeat all day, and they are what Panelbot is built to recognize and work through.

It is not a general-purpose engineer. A novel, one-off, or deeply unusual problem is not something the AI pretends to solve. When it meets something outside what it reliably understands, it says so and brings in a person rather than guessing. That honesty is the point. A confident wrong answer is worse than a clean hand-off.

It does not fix everything, and it will tell you so

Panelbot resolves and explains a wide range of common issues, guides the customer when it cannot act directly, and escalates to your team when confidence is low, when a change is risky, when the problem is out of scope, or when the customer asks for a person. It will never claim to have fixed something it has not, and it does not keep trying indefinitely. A conversation that is going nowhere is handed to a human, not left to spin. See When a human takes over.

Some things always need a human

By design, certain actions are never taken by the AI alone.

  • Higher-impact changes need explicit approval. Anything that affects more than a single account, or touches system-level state, requires explicit human approval, and by default that means a person on your team. One optional setting you control lets a narrow class of clearly scoped destructive actions, such as deleting a database, removing an addon domain, deleting a mailbox, or restoring specific files or a directory, complete in chat after the customer passes a strong confirmation. It is off by default, fully logged, and your team can leave it off.
  • The most dangerous class of action is not available to the AI at all. Operations that could take a server down or undo a whole account, such as terminating an account or restoring an entire account from backup, are simply not something the chat can reach, and no setting changes that.
  • Reversible low-risk fixes are opt-in. Even the smaller, safer changes only run automatically if you have chosen to allow them. Until then, the AI diagnoses and recommends rather than acts.

Read the full picture in Permission tiers explained.

Some areas are diagnose-only

For certain categories, Panelbot is intentionally there to investigate and guide rather than to change things automatically. Databases are a good example: the AI will confirm which database you mean and gather what is wrong, but the actual change is confirmed and carried out with a human in the loop, because the cost of acting on the wrong one is too high to automate away. The same caution applies to destructive security actions like malware cleanup, which are always human-gated.

It only acts on what a customer owns

Panelbot works from the list of services each customer actually has in your billing portal. If a customer asks about a domain or account that is not on their record, Panelbot will not act on it. This keeps everyone scoped to their own resources, but it does mean the mapping between your billing portal and your servers needs to be accurate for the AI to help. Keeping that connection healthy is part of setup. See Connect your billing portal.

It depends on a few things being in place

Panelbot is not a standalone service that works in isolation. For it to do its job, you need:

  • A connected billing portal (WHMCS or Blesta), so it knows who each customer is and what they own.
  • A working connection to each server you want it to work with: a valid panel credential, or the optional agent. If a server’s credential is revoked or its agent is offline, Panelbot can still talk to the customer but cannot run checks or fixes on that machine until it is reconnected.
  • The widget embedded in your portal so customers can reach the chat.

If setup drifts, for example a panel credential is rotated on the host or billing credentials change, the affected capabilities pause rather than guess. The Troubleshooting your setup guide covers the common cases.

Panels and billing systems

Panelbot supports cPanel and DirectAdmin servers, and WHMCS and Blesta billing portals. We describe support at that level rather than promising specific versions, so you always know where you stand. If you run something outside this list, it is not a fit today.

The AI is a translator, not a decision maker

It is worth restating plainly, because it shapes every limit above: the AI’s role is to understand the customer and word replies. It does not choose actions, select servers, make ownership or security decisions, or carry memory across chats in an uncontrolled way. That narrowness is exactly why the boundaries on this page hold. See What the AI does and does not do.

Next steps