Your app in ChatGPT and Claude
Two Appilot connectors put your app inside the assistants your team and your users already pay for. They do opposite jobs, and it is worth being clear about which is which before you turn either on.
| Connector | Who uses it | What it does |
|---|---|---|
| Appilot Studio | Your developers and configurators | Audits, writes and validates your app's Appilot configuration by conversation. Never touches a live page. |
| Appilot | The people who use your app | Reads and operates your app in their own browser, in their own session. Never writes configuration. |
Why this matters commercially
Your app's AI behaviour stops running on your release calendar.
A procedure changed on Monday, a rule your support team keeps repeating, a form field nobody understands: fixing any of those in code means a ticket, a review and a deployment. Through Studio it is a conversation, and it is live for every user immediately. Your app keeps its own release cycle; the AI layer gets a faster one.
On the other side, your users bring their own assistant subscription. They get Appilot inside a product they already have open, and you did not pay for the reasoning.
Appilot Studio, for the people who configure
Studio is how a developer or a configurator works on your content model without opening the Backoffice. It reads the live configuration, reports what is wrong with it in ranked order, writes the fix once you approve a diff, and validates the result against the same health rules the platform enforces.
The practical effect is that configuring an app becomes an afternoon of conversation instead of a project. See Configure with AI for the full procedure.
A Studio connection carries a service token with explicit scopes. Reading needs
config:read, writing needs config:write, provisioning needs
provision:write. Give a person the narrowest one that lets them do their job,
and revoke it when they are done.
Appilot, for the people who use your app
Your users add the Appilot connector to ChatGPT or Claude, sign in with their own Appilot account, and share the tab your app is open in. From then on they can ask their assistant to find things, explain the page, walk them through a procedure, or fill a form, and it happens on the real page in front of them.
Everything runs in their own session. The connector cannot exceed what the person could do by hand, there is no service account, and your app's authorization is unchanged.
The guardrails your configuration already carries apply without exception: credential fields stay closed, a plan that would submit an empty form has the submit dropped, values are typed into the field for the person to check, and the person presses the button that commits.
Configuration quality decides what is exposed
This is the part to plan for.
Appilot works on any web app, including yours before you configure it. Without a configuration it reads the page, finds and highlights elements, and assembles plans anchored to what is on screen, and it tells the person the guidance is inferred from the screen.
Your curated surface is different. Action plans, knowledge, tools and control descriptions are served to an outside assistant only while your configuration passes the health contract with no critical or high findings. A half-configured app is not exposed half way.
That gate protects you. A partial configuration produces confident wrong guidance, and the person blames your app rather than the configuration. It also gives your rollout a real switch-on moment: the day the configuration goes green is the day your users notice the difference.
Check where you stand in the Backoffice, or ask Studio to validate. Fix the critical and high findings first; those are the ones holding the gate shut.
What controls it today
Two things decide what an outside assistant gets on your app, and both are in your hands already.
The health gate decides whether your curated surface is served at all. Until your configuration is clean, an assistant works from the page and says so.
The person's own access decides everything else. The connector acts in their session, so anything they cannot do in your app, it cannot do either. Removing someone's access to your app removes their assistant's access at the same moment, with nothing else to revoke.
A per-app switch that turns the runtime connector off independently of the health gate is not built yet. If you need one before it exists, say so through support and it will be prioritised against real demand rather than guessed at.
What you will see in reporting
A plan driven from an outside assistant is recorded like any other, with the assistant named as the actor, so your Activity and AI Interactions views distinguish it from a plan the Appilot panel started. Interaction retention follows your plan, and telemetry control on an enterprise licence covers this traffic like the rest.
Where to go next
- Configure with AI sets up Studio.
- Authoring for the agent is what makes the curated surface good enough to be worth exposing.
- From your assistant is the page to send your users.