Skip to main content
Dubot sits between a customer request and the product experience. It translates intent into a known set of building blocks, operates through an approved surface, and checks whether the expected result occurred. If you have not read the object model, start there: actions, pages, knowledge, and journeys are grouped into capabilities and given to an agent.

​
Current configuration view

The current Dubot app lets a team configure an agent’s model, reasoning budget, and customer-facing behavior. Capabilities and actions are attached after the agent is created. This is the configuration plane, not a Browserbot execution surface. Agent configuration in the current Dubot application

​
The action loop

1

Receive intent and context

A support AI, agent, or in-product surface passes the customer request and the context needed to act.
2

Resolve to an approved capability

Dubot matches the request to a capability the business has reviewed. If no suitable action or journey exists, it stops or falls back rather than improvise a new write.
3

Check state and policy

Dubot evaluates the current product state, the allowed scope, and any required confirmation before continuing.
4

Do, or fall back to show

When an approved action exists and is reachable, Dubot performs it. When it does not, Browserbot or the contextual sidepanel guides the customer to the right place and shows them the next step.
5

Verify the result

Dubot checks for the expected state change and reports whether the request was completed, needs attention, or could not continue safely.

​
Runtime model

Two ideas shape how Dubot behaves once a request is approved.

Do, falls back to Show

Whether Dubot acts or guides is decided at runtime, not fixed in advance. If the approved action is available it runs; otherwise Dubot navigates the customer to the right screen and shows them the step. The customer is never left at a dead end.

Intent, not selectors

Navigation targets are stored as intent, such as “the settings link in the primary navigation,” and resolved against the live interface at runtime by a fast model, with resolutions cached and retried. This avoids brittle stored selectors that break when a product’s markup changes.
The runtime model describes intended behavior. The contextual sidepanel and runtime knowledge retrieval are in active development.

​
Control model

Dubot is designed around bounded, approved building blocks rather than open-ended control.
Exact runtime, identity, data handling, and audit behavior must be confirmed for each customer environment. This page describes the intended control model, not a universal deployment contract.

​
Current status

Agent configuration, attaching capabilities and actions, knowledge ingestion, Browserbot-based interaction, explicit approval points, and outcome verification can be evaluated with a focused first use case.
The contextual sidepanel, runtime knowledge retrieval, reusable governance controls, and support-platform connection patterns are in active product development.
General availability, a public API, prebuilt connectors, deployment models, and formal compliance claims are not implied by this documentation.