Sharing an AI Employee Externally

Let outsiders try the AI employee you’ve raised with a single link, exactly as it is right now. Anonymous visitors can use it without signing into UpServe. They land in a chat view and talk to your employee directly, while all AI model and tool usage is billed to your SU balance, never theirs. Publishing leaves your original employee unaffected.

The unit of sharing is a public version: a frozen, isolated copy of your employee at the moment you publish it. You can keep editing or even delete the original; the public version stays untouched.

At a glance

Item	Detail
Pre-publish review	A review coach recommends what to keep per file and lets you edit it in place. If anything risky remains, publishing is blocked
Unit of sharing	Public version (a frozen copy of the employee)
First greeting	The first message a visitor sees when they open the link. The owner can edit it directly (the review coach writes a default)
External service pre-check	Before publishing, the system automatically finds external service requests that would otherwise break and lets you allow them in one click
Visitor sign-in	Not required
Who pays	The owner’s SU balance
Link types	`link` (standalone page) · `embed` (site embed)
Expiry	No time-based expiry. Owner closes manually, or guardrails close automatically
Updating	Swap in the latest state without changing link addresses. The previous version is kept for 7 days (roll-back available) before automatic cleanup
Telling it how to behave	Tell it in chat (“answer visitors like this”) and it applies instantly, no republish needed (one exception, see below)
Guardrails	Per-session and per-day SU caps, enable/disable toggle, automatic closure
Session retention	Free 3 days · Starter 7 days · Standard 14 days · Pro 90 days · Enterprise unlimited (based on owner’s plan)
Attachment retention	No independent timer. Deleted together with its session once the session retention period elapses
Answering visitor questions	Questions the employee can’t answer are handed off to the owner, and the owner’s reply is delivered straight into that visitor’s conversation (web, iOS, Android)
Contact (lead) capture	Contact details from the entry form plus anything the employee learns during the conversation both land in the Leads table under Files & data

How source · public version · link relate

Create a public version from the source employee, then issue multiple links for each version. Changes to the source reach existing public versions only after an update.

For an employee that has handled Google account data, creating a public version, saving or exporting a template, and exporting a skill may be restricted to protect material that could contain that data. Disconnecting the account alone does not remove the restriction. On the web, after bringing in a shared employee or template, check the preparation card for missing capabilities and connections you need to set up.

Publishing status

Once you finish the review and click Create Public Version, a row is created immediately in waiting state while the actual file copy runs in the background. Once the copy finishes the status changes to ready; if something goes wrong it becomes failed. You can watch the status update live in the UI. Links cannot be issued until the public version is ready.

What a public version captures (and what it doesn’t)

Publishing copies your employee onto a separate, isolated AI work computer at that moment. From that point on, the original and the public version evolve independently.

Captured

Employee name, description, avatar, behavior instructions
Enabled tool configuration
The employee’s file system (memory and working folders): only whitelisted paths are copied onto a fresh AI work computer

Not captured

The original employee’s chat history
Webhooks, scheduled runs, team relationships (links to other employees)
The original employee’s SU balance or subscription

Memory exposure warning. Your employee’s file system may contain past conversation summaries, notes, and knowledge files that are personal or sensitive. Before publishing, use the review step to check the file list and leave out anything you don’t want to share externally. See “Pre-publish review” below for how it works.

Automatic refine suggestions. Sometimes you want to share the know-how in a memory file but not the personal details and proper nouns baked into it. The review coach finds these files on its own and prepares a refined version (with personal data and proper nouns stripped out), ready for you to check and adjust on the review screen. The original file is not shared.

File content. Selecting a file on the review screen shows its content right away. You can inspect the content of text files within the whitelisted paths. Binary files are flagged as “binary”; their content is not shown.

Tools available in public sessions

Every visitor gets their own workspace. Each person who opens a public session is given a separate, isolated workspace. Files one visitor creates and anything they run stay invisible to other visitors and never reach the original employee. That is why a public copy can do more than read and reply: it can actually get work done.

The allowed set includes:

Web search and HTTP requests
Image generation
File read, write, and edit; file share
Code execution
Skill execution (see the caveat below)
Send card (structured UI responses)
Memory recall, history search, source conversation reference
Saving contact details a visitor volunteers during the conversation (see “Collecting visitor contact details” below)
Handing off a question the employee can’t answer to the owner (see “Answering visitor questions” below)

