Managing 1 AI agent takes a handful of settings. Managing 5 or 10 means every change has to name the agent, the workspace, and the knowledge base it touches.
Chatley Architect (Arc for short) is an assistant that manages your account from plain-language requests. Every action that touches your account arrives as an approval card, and nothing changes until you approve it. This post covers naming agents, targeting the right workspace, and telling removing a knowledge base from an agent apart from deleting it. Deleting a knowledge base cannot be undone, so read that section before you approve anything.
For the wider view, see our guide to AI agent management.
Give each agent one job and name
Say you run a sales agent, a support agent, an appointment agent, and a receptionist agent, each with its own instructions, voice, and knowledge. With 4 agents, "change the voice" could mean any of them. When several match, Architect shows a shortlist and asks which one you mean. Naming the agent up front skips that round trip. "Change the voice of the appointment agent" can be proposed as written.
Put the role first in every name, then the channel or team. "Support - Main line" and "Sales - Web - EN" can be identified in 3 seconds by someone who didn't build them. "Agent 2" forces a person to open the agent and read its instructions. Names matter most on live agents, since a change to an agent with a phone number attached reaches real callers the moment you approve it.
Name the workspace when agents share a role
A workspace groups agents with everything they draw on. Agents, knowledge base, templates, voices, campaigns, lead forms, appointments, calls, transcripts, and insights all belong to 1 workspace. Plan, billing, the Do Not Call list, and team members are shared across the account.
If 2 workspaces each have a sales agent, "update the sales agent" has 2 possible targets. When your account has more than 1 workspace, Architect asks which one and shows you the list. "Update the support agent in the customer service workspace" skips that step and leaves nothing to guess.
Knowledge bases belong to 1 workspace, so moving material between workspaces means recreating it. Most accounts start with 1 workspace. A second one earns its place when 2 sets of agents shouldn't share material, such as separate clients, separate brands, or a sandbox kept away from live agents. See the Workspaces documentation.
Where knowledge lives and how to keep it fresh
Knowledge attaches at 2 levels. The workspace knowledge base holds shared items that every agent in that workspace can use. Per-agent documents are files attached to a single agent. Use workspace knowledge for content every agent needs, such as pricing or business hours, and a per-agent document for material only 1 agent should cite.
You add knowledge by uploading PDF or HTML files or by scraping a website, with scrape depth defaulting to 2 links from the starting URL. Keep it current by re-scraping when a site changes, removing out-of-date files, and splitting very large documents into focused ones. Architect can't upload files, so add them from the Knowledge Base screen and then ask Architect to attach them.
What is the difference between removing and deleting a knowledge base?
Removing a knowledge base from an agent stops that agent from using it. The file stays in your library and stays on every other agent using it. Deleting a knowledge base removes the file itself and takes it away from every agent at once. It cannot be undone. A deleted file leaves nothing to restore, so you would upload it again from the Knowledge Base library.
Here is how that plays out. A business has 1 product knowledge base attached to its sales agent and its support agent. The support agent no longer needs it. Removing it from the support agent solves that. Deleting it would strip it from the sales agent too, and the file would be gone.
Write "remove the product knowledge base from the support agent" so the request names the agent and the action. Architect asks for approval on every deletion, whatever you approved earlier in the chat. Treat a delete card as the moment to check which agents still depend on the file.
What an approval card shows and what to check
When Architect proposes a change, the card describes exactly what will happen. You get 3 buttons. Approve once applies that one change. Approve for this chat applies it and stops asking for the same kind of action until you close the conversation. Deny changes nothing. Some cards also include Edit, which lets you correct a value, and saving your edit asks Architect for a fresh proposal.
Read the card, not just the message around it. The card is the exact change and the message is explanation. Cards expire after 10 minutes, so if one lapses, ask again.
In two situations, always ask, whatever you chose earlier. The first is a live agent, where the card says the change reaches callers the moment you approve it. The second is deletions and undo. Because Approve for this chat stops the asking, name the agent and workspace in every request that follows.
Undo and what Architect leaves to other screens
Ask Architect to undo, and it takes back the most recent change it made, such as replaced instructions, a changed voice, an attached knowledge base, or an agent it created or deleted. Only the last change can be reversed, so after 3 approvals in a row you can't step back through all of them. Some changes can't be reversed at all, and Architect gives the reason.
Deleting an agent pauses it. The agent keeps its settings and call history and can be restored later.
Architect won't delete workspaces, change billing, manage team members, provision phone numbers, run campaigns, set up integrations, or upload files. Deleting a workspace happens from the Workspaces screen and permanently removes every agent and all data in it, so move anything you want to keep first. Full behavior is in the Architect documentation.
Myths about managing multiple agents
Most mistakes in multi-agent accounts come from a wrong assumption about what a button does. These 4 come up most often.
Approving a card always makes the change safe. | Approve for this chat stops the asking for that kind of action, so name the agent and workspace every time. |
Deleting an agent destroys it. | The agent is paused and can be restored with its settings and call history. |
Undo gives you a full change history. | Undo reverses only the most recent change. |
Knowledge is shared across the whole account. | Knowledge belongs to 1 workspace, and moving it means recreating it. |
Checklist before you approve a change
Confirm the agent name matches the one you meant, especially when 2 agents share a role.
Confirm the workspace.
Check whether the card says remove or delete.
Before any deletion, list every agent that uses the knowledge base and keep a copy of the source file outside Chatley.
Check whether the agent has a phone number attached, because then the change reaches callers immediately.
Approve within 10 minutes, or ask again.