AI agents & knowledge
Configure AI agents, versions and execution history
An agent combines a defined job, a versioned configuration and the services it is allowed to use. Availability depends on your deployment and permissions.
Understand an agent definition and its published version
An agent definition identifies a reusable assistant or automated worker. Its version contains the instructions, selected provider and model, conversation settings, knowledge configuration and allowed tools. Publishing a version selects the configuration intended for new work. Editing an unrelated draft does not mean the running workflow has adopted those changes.
Some agents are supplied and maintained by the platform or a feature module. Such definitions can be read-only, hidden from management lists or unavailable in the sandbox. Use the controls provided for that feature instead of assuming every agent can be duplicated or edited freely.
Write instructions around a concrete task
Begin with the result you want and the context the agent should rely on. A publishing assistant might turn an approved brief into a channel-specific draft. A support assistant might explain a documented setup step and identify when a case needs staff. An internal marketing agent can have a different audience and allowed actions from a public sales conversation.
Specify the desired tone, required facts, prohibited assumptions and what to do when information is missing. If another feature expects a structured response, preserve that feature’s required response format. Changing it to free-form prose can make a useful-looking answer unusable to the workflow.
Review model, context and capability settings
- Open the agent available to your role and inspect its published configuration.
- Where editing is allowed, create or clone a version for a controlled change.
- Review instructions, provider/model selection and any required output format.
- Choose the permitted knowledge sources, tools and access requirements.
- Set appropriate conversation inclusion and execution limits, then test before publishing.
Conversation history can be included in later turns with a configured limit. Prompt and response retention is separately configurable. Neither setting should be interpreted as automatic access to all workspace conversations.
Test a representative request before publication
Use the sandbox only when it is enabled for the definition and your role. Test a normal request, an incomplete request and one outside the agent’s intended scope. For a drafting agent, review the actual draft. For an agent with tools, also check the record or action created by the tool.
After publishing, run the same representative request through the feature that will use the agent. A sandbox result is useful evidence, but it does not verify a website embed, scheduled post generator or Ticket handoff. Those surfaces have additional configuration and access requirements.
Use execution history to understand a result
Where permitted, execution history shows recorded runs, their status, provider/model, timing and available usage information. A run can contain different stages such as context retrieval, model execution and tool activity. Inspect the stage that stopped instead of treating every failure as a writing-quality problem.
History visibility depends on permissions and retention settings. Full prompt text is not always retained or shown. Share only the minimal run reference and a non-sensitive description when requesting help; avoid copying private customer messages into unrelated channels.