Skills run only when they need nothing of yours. A skill that requires a connected account (Google, Slack, and so on) or saved connection details (such as an access key) is refused automatically in a public session, and the employee carries on with whatever it can do without it. It will not ask the visitor to connect an account either.

Browser automation, desktop automation, skill search/install, canvas, scheduled run management, team collaboration, and use of saved connection details are blocked automatically. The ask-user capability is also auto-disabled in public sessions. Instead of pausing for a reply, the employee addresses questions naturally within its text response. You can block additional tools per public version via the Additional tools to disable list at creation time.

Whatever a visitor makes disappears with their session. The isolated workspace is removed when that visitor’s session passes its retention window. To leave a visitor with something, the employee has to hand it over with file share.

Memory and history tools are never shown by name to visitors. Memory recall, history search, and source conversation reference run silently. Visitors see only a generic category label such as “recall” rather than the specific tool name. All other permitted tools (web search, image generation, code execution, etc.) display their activity labels as usual.

Read-only reference to the original conversation. A public version can reference original conversation content only within the scope the owner approved when publishing. That reference is frozen at the moment the version was created, so nothing from subsequent conversations is included. Visitors cannot directly search or browse the original conversation through this mechanism.

External service calls. Any external service the source employee normally relies on does not carry over automatically. To let a public session use it too, set it up separately. See “External service access for public sessions” below.

Telling it how to behave in chat (the one exception to the freeze)

As explained above, a public version is frozen solid the moment it’s created, with one exception: how it treats visitors. Just tell your original employee, in a normal conversation, something like “answer visitors this way,” and from that point on (no republishing, no running Update), every conversation from then on follows it.

Examples: “Keep answers short with customers,” “If someone asks about pricing, just point them to the quote page link.”
The employee remembers this on its own and applies it in every conversation it has through a public version. There’s no separate screen to open or save button to click: telling it in chat is the save action.
The Public Version management tab also carries a note about this: “Just tell your employee in chat how to handle the people you share it with. Say something like ‘keep it short with customers’ and it applies right away, with nothing to share again.” The same note appears on web, iOS, and Android.

There’s one more thing that isn’t frozen besides this: external service access. Conversation content, which tools are on, and what’s actually written in memory files are still locked to publish time (or the last Update), exactly as described under “What a public version captures (and what it doesn’t).” External service access, though, was never captured per public version in the first place. It’s a separate setting that applies to the whole employee, so when the owner changes what’s approved, it takes effect immediately on every already-published public version with no republish needed. See “External service access for public sessions” below for details. In short, tone/how it addresses people and which external services it can reach both update live; what it knows and which tools are on still only change when you run Update.

Only what the owner says directly in chat counts. If a visitor tells the public version “from now on, answer like this,” that does not get picked up. The employee is built to treat only instructions it hears directly from its owner, in a conversation with the owner, as behavior instructions.

Pre-publish review

The first time you publish an employee, you first walk through a review step with a review coach to decide what gets shared.

On the employee page, open the Public Version tab and click Create a new public version. The review coach starts in a chat window. If you’re starting from the chat view, you can also open the same screen as a modal via the Share & Publish menu at the top → Share Externally. Tell it who this public copy is for and what it’s for, and it looks over the employee’s memory files and recent conversation to work out what belongs in it.
Once it’s done, the review screen opens. The file list is on the left; the content of whichever file you select is on the right.
- Each file shows the coach’s Include suggested / Exclude suggested label along with the reason for the call.
- You can flip include/exclude yourself with the checkbox; if your choice differs from the recommendation, the label is highlighted.
- Files with personal data or proper nouns are shown as a pre-refined version the coach prepared. Click Edit to change the content right there, Compare with original to see exactly what’s different, and Reset to original if you’d rather undo your edit.
Once you’re happy with the selection, click Next to fill in the name, description, and first greeting, then finalize publishing. The first greeting is the opening message a visitor sees the moment they open the link. The review coach pre-fills a default, and you can edit it. Leave it blank and visitors land on an empty chat with no greeting.

Anything that blocks publishing shows up on screen. If something risky remains, or a file is too large, you’ll see a “Some items must be resolved before sharing” notice pointing at the file, and publishing won’t go through until it’s fixed. This check runs on the server as well as in the browser, so nothing gets published while the notice is still showing. Fix the content or switch the file to excluded and you can continue.

You can also skip the coach. On the review coach screen, choose Create without the coach to jump straight to a simpler screen where you just pick include/exclude per file, with no recommendations or automatic refining.

