Skip to main content

End to end with the extension

The extension route suits an application you cannot or will not change: a SaaS your team lives in, an internal tool nobody wants to redeploy, or your own app before you are ready to embed anything. The page stays as it is; the assistant arrives with the user.

Budget about an hour. Where the widget tutorial asks you to add code, this one asks you to configure.

What you need: an Appilot account (the beta is by invitation, so request one at appilot.space), Chrome, and an application reachable at a hostname you can register.

1. Account and organization​

Sign in at app.appilot.space. Create an organization if you have none; you become its administrator and it starts with trial credits.

Every person who will use the assistant on this application needs an active membership in this organization. Invite them from the Backoffice under Organization Users, or hand them a join code and approve their request. An account with no membership signs in and gets refused on the first turn, so do this before you hand out the extension.

2. Install the extension​

  1. Download the ZIP from appilot.space/downloads.
  2. Unpack it into a folder you will keep. Chrome loads it from there on every start.
  3. Open chrome://extensions, turn on Developer mode, choose Load unpacked, and pick the folder.
  4. Open the panel and sign in. The extension sends you to My Account, you sign in there with whatever your account uses, and you confirm the handoff. The session comes back to the extension.

There is no Chrome Web Store listing during the closed beta and no auto-update. Full detail in The extension for your app.

3. Register the hostname​

Open any page of the target application and look at the panel. On a hostname nobody registered, it says the assistant is in live page mode: the turn runs, it is grounded in the page and your organization's knowledge, and none of your app configuration applies.

To change that, register the hostname:

  1. In the Backoffice, create an app for this application.
  2. Add its hostname as a domain: tools.acme.com, or myapp.lvh.me while you develop locally. Register the hostname alone, without the port and without a path.
  3. Reload the target page. The panel now names your app.

Two rules to know before you plan around a hostname:

  • A hostname belongs to exactly one organization. On a shared SaaS host, the first organization to register it holds it.
  • Verification is not needed here. The extension serves an unverified domain. The TXT record gates the live widget key and the site adapter, which is what makes this route workable on a hostname you do not control. See Verify your domain.

4. Teach it the application​

The extension reads the page, so it can already see forms and buttons. What it cannot infer is your meaning: which screen is which, what a field is for, what the procedure actually is.

Author, in this order:

  1. Views, so the assistant knows which screen the user is on. Prefer a URL rule where the URL changes between screens; use a DOM rule only for screens that share a URL. See Managing views.
  2. Knowledge, scoped to those views. Meaning, rules, terminology. Not step-by-step procedures.
  3. Controls, the elements the assistant can point at or operate, and the forms that compose them.
  4. Action plans, the executable procedures. A plan is where steps belong; a step-by-step knowledge article competes with the plan and teaches the agent to invent steps instead of adopting yours.

The fastest way to author controls is from the page itself. Grant a member the domain-editor role and they can register controls, forms and zones through the extension's Editor tab, with the real element in front of them. Organization administrators are editors on every domain already. See Domain editors.

Or say it to a connected MCP client:

Read this app's config, then author the views for the ticket list, the ticket detail and the new-ticket form, with a knowledge article on our escalation rules.

5. If you can add code to the page​

You do not have to, and if you cannot, skip this. But two small additions make the extension considerably better on an app you own:

Declare the view instead of leaving it to detection:

window.__appilot = { view: 'tickets/detail' };
// on SPA navigation:
window.dispatchEvent(new CustomEvent('appilot:viewchange', {
  detail: { view: 'tickets/detail' },
}));

Register client actions so the assistant can act through your own code rather than through the DOM:

import { registerTool } from 'appilot';

registerTool({
  name: 'open_ticket',
  description: 'Open a ticket by number.',
  inputSchema: { type: 'object', properties: { number: { type: 'string' } } },
  annotations: { readOnlyHint: true },
  execute: ({ number }) => { router.push(`/tickets/${number}`); },
});

Both work under the extension with no widget in the page. See View sync and Client actions.

6. Iterate​

The extension re-reads the domain and the app configuration on every page load and the content model on every turn, so the loop is short:

  1. Change the configuration.
  2. Reload the target page.
  3. Ask.

Nothing to clear, nothing to redeploy. Reloading the extension itself is only needed when the extension build changes.

When an answer is wrong, open the turn in the Backoffice under AI Interactions. It shows what the assistant was given: which view was detected, which knowledge was in scope, which tools were offered, and what was dropped.

7. Roll it out​

  1. Invite the people who will use it and approve their memberships.
  2. Hand them the ZIP and the four install steps, or arrange a policy rollout with us. See Enterprise deployment.
  3. Export the configuration and keep it in git as a manifest, so the app can be rebuilt or cloned into another environment. See Config backups.
  4. Watch the requests queue. Questions the assistant could not answer arrive there as gaps worth filling.