Skip to main content

​
Keep the support stack. Add an action layer.

Dubot is designed to work alongside the tools a CX team already uses. The support platform remains the place where a request is understood. Dubot becomes relevant when resolving that request requires controlled work inside the product. Example support entry points connecting through Dubot to the product

Support platforms

Systems such as Zendesk, Intercom, Salesforce, or a custom support experience can be evaluated as conversational entry points.

Support AI

An AI assistant can identify an eligible action and hand off the context required to begin a reviewed journey.

Your product

Browserbot and the sidepanel help complete the work in the product where the source-of-truth state already lives.
The names above describe the integration category and evaluation targets. They do not claim that prebuilt connectors are generally available.

​
How actions relate to your product

Dubot adds an action layer, not a new backend. A few properties keep the integration surface small.
  • Configuration, not new code. Actions are defined against the APIs your product already exposes. Dubot does not add new API endpoints.
  • Your writes ship from your code. Anything that changes state in the product runs from your own codebase, shipped by your team, not from Dubot.
  • It runs where the SDK already is. The action layer operates inside the SDK you install, so there is no separate service for your team to stand up and deploy.
  • Reviewable before it runs. Every action is inspectable, in the Actions interface or over MCP, before it is attached to an agent.

Manage Dubot over MCP

Connect an authorized AI client to inspect workspace configuration, prepare Test changes, review dependencies, and publish approved configuration.

​
The integration contract

A first integration should stay intentionally small. The exact mechanism depends on the support system and product environment, but the contract needs to answer five questions.

​
A typical handoff

​
What we do not need on day one

A useful first release should not require a broad API program, a complete workflow catalog, or a production-wide rollout. We begin with one valuable request and the narrowest connection that can test it safely.