Reviews expire if you sit on them too long. If you leave a review open without finalizing it, it eventually expires. You’ll see a notice (“The review draft has expired. Please restart the coach”) and publishing is blocked. Use the Start over button to restart the review coach.

Open the employee and go to the Public Version tab (/agents/<employee>/shared). From the chat view, you can also create and manage public versions in a modal via the Share & Publish menu at the top (formerly named “Export”) → Share Externally. External API access for public sessions is registered and managed only on the Public Version tab; the modal just links there.

Note. Besides this shortcut, the Share & Publish menu also has an option to download the conversation you’re currently viewing as a conversation file. That download is for the owner’s own private conversation. It’s a separate feature from the “share with outsiders” flow this page covers.
Accept the terms of service and privacy policy, then click Create a new public version.
- You’ll go through the “Pre-publish review” step above to decide what to include.
- There is a maximum package size, so exclude large or sensitive files you don’t need.
- Once you finish the review and confirm, the public version starts in waiting state; it changes to ready once the copy completes.
Add a link to the public version. Each link has its own configuration:
- Type: link (a standalone external page) or embed (embedded view in your own site)
- Collected fields: mark name / email / phone as required, optional, or hidden
  
  Contact details you choose to collect here are automatically added to the Leads table under Files & data. That includes both what visitors type into the entry form and anything the employee learns during the conversation, and you get notified when a new one arrives. See “Collecting visitor contact details” below for details.
- Max SU per session (e.g. 500 SU)
- Max SU per day (e.g. 5,000 SU)
- Allowed origins (for embed links): the domains permitted to embed the embedded view
Copy the generated URL and distribute it.

A single employee can have many public versions, and each can have many links. Splitting links by campaign or channel lets you track usage separately.

Connecting a KakaoTalk channel

If you already run a KakaoTalk channel, you can have this link’s public version answer the messages that come in through it.

Once real questions start arriving through your public link, the employee proactively offers to connect it. A card titled “Want me to take KakaoTalk questions too?” appears in your chat, and clicking Connect channel takes you straight to the connection screen below. This setting used to be buried inside the link settings screen, hard to find on your own. Now the employee surfaces it the moment a real question comes in. The card doesn’t appear if you’ve already connected, or if your public link hasn’t received a question yet. Finishing the connection requires a desktop browser (the Kakao chatbot admin console is a desktop tool), so on mobile the card shows only “You can’t connect from this device. Open this conversation on your computer to connect your KakaoTalk channel.” instead of a button. You don’t have to wait for the card; you can connect any time using the steps below.

Click the card in your chat, or open the link’s settings screen and find Connect KakaoTalk channel → Issue.
Two values appear: a skill server URL and a request header value. Enter them into the Create skill screen of the Kakao chatbot admin console (OpenBuilder).
Attach the skill you created to your scenario’s fallback block. From then on, messages coming through the channel are handed to this link’s employee.
Turn on the callback option in that block’s settings. The employee needs more than five seconds to compose an answer, so with callback off, messages arrive normally but not a single reply is ever delivered.
Deploy the bot and connect it to your live channel. Without deploying, your changes never reach the real channel.

These two values are shown only on this screen, once. Once you close it, there’s no way to view them again. If you lose them, you’ll need to close the connection and issue a new one (which also means re-registering the skill in OpenBuilder). The screen tracks whether you’ve copied both values, so wait until that reminder is gone before closing.

The connection list shows how many requests have come in, when the last one arrived, and when a reply was last actually delivered. Those are two different things: with callback off, requests keep arriving while no reply ever gets through. When something is wrong, the connection shows what is blocking it and when that problem was last seen. For example, with callback off you’ll see something like “The callback option is off in your chatbot block. Open the settings of the block this skill is attached to in OpenBuilder and turn callback on.” This notice clears itself once a reply actually gets delivered. Connections you no longer need can be removed with the Revoke button.

Answering visitor questions

Sometimes a visitor asks something the employee simply can’t answer with the information it has: a pricing exception, current stock, whether a specific date works, an approval only the owner can give. Instead of just saying “I don’t know,” the employee can hand the question straight to the owner.

