Managing Agents
The enterprise-wide agent catalog.
The Agents section in the sidebar lists every agent in the enterprise — across all apps.
The agent list
Each row shows the agent's name, the apps that use it, its status (Active or In development), its tool counts (data tools, knowledge tools, process flow tools), and who last edited it. Search, sorting (newest, oldest, A–Z, Z–A, last edited), and pagination are available; + Create Agent starts a new one.
Configuring an agent
An agent's configuration is the same whether you open it here or from an app's Agents tab. It's split across five tabs — Agent Config, Data Tools, Knowledge tools, Process flow tools, and Guardrails — and Agent Config itself has four panels:
- Agent Details — name and the LLM powering the agent's responses
- Purpose & Responsibilities — a short purpose summary and the key tasks the agent handles. Both are required; they shape the agent's system behavior.
- Character Attributes — optional, and more than just tone. You can set the agent's role (the position it represents, e.g. banker or HR assistant), tone (formal, friendly, neutral), domain (the industry it specializes in), audience (who it talks to — customers, employees, partners), constraints (rules and limits on its behavior), schema definitions (structured definitions to reference when handling data), gender (for voice and persona design), and free-form instructions.
- Other Preferences — a dashboard preference describing which widgets matter for this agent. This feeds Pulse dashboard generation.
Guardrails
Open the Guardrails tab on an agent to attach safety checks for that agent only, override enterprise defaults when allowed, and run a dry-run test. Type definitions and enterprise-wide defaults live under Administration → Guardrails.
The attached list
Each row shows the guardrail name, a short description, an enforcement mode badge (Active or Shadow), and an enable toggle.
From the row menu you can Edit or Delete. Both require the guardrail to be enabled and not enterprise-enforced. If it is enforced or disabled, Edit and Delete stay unavailable (with a tooltip explaining why).
Enterprise-enforced guardrails also lock the enable toggle — you cannot turn them off on the agent.
Adding a guardrail
Click Add GuardRail, pick a type that is not already attached, then set its agent-level options:
| Field | When it appears |
|---|---|
| Applies to | Competitor Check, Gibberish, PII, Toxicity — input, output, or both |
| Banned list | Competitor Check only |
| PII entities / Mask strategy | PII / Anonymizer only |
| Enforcement mode | Always — Active (enforce) or Shadow (detect only) |
| Action on fail | Always — options depend on the type |
Only types not yet on the agent appear in the picker. When every type is attached, the modal shows that all guardrails are already added.
Editing configuration
Edit opens Configure Guardrail. You can switch among enabled, non-enforced guardrails on the agent and change the same override fields as when adding (applies to, banned list / PII fields when relevant, enforcement mode, action on fail). Done saves the override for that agent.
Overrides apply only to this agent. They do not change the enterprise defaults in Administration.
Testing
Test opens a dry-run against enabled guardrails on the agent:
- Enter sample input and/or output text (at least one is required).
- Run Test.
- Review sanitised input and sanitised output, plus a test report per guardrail: name, latency, type (Input / Output / Input/Output), status, and action taken.
- Change the sample text and Rerun Test if needed.
Use this to confirm filters, blocks, and redactions before publishing.
Enterprise enforcement and read-only
When a guardrail has Apply this configuration enterprise-wide turned on in Administration, it still appears on the agent but cannot be edited, deleted, or toggled here. Platform Users (and other read-only views of the app Agents tab) can see the list and run tests, but cannot add or change guardrails — the empty state points them to edit at the enterprise agent when needed.
Deleting an agent
Because agents are shared, deletion is checked for impact first: the confirmation lists every app currently using the agent, with links to open them. Deleting removes all of the agent's configuration and cannot be undone.
Things to know
- Agents are shared: one agent can serve several apps, and edits apply everywhere.
- An agent must be Active to serve real conversations; agents still being built show In development.
- Attach knowledge to keep answers grounded in your documents rather than the model's general knowledge.
- Tools are managed at the enterprise level. Inside an app's Agents tab the tool tabs are read-only — the empty state points you here.
- Guardrails can be set per agent or locked enterprise-wide — see Guardrails for type details and shared settings.