AI Modes

The ARCY SDK exposes a chat assistant that answers questions, highlights UI, and takes action on the user's behalf. There is no mode picker or tab bar — a query router selects Chat, Copilot, or Autopilot per query, from whichever capabilities are enabled in customization.modes. The end user never picks a mode directly.

Every agentic step (a Copilot highlight, an Autopilot pause, a value the SDK needs collected) renders as a block inline inside the chat transcript itself — never as a separate floating, draggable card. The one thing that still lives on the page rather than in the chat bar is the highlight glow applied directly to the live element being pointed at, since the chat bar has no way to glow a button elsewhere on the page.

Modes

Chat

The user asks a question. ARCY answers directly in text, inline in the chat transcript, with an optional link to the relevant in-app page. No element highlighting, navigation, or action occurs — Chat is the answer-only capability.

Chat answers are grounded in your Knowledge Graph (product structure: routes, entities, flows) and, if you've added any, your Chat Sources: documents and links you upload from the dashboard so Chat can answer questions your Knowledge Graph doesn't cover, such as pricing details or help-center content. See Chat Sources for how to add them.

Copilot mode

The user asks how to do something. ARCY generates an ordered, step-by-step walkthrough that highlights real UI elements on the page. Each step renders as a block in the chat transcript showing the step's title and description, a step counter (e.g., 2 / 5), and Back/Next (or Done, on the last step) controls.

The user moves through steps at their own pace. When a step specifies a target element, that element receives a pulsing glow highlight and is scrolled into view automatically if off-screen. The highlight follows pointer events through to the element so the user can interact with it normally. If the element cannot be found (e.g. it was removed), the step still displays in the chat transcript without a highlight.

Content-aware highlighting

When a Copilot step targets an element that repeats across rows (e.g. a delete button on every table row), the SDK uses content matching to find the correct row: the row gets a subtle background highlight first, then the action element within it gets the standard pulsing glow. If the match fails (row not found or ambiguous), it falls back to standard anchor-only highlighting.

This is the same mechanism that powers the destructive action fallback: when a user asks Autopilot mode to delete a specific item, ARCY responds with a Copilot walkthrough that highlights the correct row and its delete button so the user can perform the action themselves.

Cross-route persistence

Step state (current step index) is persisted to sessionStorage alongside other SDK UI state. When a Copilot step triggers a route change that causes a full page reload, the walkthrough resumes at the persisted step after the page loads, and the chat bar reopens with it.

In Copilot mode, the chat bar can only be resized horizontally. Vertical resize is disabled.

Autopilot mode

The user tells ARCY what to do. ARCY creates an action plan and executes the steps on the user's behalf using the constrained action model (click, focus, fill, navigate). No arbitrary DOM manipulation occurs.

While ARCY is planning, a toast notification appears at the bottom-right of the screen with a loading indicator. When planning finishes, ARCY shows the full plan in the chat panel for review before anything runs. The user can approve or cancel.

Once approved, Autopilot always runs straight through the plan step-to-step, showing live progress ("N of M steps done") in the chat transcript — there is no per-step confirmation toggle. The only things that pause it are a step that highlights an element for the user (Copilot-style, see above), a step that needs a value collected from the user, and the unconditional safety pauses below. None of those pauses skip a safety check; they only stop the straight-through run at exactly the point the user's attention is needed.

When all steps finish, a success toast confirms completion and auto-dismisses after 4 seconds. If a step fails, an error toast appears and the user can dismiss it to reset the autopilot state. Step state is preserved across page navigations so multi-page plans continue correctly after a route change.

Step-level confirmations (Human in the Loop)

Certain steps pause automatically and require explicit confirmation before ARCY proceeds. This happens when:

• The action cannot be undone. ARCY shows "This action cannot be undone" and requires the user to click Confirm.
• The step was marked for confirmation by the AI. For consequential but reversible actions such as submitting a form, sending an invite, or publishing content, ARCY shows "This step requires your confirmation." The user must click Confirm to proceed.
• The target element cannot be found. ARCY shows "Could not find this element." The user can allow the attempt anyway or skip the step.
• The target element is currently unavailable. ARCY shows "This element is currently unavailable" (for example, a button that is disabled or obscured). The user can allow the attempt or skip.
• The target is behind a shadow DOM or iframe boundary. ARCY cannot reach elements inside either, and says so explicitly rather than reporting a generic "not found."
• Multiple matching elements were found and none can be told apart. ARCY shows "Multiple matches found" rather than guessing which one the user meant.

In every case, the user can cancel the entire plan using the close button on the step block. Steps that require confirmation show a Confirm button instead of Allow; steps where skipping is meaningful show both Confirm and Skip. Closing the chat bar itself is blocked with a confirmation prompt while any step is running or paused this way — the same guard, not a bespoke check per pause reason.

In Autopilot mode, the chat bar can only be resized horizontally. Vertical resize is disabled.

How Autopilot finds elements to act on

Autopilot targets elements by fingerprint, resolved at runtime from real usage, not from an attribute you add to your source code. There is no manual instrumentation step. See Element Targeting for the full mechanism.

An element only becomes eligible for Autopilot to act on unsupervised once it has either accumulated enough real-usage confidence or been explicitly confirmed by a dashboard admin through the visual tagger. Below that bar, Autopilot pauses with pauseReason: "confirmation_required" and asks the user instead of guessing. Elements that repeat in identical structure (a delete button on every table row) with nothing to tell them apart are never eligible for unsupervised action, regardless of how many times they've been seen.

Interaction history

The ARCY settings panel includes a History section that lists recent interactions across all three capabilities. Each entry shows:

• The capability used (Chat, Copilot, or Autopilot)
• The first message or query the user sent
• How long ago the interaction started

History is stored in localStorage and persists across page reloads within the same browser. It is scoped to this browser only and is never sent to ARCY servers. Users can clear the full history from the settings panel at any time.

Every interaction is recorded on the query that starts it, regardless of which capability the router selected.

Supported action types

Autopilot mode executes these action types only. No other DOM operations are performed.

Destructive actions (delete, remove, drop) are never included in autopilot plans. If a user asks for a destructive action, ARCY responds with a Copilot walkthrough instead.