Handed-off questions show up as a card above the public version list, on the employee page’s Public Version tab. This is a queue of people waiting for an answer, so the longest-waiting question sits at the top. If there are no waiting questions, the card doesn’t appear at all.
Each card shows the visitor’s question (as written up by the employee) alongside any background the employee added for context. Both the visitor’s and the employee’s own words are shown in quotation marks to keep them clearly separate from facts the owner has directly verified. The added context is unverified, for reference only.
Write your answer and click Send answer. It’s delivered immediately into that visitor’s conversation. If the visitor still has the page open, it appears in real time; otherwise they’ll see it the next time they open it. Once sent, it can’t be edited, so check it before sending.
If you’d rather not answer, click Don’t answer to remove it from the list. The visitor is not told anything either way; no “declined” signal is sent.

This works the same way on web, iOS, and Android. There are limits on how many waiting questions one visitor can have at once, how many a visitor can send per day, and how many can pile up on a single public version at once, to prevent abuse. The employee tells the visitor when a limit is reached.

Collecting visitor contact details

When a visitor talking to a public version volunteers their own contact info (“here’s my number, call me”), the employee can save it as a lead. There are two paths into the same place.

Entry form: whatever the visitor types into the collected fields (name, email, phone) configured under “Creating a share link” above
Captured mid-conversation: contact details a visitor mentions naturally during the conversation, which the employee notices and saves

Both paths land in the same place (the Leads table under Files & data), and the owner is notified when a new lead arrives. See the Files & data guide for how to use that screen.

Values already in the entry form are never overwritten. If a visitor already filled in a field on the entry form, a different value mentioned later in conversation won’t replace it. Only empty fields get filled in by conversation. Correcting a value has to be done by the owner, directly on the Files & data screen.

Leaving contact details is always optional. A visitor can keep chatting without sharing a name, email, or phone number at all (unless the owner marked a specific field required on the entry form, in which case it’s required to enter the session). The employee never invents a contact detail. On the web public link, it never asks for one a visitor hasn’t offered. On a KakaoTalk channel, Kakao doesn’t share who the customer is, so the employee asks once for a phone number at the end of its first answer and says in the same sentence that it’s so the business can get back to them. If the customer doesn’t want to, it doesn’t push, and asks once more only when it can’t answer and the business needs to reply directly.

Can this be turned off? There’s no single on/off switch. Setting every entry-form field to hidden stops the form from collecting anything, but question hand-off and mid-conversation contact capture are always on for every public version. There is currently no way to disable either one individually from any screen.

Updating a public version

As you keep refining your employee, you’ll often want the content behind an already-shared public version to reflect the latest state. In the past that meant creating a brand-new one and reissuing links. Now you can refresh the content while every link you’ve already shared (standalone pages and embeds alike) keeps pointing at the same address.

Find the public version you want to refresh in the list and click Update.
A screen opens pre-filled with the name, description, files included in sharing, and tools blocked from sharing you set last time. If this public copy was built with the review coach, the include/exclude choices from that review carry over automatically.
- The file list works on an include-by-check basis: only checked files are published. Uncheck a file to leave it out of this version.
- You won’t see every file laid out at once. The screen expands only files that changed on the source since your last publish, files that are new, or files that otherwise need a decision, and collapses everything whose decision hasn’t changed into an “Unchanged since last time” group. Those keep their existing decision, so you don’t have to re-scan the whole list every time.
- Files that are new on the source since your last publish are marked New and start unchecked (excluded), so content that has never been reviewed can’t go public without you noticing. Check the box to publish them.
- Files whose content has changed on the source since your last review are marked Source changed. Opening one lets you click Compare with the published version to see just what’s different, with no need to re-read the whole file. If this public copy was built with the review coach, a notice appears with a Re-review with the coach button whenever there are new or changed files. Click it and the review coach re-examines those files and produces a new review. Check the summary, then click Update with this review to actually apply it.
- Unless you check Keep the previous version’s conversation cutoff, the new version reflects the source employee’s conversation up to this exact moment.
If you don’t want to make the same call every time, turn it into a rule. The Rule button next to a file lets you set “always include/exclude this file” or “always include/exclude this whole folder.” Once set, that decision applies automatically from the next update onward (including to files created afterward), so you don’t have to re-decide the same path or folder each time. Rules can be reviewed and removed from a list at any time.
Click Update and wait while the new version is built. Once it’s ready, every link issued for this public version automatically switches over to the new version. You don’t need to touch any URL or embed code you’ve already shared.

The previous version isn’t gone. Expand the Previous version section in the list to see everything that’s been replaced, and if something’s wrong with the new version, click Roll back to point links back at the older one. Link addresses stay the same during rollback too.

