Manage one live Assistant and its alternatives

Profile operations

Several profiles can be saved. Only one is the selected runtime identity.

The Active badge is more than decoration: its local ID determines which model, greeting, and Instructions ordinary chat uses and which profile becomes the Base Assistant when Advanced Agents is enabled.

One active profile, many saved alternatives

Assistant cards are ordered by internal name and show model, Display Name, created date, local asst_ ID, and management actions. The active card is marked Active; every other card offers Activate.

Saved alternatives are useful for a controlled replacement, different brands/environments, or Tool assignment. They are not automatic audience routing, page targeting, role targeting, or A/B testing. SmartSite does not choose among local profiles based on the visitor’s question. If you need specialists inside one experience, use an Advanced Agent Flow rather than manually multiplying Base profiles.

What the card actions really do
Action	Immediate effect	What it does not do
Activate	Writes that profile’s local ID as the selected Assistant for future runtime requests.	Merge profiles, copy knowledge, reset old conversations, or test compatibility.
Edit	Changes the stored Name, Display Name, model, Welcome Message, and Instructions after Save.	Modify an OpenAI Assistants object; none is created.
Copy ID	Copies the local profile identifier.	Produce an OpenAI platform Assistant ID or credential.
Delete	Permanently removes the local profile; deleting Active also clears the active selection.	Remove remote knowledge, undo past conversations, or repair Tool/workflow references automatically.

Activation changes the runtime, not the library

All profiles share the site’s synchronized Knowledge Base. Activation changes the selected model and local identity/behavior; it does not create a new vector store or resynchronize pages. An answer difference after activation may therefore come from model/instruction behavior while the underlying sources remain identical.

Tools behave differently. A Tool assigned to All Assistants remains available across profiles. A Tool assigned to one Assistant ID is exposed only when that profile is relevant in Basic runtime; workflow specialists have their own explicit Tool connections in Advanced runtime. Audit assignments before retiring an ID.

Existing visitor response chains may retain conversation context. Activation applies to subsequent runtime configuration, but an old conversation can make comparison misleading. Use a fresh visitor token/private window for regression testing.

A controlled profile switch

Name the change. Model upgrade, instruction revision, public rebrand, or new audience should have a specific test goal.
Preserve the current profile. Copy approved Instructions and note active ID/model so rollback is possible.
Prepare outside production. Because creating a profile activates it immediately, use Local/staging or a maintenance window when creating the candidate.
Audit Tool assignments. Identify Tools bound to current and candidate IDs and those available to All Assistants.
Audit Advanced runtime. If enabled, confirm the candidate is appropriate as Base Assistant and run Flow Checks/simulator.
Activate the intended card. Confirm exactly one Active badge and the success notice.
Start a fresh conversation. Run the same direct, knowledge, uncertainty, Tool, and out-of-scope cases.
Read Analytics. Verify model, Assistant identity, runtime, retrieval, Tool behavior, duration, and errors.
Keep or roll back. Reactivate the previous profile if the candidate fails; do not delete either during the comparison.

Editing the active profile applies after Save without a separate Activate step. Treat a substantial edit like activation: record, save during a test window, and use fresh conversations.

Use alternatives for the right reasons

When another profile helps—and when it hides the real design
Situation	Another local profile?	Better reasoning
Prepare a tested replacement model/instruction set	Yes, with controlled activation.	A separate candidate preserves the known-good profile for rollback.
Automatically handle sales versus support questions	No.	Use one clear Assistant or Advanced specialists/routing. Local activation is global, not intent-based.
Separate staging from production	Usually separate sites/environments.	Profiles inside production are not an environment boundary.
Give one Assistant a particular Basic Tool	Possibly.	Specific ID assignment can narrow profile exposure, but receiver security still applies.
Test tone variants with live visitors	Not as built-in A/B testing.	Activation is a manual global switch and lacks automatic experiment allocation.

Edit without creating contradictions

The edit page separates Identity, AI Model, Welcome Message, and System Instructions. Read the whole profile after any change. A new Display Name can conflict with a Welcome Message that still uses the old brand. A new model may respond differently to the same instruction. A translated brief may preserve fluent words but weaken a prohibition.

The “Last updated” value helps orient administrators but is not a release record. For material changes, keep the reason, reviewer, regression results, and rollback choice in your normal operations process.

Delete only after a dependency check

Deletion is irreversible in the interface. Before deleting:

confirm the card is not Active or activate the intended replacement first;
preserve any Instructions, Welcome Message, model choice, and identity wording required for history or rollback;
inspect Tools assigned specifically to that Assistant ID;
confirm Advanced workflow behavior after changing the selected Base profile;
check operational documentation and screenshots that reference its local ID; and
run a fresh conversation with the replacement.

Deleting the Active profile clears the selected Assistant ID and can leave chat without an available Assistant. Deletion does not remove conversation logs created under the old profile, and it does not undo Tool actions already performed.

A two-profile operating pattern

Use clear internal names such as Website Support – Production and Website Support – Candidate July. Keep the production card active. Prepare the candidate in a safe environment, then recreate or edit during a controlled window, activate, and test. If it fails, activate Production again. Once the candidate has operated successfully and the old profile’s Tool assignments are migrated, retire the old card.

Do not encode confidential release notes in Internal Name; it remains local admin content but still belongs in WordPress storage and screenshots may expose it.

Keep history without keeping clutter

Assistant cards are not a version-control system. Retaining every experiment makes the Active choice harder to review and leaves old IDs available for Tool assignment. Keep a production profile and a purposeful candidate while testing; preserve approved text and change evidence in the organization’s normal documentation; delete obsolete profiles only after dependency and rollback review.

If regulations or internal policy require historical configuration, export or record the relevant sanitized fields outside the live Tool/Assistant interface before deletion. Do not keep a broken profile active or assignable merely because it is the only historical copy.

Recognize the active card

Screenshot capture pending /images/screenshots/assistants/manage.webp

Edit, Activate, and Manage Multiple Assistants

Capture: Show two fictional assistant cards, one with the Active badge and the other with Activate/Edit controls.
Show: Assistant names, models, Active status, Activate, Edit, Delete
Viewport: Desktop, 1440 × 900
Annotate: Use numbered callouts only for controls referenced in the procedure.
Redact: OpenAI keys, tokens, secrets, personal information, private URLs, IP addresses, and conversation text