Skip to content

Agents

Agents are the main assistants in XTM One. Each one is configured for a particular role, team, or workflow.

What an agent is for

Use an agent when you want a more focused assistant than the General Assistant. An agent can answer questions in a specific domain, use selected tools and integrations, search one or more knowledge bases, hand work to other agents, and run background tasks automatically.

The list page

Choose Agents from the left sidebar to open the list. You can browse all visible agents, search, filter by visibility or tag, import an agent from a file, and — if your role allows it — create a new one. Each card is a quick summary: the agent's status, what is attached to it, and whether it is company-managed or shared. Some cards also offer quick actions such as opening a chat or enabling and disabling the agent.

Click the star on an agent's card or row to make it a favorite. Favorites are pinned to the top of the list in both views, above everything else and whichever column you sort by, so the two or three agents you actually work with stay one glance away in a long fleet. The choice is yours alone — it is stored on your account, follows you to any browser, and changes nothing for anyone else. Click the star again to remove it. Filters still come first: a favorite that does not match your search or tag filter is not shown.

The toggle at the right of the filter row switches between the card grid and a sortable list. The list view is the better choice once you manage more than a handful of agents: it puts status, model, assignment count, and attached resources in sortable columns so you can answer questions like "which agents run which model?" by scanning one column. See grid and list views for how sorting and persistence work.

Not every visible agent is editable. Company-managed agents are shared broadly and often read-only for standard users, shared agents come from a group or another owner, and built-in agents are typically read-only. If you open an agent and cannot change it, the page is behaving as designed for your access level.

The detail page

Click an agent card to open its detail page. The header gives you direct actions — Chat with Agent, Duplicate, Export, enable or disable, and delete when you can manage the agent. If the agent is designed mainly for assignments, the chat button still works but XTM One warns that it is not optimized for conversation.

The page is organized into tabs (some appear only when your role can see them):

  • Overview is the best first stop: a quick understanding of what the agent does and what is attached to it, without reading the full configuration.
  • Configuration is how the agent is set up — persona and instructions, tools and integrations, knowledge and memory, handovers, channels, and intent bindings. For most users this is a reading page; editing is usually reserved for admins. The Intent Bindings card is what makes the agent available inside OpenCTI, OpenAEV, or OpenGRC; see Intents.
  • Budget caps what one run of the agent may spend — money, tokens, tool calls or time — and can let a run that reaches its cost ceiling finish on a cheaper model instead of stopping. Lowering a limit is open to anyone who can edit the agent; raising one above the platform's own budget is an administrator's decision. See Run budgets.
  • Memory shows the agent's longer-term memory, where authorized users can search it, review its health, and run maintenance.
  • Chats shows conversations associated with the agent, to review or reopen context.
  • Delegations shows work the agent sent to or received from other agents, useful for understanding how handovers behaved.
  • Activity is the agent's run history — review recent executions and spot failures.

Duplicate and export

Two header actions are easy to overlook. Duplicate creates a private copy you can adapt without changing the original, and Export downloads the agent so it can be stored, shared, or imported elsewhere. This is especially helpful when your organization uses standard company-managed agents but you need a private variation.

Export asks which format you want. The XTM One native bundle (default, JSON) carries everything — assignments, handover routing, memory settings, prompts, skills and variables — so use it for backups and for moving an agent between XTM One instances. Microsoft AgentSchema (YAML) is an open, cross-vendor agent definition that other agent platforms can read, and only what that specification can express goes into its standard fields.

Choosing AgentSchema shows you exactly which of your agent's settings will not be included as standard fields — handover, memory tiers, assignments, integration bindings, prompts and skills among them — before the file is created. Nothing on that list is thrown away: it is preserved in an XTM One section of the document's metadata, so re-importing the same file into XTM One restores everything, while other platforms ignore that section.

Importing an agent

You do not have to say what kind of file you are uploading. The platform reads the file, works out whether it is an XTM One bundle or an AgentSchema document, checks it against that format's rules, and only then creates the agent. Both JSON and YAML are accepted.

After a successful import you are told which format was detected, along with anything the platform had to assume about your file or could not resolve here. A tool declared in an AgentSchema document arrives without its code, because the specification describes what a tool takes rather than how it works, so you need to fill in the implementation before enabling it. An MCP server arrives as a placeholder, since no server address or credentials travel in the document. A knowledge base or file-search source may be referenced but not included, in which case you bind the agent to a knowledge base on this instance to restore retrieval.

If the file is neither format, fails its format's rules, or is an AgentSchema document describing a hosted or workflow agent — kinds XTM One has no equivalent for — the import is refused and the reason names the specific fields or rules that failed. Nothing is created in that case.

Whichever format you import from, integration bindings, knowledge bases and links to other agents are not imported: they belong to the instance the agent came from. Imported assignments always start disabled so nothing runs before you have reviewed it.

Exposing an agent on a messaging platform

An agent answers in web chat by default and nowhere else. To let it work in Slack, Microsoft Teams, WhatsApp, Telegram, Discord, or Google Chat, enable the channel in Configuration > Channels & Bots, where you choose whether the agent receives messages, publishes messages, or both, and on which channels.

The bot itself is connected once by an administrator. See Channels and bots for the platform setup and the rules that govern mentions, direct messages, and anonymous users.

When an agent is disabled

A disabled agent stays visible but does not behave like an active one: it looks dimmed in the list, chat is limited, and assignments do not run normally. If an agent you expected to use is disabled, contact the person who manages that workflow.

Next step

The next chapter explains Agentic Flow, which shows how agents connect to one another.