Visitors who were already mid-conversation when the update goes live keep talking to the previous version without interruption; only visitors who arrive afterward land on the new one.

Previous versions are cleaned up automatically after 7 days. Rolling back only works within that window. If you want it gone sooner, you can delete it directly from the list.

Auto-update (optional)

If updating by hand each time is tedious, turn on auto-update in the edit screen. When enabled, a new version is created automatically on the interval you set (in days) whenever the original employee has changed, and your share links switch over, while the link URLs stay the same. The list shows which public versions have auto-update on along with their interval, and if the original has changed since this version (a Differs from source state), you get a notification. Auto-update only runs when the original has actually changed; if nothing changed, no new version is created.

Auto-update only refreshes files you’ve already published. Files created since your last publish have never been reviewed by anyone, so auto-update leaves them out. An “always exclude” rule you set above still applies during auto-update, but an “always include” rule only takes effect the next time you run Update yourself, a safeguard against a never-reviewed new file quietly going public through auto-update. To publish new files anyway, open Update yourself and check them, or re-review them with the review coach and confirm.

External service access for public sessions

External services used by the source employee do not connect to a public version automatically. Open external service access in the employee’s public-version management screen and allow only the access it needs. This setting applies to all public versions of this employee. A preflight card can show connections that need preparation and let you Allow them.

If extra access is needed while serving a visitor, the owner may receive an approval request. Check its target and action, then Allow / Deny it. Unapproved work does not proceed, and visitors never see the actual saved connection details. Allowing reads does not also allow changes.

`link` vs `embed`

Item	`link`	`embed`
Entry context	Standalone page	Inside an embedded view
Loading inside an embedded view	Blocked (security)	Allowed
Header / background	Visible	Hidden / transparent
Origin allowlist	Not used	Only listed domains may embed and exchange messages

Embed snippet

To embed the employee, copy the embed code from the share-link screen and give it to the person managing your site.

What the visitor sees

After opening the link, the visitor sees the employee’s name and description with an entry form.
They fill in name / email / phone according to the link’s collection policy.
They check the terms of service / privacy policy consent box, required before the session begins.
The chat view opens. If the owner set a first greeting, the conversation starts with it; otherwise it starts empty. Replies stream in real time.

A ‘Build your own’ link (optional). A “Powered by UpServe” mark appears at the bottom of the shared screen. If the owner turns on Show a ‘Build your own’ link to visitors in the link settings, that mark links to UpServe sign-up, giving visitors who liked the employee an entry point to build their own. It’s off by default and configured per link.

Cost and guardrails

All AI model and tool usage in a shared session is billed to the owner’s SU. Visitors pay nothing. That makes the guardrails essential.

Guardrail	Behavior
Per-session SU cap	Once a single session crosses the cap, it is blocked and rejects further messages
Per-day SU cap	Once the link’s daily total crosses the cap, new sessions are refused (resets next day)
Auto-close	If the owner’s SU are exhausted or the owner’s account is deleted, the link is auto-disabled
Link toggle	The owner can disable or delete a link at any time

Both SU caps are optional. Leaving either the per-session or per-day cap blank means that check isn’t enforced at all, and usage can run effectively unlimited until the owner’s overall SU balance runs out. Since these guardrails only work if they’re set, we recommend filling in both unless you have a specific reason not to.

Disabling or deleting a link immediately ends any active sessions on it. Visitors see the termination reason in the UI.

Visitor usage is charged to the owner’s SU balance. Usage limits and the link’s active status can restrict access.

Operating and monitoring

The owner-facing dashboard at /agents/<employee>/shared exposes:

Sessions: per-session visitor info, SU consumed, last activity, blocked state
Message log: full transcripts per session (owner-only)
Audit log: every link create / update / close / CSV export action
CSV export: four files: sessions.csv (session list), messages.csv (message detail), usage.csv (SU usage aggregation), audit-logs.csv (audit log)

Using visitor feedback to improve. Once you have published at least one public version, the original employee gains access to an inbox of visitor transcripts from all its derived public versions. Use these to understand what questions visitors ask, where they get stuck, and what to improve in the next update.

Deleting a public version also closes its links. Visitors can no longer use them, and the closed links no longer count toward your account’s public-link limit.

Security and privacy

Sharing involves third-party personal data, so the following rules apply.

