Skip to main content

How the assistant answers

The agent runtime​

Appilot routes each user message through an AI agent that reasons about your question, consults the knowledge it has, and decides what to do.

1. Bootstrap​

Appilot detects the current webpage, identifies interactive elements, and pre-loads the most relevant knowledge entries for the view you are on.

2. Agent loop​

A single AI model runs a short, transparent tool-use loop:

  • It reads from your knowledge base (search_kb, get_kb_doc).
  • It looks up forms, controls and tools that the admin has authored for the page (list_forms, get_form, list_controls_for_view, get_control).
  • When needed, it inspects the live DOM through a Web-MCP-aligned tool set (get_page_outline, find_elements, inspect_element, read_form_state, get_visible_text, wait_for).
  • It can look up what the user saved about themselves in My Context (search_user_context), scoped to that user and to nobody else.
  • It can iterate, calling several tools in sequence, until it has enough information to answer.

Every one of those readers consults the same rule about credential fields, so a password, a one-time code, a payment-card field or a hidden field comes back as present and filled, never as a value. read_form_state is the one that matters most here: its own description tells the model to call it before asking the user what they have filled in, and it used to return input[type=password].value verbatim.

You see the loop's progress in real time: the response panel shows which tools the agent is calling, plus a short "thinking" trail.

3. Answer​

The agent finalises by writing its answer as plain text, which streams to you token-by-token. The response mode, the citations, and (when applicable) the executable action plan are attached automatically: the plan is proposed through an emit_plan step before the closing text, and citations / source links / page-region pointers are derived from lightweight markers in the prose and rendered as pills below the answer.

Response modes​

The server derives one mode per turn from recorded provenance. It does not verify every sentence, a particular passage, or every step in a mixed plan.

  • 🟢 Verified action: steps anchored in your control registry, or one of your tools that ran and returned data
  • 🟡 From documentation: an answer that cites a knowledge-base entry it used. Documentation being loaded does not earn this; a resolved citation does
  • 🔵 Based on this page: a successful page observation, steps anchored to elements found on it this turn, or an answer that points the reader at one of those elements
  • 🟠 Best guess: no authored anchor, resolved citation or successful page observation was recorded. Review before acting
  • 🔴 Not enough info: honest "I don't know". Escalate or refine your question

A single citation can earn the documentation badge for the whole answer. Green can come from one authored step in a mixed plan or a successful tool with no plan card. The badge identifies evidence to review; it is not a confidence score. Backoffice qualifies older records without a recognized rule version and distinguishes interrupted turns from completed answers.

Privacy & data​

  • Structured personal data in a message (emails, phone numbers, card numbers, street addresses) is masked before it reaches a third-party provider. What the user pinned in My Context is sent on purpose, because that is the feature.
  • Credential fields are never read or written, by any tool, on either surface.
  • Your organization chooses the provider, including a model on its own infrastructure, which is the only configuration where prompts do not leave your premises.
  • Conversation history belongs to the user and to the administrators of the organization it was recorded under. It is not shared beyond that.