> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dubot.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# How Dubot learns a product

> Record workflows and turn captured calls into reviewed candidate actions

Before Dubot can act inside a product, it needs to know what the product can do. That knowledge comes from three inputs, each with a different level of maturity today.

<CardGroup cols={3}>
  <Card title="Ingest" icon="globe">
    A backend crawl of a public help center. No login required. Produces the knowledge corpus.
  </Card>

  <Card title="Crawl" icon="radar">
    An in-development browser pass explores the logged-in product and produces candidate actions, page summaries, and brand styles.
  </Card>

  <Card title="Record" icon="circle-dot">
    A person uses the product normally while the browser extension records the calls triggered by the workflow. Dubot turns the captured calls into candidate actions for review.
  </Card>
</CardGroup>

## What each input produces

| Input  | Requires login | Produces                                        | Status          |
| ------ | -------------- | ----------------------------------------------- | --------------- |
| Ingest | No             | Knowledge corpus                                | Available today |
| Crawl  | Yes            | Candidate actions, page summaries, brand styles | In development  |
| Record | Yes            | Candidate actions from a recorded workflow      | Available today |

<Note>
  Recording works before any SDK is installed. The extension observes calls
  made during normal, logged-in product use; it does not add those calls to the
  action catalog automatically.
</Note>

## Record, review, and add

<Steps>
  <Step title="Record a real workflow">
    Start recording in the extension, then use the product normally. The
    extension captures the calls triggered by the workflow so the recording
    reflects the product's actual behavior.
  </Step>

  <Step title="Review discovered calls">
    Finish the recording and inspect the candidate actions Dubot found. Choose
    the calls that represent useful product operations rather than adding every
    request indiscriminately.
  </Step>

  <Step title="Define the action contract">
    Review the method and endpoint, correct the description and assumptions,
    decide which inputs come from product context or the conversation, and
    choose which response data an agent can use.
  </Step>

  <Step title="Set the runtime policy">
    Decide whether the action can run automatically, requires confirmation, or
    must not be available to an agent. Add it to the catalog only after that
    review is complete.
  </Step>
</Steps>

Nothing captured is used blindly. A recorded call remains a candidate until a
person reviews its contract and explicitly adds it to the action catalog.

```text theme={null}
record a workflow
  -> capture the calls it triggers
    -> discover candidate actions
      -> review inputs, outputs, and runtime policy
        -> add approved actions to the catalog
```

<Warning>
  Recording does not make an action agent-callable by itself. A person must
  review and approve each candidate before it becomes part of an agent
  experience.
</Warning>

## Why not just record selectors

Recording learns from the product calls behind a workflow rather than relying
only on selectors for visible controls. The reviewed action contract describes
the operation an agent can use, while navigation is resolved separately at
runtime. See [How Dubot works](/concepts/how-dubot-works) for the runtime model.