Data controller: the owner is the data controller for visitor data. UpServe is the infrastructure processor.
Collected fields: name / email / phone (when the visitor enters them), an anonymous session identifier, IP address. Values from the entry form and anything captured mid-conversation also land in the Leads table under Files & data.
Visitor questions: questions the employee hands off to the owner, along with any context, are held separately until the owner answers and are visible only to the owner.
Visitor session isolation: each visitor’s conversation is kept separate. Conversations from one visitor do not carry over to any other visitor using the same shared link. Anything generated during a visitor’s session is not retained by the employee, so a later visitor cannot see what an earlier visitor discussed. The memory the owner set at publish time is what all visitors share, and it does not change based on visitor conversations.
Session retention: sessions are automatically purged based on the owner’s plan: Free 3 days, Starter 7 days, Standard 14 days, Pro 90 days, Enterprise kept indefinitely (no automatic purge). Downgrading triggers a grace period before the shorter retention applies.
Attachments: not retained on an independent timer. They are deleted together with their session once the session retention period above elapses.
Transcripts: retained together with their session and automatically deleted once the session retention period above elapses (independent of deleting the public version itself).
Application logs: 90 days.
Audit log: retained indefinitely (for legal and security compliance).
Visitor data deletion: the owner can delete the personal information (name, email, phone) for any individual session from the owner dashboard.

For the public-facing wording shown to visitors, see the Shared Agent Terms and Shared Agent Privacy Policy .

FAQ

Q. If I update the original employee, do existing share links pick up the changes?

No. A public version is frozen at the moment it’s created. However, using Update from the list creates a new version from the source employee’s current state while your existing share link URLs stay the same. See “Updating a public version” above for details.

One exception: how it treats visitors. Tell it in chat and the next conversation follows it immediately, no Update required. See “Telling it how to behave in chat” above for details.

Q. Can a visitor permanently change my employee’s memory files or notes?

No. Visitor activity never touches the source employee. Beyond that, anything arising from one visitor’s conversation is not saved back to the employee, so a different visitor arriving via the same link cannot see what earlier visitors discussed. The memory you set at publish time is the same starting point every visitor gets, and visitor conversations do not alter it.

Q. Can the employee hand visitors a generated file or image?

Yes by default. File sharing and image generation are allowed, so visitors can download whatever the employee produces (there’s currently no way for a visitor to upload their own file, though). If cost containment is a concern, add these tools to the extra-disabled-tools list when publishing.

Q. Are password protection and expiry dates supported?

Not currently. To cut access immediately, disable or delete the link; to limit exposure over time, set per-session and per-day SU caps.

Q. Are there limits on how many public versions or links a single employee can have?

Active public links are subject to the owner account’s plan limit. The limit counts every active link across all of your employees, not per employee, so a link left on another employee’s public version counts too. When you hit the limit, the message names the employee holding the active link; turn off or delete the unused link on that employee’s public version screen. Each public version does provision its own AI work computer, though, so prune ones you no longer use.

Q. Can I turn off visitor contact capture?

Setting every field in the entry form to hidden stops the form from collecting anything. Mid-conversation capture and question hand-off, though, are always on for every public version. There’s currently no way to turn either off individually, and no single overall switch either.

Learn more

Equipping Tools: decide which tools to enable before sharing
Skills & the Autonomous Skill System: review the skills your visitors will rely on
Files & data guide: browse and export what’s collected, including the Leads table
Shared Agent Terms
Shared Agent Privacy Policy

Advanced

You don’t need this for everyday use. It’s here if you want the exact mechanics of updating, rolling back, the pre-publish review, chat-based behavior instructions, and external API access.

How the review draft works

A review the coach saves is kept for 24 hours. If you don’t finalize publishing within that window, the review expires, and you’ll see a notice on screen telling you to restart the coach.
Edits to the file list and file content on the review screen are saved automatically after a short pause, and the last edits are saved once more the moment you finalize publishing.
Whether risky content remains, or a file is over the size limit, is checked by the server on every edit and again at the moment you finalize publishing. Even if the on-screen check is bypassed somehow, publishing is refused unless the server-side check passes too.
A review that actually made it to publication is kept afterward so a future update to that public version can carry over its include/exclude choices. It’s cleaned up once the public version itself is deleted.
If you choose Create without the coach, none of this review-draft or automatic-refining process runs. Only the include/exclude you picked directly on the file list is applied.

How updating works

