The agent editor is the configuration workspace for one AI agent — its identity and every part of how it behaves, organized into a side-nav of sections.
Overview
The agent editor has three tabs — Configuration (everything below), Deployments, and Observability (the last two are permission-gated). On the Configuration tab, a left side-nav lists every configuration section; selecting one opens it in the panel to the right. A persistent header across the top shows the agent's name (and, once published, when it was last published or updated) alongside a model selector and the Preview and Publish controls, with Version History in the overflow menu once a version exists.
You move through the side-nav sections to teach the agent who it is (Instructions), what it knows (Knowledge), what it can do (Tools, Skills, Capabilities, Tasks), what it remembers (Memory), which models run it (Models), and how it's kept safe and tuned (Guardrails, Settings). Some sections only appear if your role grants access to them.
Note: The word "Agent" in these screens can be renamed per workspace, so your instance may show a custom label in its place.
Sections in the Editor
The side-nav holds these sections, top to bottom:
Section | Covers |
|---|---|
Instructions | The agent's role, goal, and behavior, plus the conversation starters users see first. |
Knowledge | The knowledge sets the agent retrieves from to answer accurately. |
Tools | The custom actions the agent can call: connector operations, MCP servers, custom endpoints, and workflows-as-tools. |
Skills | Reusable expertise attached to the agent. |
Capabilities | Built-in functions you switch on for the agent (web search, run code, create documents, and more). |
Tasks | The distinct journeys/intents the agent can run. Permission-gated. |
Memory | What the agent remembers across conversations. |
Models | Which AI model runs each function of the agent. |
Guardrails | A group of safety controls: PII masking, hallucination checks, content filters, custom word filter, denied topics, and blocked messaging. Permission-gated. |
Settings | A group covering indexing, pre-processing, response generation, and prerequisite actions. |
There is also a Prompts section — a library of reusable prompt templates — reached from links inside the editor rather than from the side-nav.
Naming, Icon, and Description
Click the agent's name in the header to open its identity popover — the header itself only shows the name, not the avatar — where you edit the avatar, name, description, and tags in one place. Identity changes save automatically as you make them. These details show up wherever the agent is listed, so a clear name and description make it easier to find and share later.
Saving, Previewing, and Publishing
Saving happens per section, not in the main header:
Section type | How it saves |
|---|---|
Sections you type into (e.g. Instructions) | Show a Save button at the top of the section, with an Unsaved changes indicator while you have edits. Save is disabled when there's nothing to store. |
Picker-based sections — Models, the Guardrails group, the Settings group | Save automatically as you change them. |
Identity edits (name, avatar, description, tags) | Auto-save too. |
In the header, Preview opens the agent so you can try it, and Publish creates a deployable version of the agent and makes your latest changes live (publishing needs deploy permission). If you have share permission, the header also offers Share.
How Sections Map to Runtime
When a user messages your agent, the sections you configured are consulted in a fixed order:
Pre-processing settings and Guardrails screen the incoming message first (blocked messages never reach the model).
For every reasoning step, Instructions (plus Models and response-generation settings) are compiled into the system prompt.
Tools, Tasks, Skills, and Knowledge are assembled into the tool catalog the model can call.
The conversation history and Memory fill in the context.
The agent loops — model call, tool calls, results fed back — until it produces a final answer, which passes through response guardrails before the user sees it.
So: Instructions shape every step, Tools/Tasks/Skills/Knowledge define what the agent can do in a step, Models decide which model reasons, and Guardrails bracket the whole exchange on the way in and out.
Read-Only Mode and Permission-Gated Sections
Two things control what you can see and do. First, the editor opens read-only when you're viewing a published version or when your role doesn't grant edit access — in that mode the Save control is hidden and the fields can't be changed. When you view a published version, the Skills section isn't shown. Second, two sections are permission-gated: Tasks and the Guardrails group only appear when your role grants access to them.
Note: If a section you expect isn't in the side-nav, it's almost always a permission you're missing — ask a workspace admin to grant it.