Update doesn’t edit a public version in place. It builds an entirely new one from the source employee’s current state, then switches every existing link over to it in a single step. The previous version keeps serving traffic until that switch completes.
Visitors who started a session before the switch stay on the version they connected to; only visitors arriving after the switch land on the new version.
Rolling back doesn’t delete the newer version itself. It stays in the list, but from that moment it isn’t connected to any link. Reactivating it means issuing a new link (at a new address) or running Update on it again, and Update always rebuilds from the source employee’s current state; it doesn’t restore this version’s exact prior content.
A public version whose source employee has been deleted can’t be refreshed. The Update button is disabled because there’s no longer a source to pull from.
There’s no way to hand-edit the files inside a public version that’s already published, in place. To change what it contains, either update the source employee first and then run Update, or edit the file directly on the review screen while an update is in progress.
The “changes only” diff on the update screen compares against the content of that file in the most recently published version, as its baseline. For refined files, comparing the refined content against the source’s current content takes priority instead.
Include/exclude rules (per file or per folder) take priority over the screen’s default carry-over and recommendations, but on the auto-update path only exclude rules are applied automatically. Include rules only take effect when a person opens Update and confirms it themselves, a safeguard against a never-reviewed new file quietly going public through auto-update.

How chat-based behavior instructions apply internally

Behavior instructions the owner leaves in chat are appended by the employee to a running list it keeps in one of its own files. That file is never copied into a public version; instead, on every visitor turn, the server reads the current content on the original employee’s side directly and folds it into that turn’s instructions. That’s what makes an edit the owner just made apply from the very next turn (including the next message of a visitor already mid-conversation), with no republish or Update involved.
This file has a size cap. Since it rides along on every visitor’s every turn, it’s set much smaller than a regular memory file (enough for a few dozen entries), and once it’s full, new writes are rejected so the employee has to trim it.
Behavior instructions may not be applied if they present a safety issue.
If something goes wrong reading this channel (a transient lookup error, say), the turn itself doesn’t fail; it just proceeds without the behavior instructions. That’s the safe default here: this channel only shapes tone and emphasis, while the boundaries that actually matter (which files came along, which external APIs are reachable, whether the vault is closed) are always enforced separately, regardless of this channel.
Because this file is never copied into a public version, the visitor-facing session has no file to write to in the first place, so there’s no path by which anything a visitor says could feed into these instructions.

How question hand-off and contact capture work internally

Both tools (question hand-off and contact capture) only make sense in a public session, so they aren’t in a regular employee’s default tool set; they’re merged in automatically the moment a public session starts. They never show up in the owner’s own conversation with the employee, since there’s no visitor session for it to reach back to. For the same reason, they don’t appear in the tool-blocking list used when creating or updating a public version (that list only shows regular tools), so there’s currently no way to disable either one individually.
Contact capture never writes to the ontology (the Leads table) directly. To preserve the existing boundary that keeps visitor and employee speech from writing straight into the owner’s tables, the tool only writes to a storage area scoped to that visitor session, and the server separately reads that value and projects it into the Leads table. A value from the entry form and one captured mid-conversation follow exactly the same path.
A lead in the table is identified by the visitor’s session. If a phone number is picked up later in the same conversation, it updates that same lead row rather than creating a new one.
A field that already has a value from the entry form can’t be overwritten by the mid-conversation capture tool. This blocks prompt-injection attempts to plant a fake value and reflects that a human-entered value is more trustworthy. Corrections have to be made by the owner directly on the Files & data screen.
Visitor question forwarding has limits to prevent abuse. The employee tells the visitor when a limit is reached.
The owner’s answer is delivered into the visitor’s conversation first, and only then is the question marked “answered.” If delivery fails, the question stays pending so the owner can try again. This ordering avoids a state where it looks answered on the owner’s side but the visitor never received it.

How external API access works internally

External service access stays within the scope allowed by the owner. Visitors never receive the actual saved connection details. Revoking access restricts later requests.

When the KakaoTalk connect card appears

The trigger is a real question arriving through your public link. Creating or publishing a link alone doesn’t surface it. It has to still be unconnected when a question comes in.
The card never appears for organization-owned employees. Issuing a KakaoTalk channel connection is only possible for personally owned employees in the first place.
The card itself doesn’t store whether you’re connected. Every time it renders, and every time you return to this conversation after the card appeared, it asks the server for your current connection state. So if you just finished connecting on another device (a computer), reopening the same card shows it already gone.