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.

Connecting a resource to an agent or to one of its assignments (an MCP server, an integration or a channel bot) is limited to the ones you can see yourself, and a save that adds another one is refused; what the agent or the assignment already names stays in place when you save, whoever connected it. An agent shared with you runs with what its owner connected to it - their MCP servers, custom tools, knowledge bases, channel bots and integrations - in its assignment runs, and in your chats too with one exception, integrations: in a chat, an integration you cannot see, or whose owner's connected account is not shared with you, is not used for you (see Sharing an OAuth integration). Your own or a company-wide integration of the same service takes its place when the agent resolves one for you; otherwise a note under the answer names the integration (by its service only when it is not shared with you) and says why, and the agent is told too, so it can say what it cannot do.

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 OpenCRQ; see Intents. A built-in tool the agent carries but this deployment has switched off (the code interpreter, Runners, a feature not enabled here) is shown greyed as Unavailable: it does nothing until an administrator enables it, and while editing you can remove it from the agent, not add it. On a company-managed agent that carries Work Items or Shared State, the same card holds its Coordination access: which agents can read and change the company-managed work items it creates and the shared state it owns (see Work history).
  • The Model picker in Configuration chooses what the agent runs on: Platform default, one model, or Platform routing model. The routing model is the lightweight model an administrator sets in Settings > AI Models (the one that already evaluates routing conditions); pick it for an agent that takes a narrow, repeated decision - classify, judge, route - that a small model handles well and for less. The agent then follows whatever routing model the administrator configures. When none is configured, the agent runs on the platform default model, and the Configuration and Overview tabs say so. Choosing a model of its own takes the agent off the routing model.
  • 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.
  • Versioning lists every version of the persona and of the tracked settings, to compare them and roll back. It also holds the agent's persona rewrites (see below).
  • Memory shows the agent's longer-term memory, where authorized users can search it, review its health, and run maintenance. An entry that no longer holds is marked Superseded (see What the agent remembers).
  • 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.
  • Feedback gathers every thumbs up and thumbs down given to the agent's work — its chat answers, its assignment runs, its background tasks and the answers it gave when another agent consulted it — with the comments people left, filterable by kind of work and by rating. When feedback criteria are defined (Settings > Quality), it also shows the agent's weighted score and, per criterion, the average, the distribution and the last 30 days. It is shown to the people who can manage the agent.
  • Activity is the agent's run history — review recent executions and spot failures.

What the agent remembers

An agent with persistent memory stores what it learns (store_memory), searches it (search_memory), and is given the most relevant entries at the start of each conversation and assignment run.

Some entries describe something that changes: what a document's footer says, how many slides a deck has, the status of a ticket. The agent stores those as state entries, named by the object they describe (a subject such as doc:<id> or presentation:<id>). When it records a newer observation of the same subject, that one replaces the older:

  • The older entry is kept and still found by a search, listed after the current ones and marked Superseded. It is never given to the agent as context again.
  • A state entry reaches the agent dated (as of <date>, verify live), with a reminder that it is a past observation and that the live document, deck or ticket is the one to check before acting on it.
  • The agent can also retire an entry that no longer holds (invalidate_memory), by its id or by its subject. A retired entry is kept and marked Superseded too.

Entries that name no subject behave as they always did. In a conversation, the agent replaces and retires only the memory it keeps for you: the memory it shares with every user of the agent stays as it is for the others, and the newer entry is the one you are shown.

What an assignment or a roster may name

An assignment whose trigger listens to an integration reads that integration's events with its credentials, so when you save it, the integration it names must be one you can see: yours, one shared with you or one of your groups, or a company-wide one. Admins may name any. Otherwise the save is refused with the same answer whether the integration exists or not. Editing anything else, or saving the trigger again with the integration it already names, is never refused, even if that integration is no longer visible to you. The agent builder tools apply the same rule; when strict admin access for agent tools is on, an administrator's agent may name only the integrations the administrator sees as their own, shared with them or company-wide.

An agent you create from a template gets the template's assignments, and the template's default skills that you can use are selected in the wizard's Skills step (remove the ones you do not want). An assignment of a template can ask for inputs: starting it manually opens a form for them (for example the report to analyse). In XTM One, the template gallery's Threat Intelligence category holds nine analyst roles adapted from Feedly's CTI prompt library (intrusion, adversary, detection engineering, threat hunting, vulnerabilities, strategic intelligence, quality review, risk communication, financial services), each with one assignment per analysis and the threat-intelligence skills it relies on. Fill in the Organization context section of their persona: every assignment tailors its output to it. A template trigger that names an integration you cannot see is created without it, and then listens to the new agent's own integration of that provider.

The agents you let an agent hand work items to (the Work Items tool's roster) follow the same rule: you can add only agents you can see (admins may add any), and the ones already in the roster stay when you save.

Improve the persona

An administrator can ask for a rewrite of an agent's persona from its Versioning tab (Ask for a rewrite), measured against one of the evaluations the agent is part of (evaluations, and so this button, are not offered in XTM One mode). The agent's latest completed run of that evaluation is the baseline, so it must have measured the persona the agent has now; if it has not been run yet, run it first. The rewrite is written from that run's lowest-scoring cases and from the feedback people gave on the agent's work. Only the persona is rewritten, never a skill, and with targeted changes: a rewrite that would grow the persona by more than half (or by more than 2,000 characters, for a short one) is refused, and a persona of more than 20,000 characters is not rewritten. The rewrites are shown to the people who can manage the agent.

Nothing changes until someone who may manage the agent approves it: an administrator for a company-managed agent, and for a private agent its owner or someone it is shared with for configuration (an administrator's access alone is not enough). Approving shows the changes line by line; Apply makes the rewrite the active persona as a new version and runs the evaluation again for this agent, on the same model.

When that run ends, the two quality scores are compared (the evaluation's judge score, or its F1 score, never the overall score with speed). A drop of more than 2 points rolls the persona back to what it was, again as a new version; anything within 2 points keeps the rewrite. If someone edited the persona after the rewrite was applied, their edit is kept and the verdict is only reported. Every step is in the version history and the audit log, so any of them can be undone by hand.

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.

The copy is yours, so it keeps only what you could connect to an agent of your own. When you copy an agent someone else owns, the integrations, MCP servers, knowledge bases, custom tools, skills, prompts, handover agents, work-item owner agents and channel bots you cannot use are left out, in the copied assignments too, and the confirmation says how many of each kind were left out and why (the warnings of the duplicate response). Everything you can use is copied as it is, a personal OAuth integration shared with you included. Whoever copies, an assignment trigger that listens to an integration you cannot see loses it: the copied trigger then listens to the copy's own integration of that provider. The original agent is not changed: it keeps running with everything its owner connected. Copied assignments start disabled.

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.

Exporting everything is for the people who can manage the agent: its owner, someone it is shared with for configuration, and administrators. If you can see an agent but not manage it, such as a company-managed agent or one shared with you as read-only, Export gives you what its AI Catalog download carries instead, in either format. A credential passed to an MCP server as an argument or in its URL is masked. Custom tools that are not company-managed are left out, unless the agent is published with its personal tools included. A company-managed tool, MCP server, skill or prompt restricted to a group you are not in is left out too, and variables come without their values. The file still imports: re-enter the masked values and fill in the variables afterwards.

Read-only integrations

An integration bound to an agent can be made read-only for that agent: the agent keeps the tools that read from it (list, get, search, download) and loses the ones that change it (create, update, delete, send, post, transition, upload and any tool whose action is not clearly a read). The setting is enforced when the agent runs, not by an instruction in its prompt: a write tool of a read-only integration is not offered to the agent, and a call that names it anyway is refused. Removing the integration from the agent removes its read-only mark. The same integration can stay writable on another agent.

Building agents from a conversation

An agent with the agent builder tools (the General Assistant, or an agent given the agent_builder built-in tool) can build agents for you in chat:

  • create_agent sets up a complete agent in one call, with everything update_agent can change: model and temperature, built-in tools, memory, tool scoping and deny list, read-only integrations, handover and channels. If one setting is refused, no agent is created. The answer lists every integration bound to the new agent with its name, so you can check none is missing.
  • clone_agent copies an agent you can see, with integrations, knowledge bases and built-in tools added or removed and the persona replaced or extended. It never copies assignments, memory or sharing, and it shows what differs from the original.
  • list_integration_tools shows which tools of an integration read and which write.
  • update_integration shares an integration with groups: members can use it (bind it to their agents and run it) or also manage it. An agent shared with a group only uses, for each member, the integrations that member may use.
  • update_agent also shares an agent, with groups or with named people outside any group: "share this agent with alice@example.com and marie@example.com, read-only" gives them the agent in their agent list and lets them chat with it; config lets them edit it too. Only people who already have an account here can be named - an address no account matches is refused, and nobody is invited. Removing someone takes their access away at once. The answer, and get_agent, say who the agent is shared with: each group by name with its number of members, each person by name and email, with their level of access. A company-managed agent is already open to everyone and is not shared this way. As for a group, a person the agent is shared with only uses, in their own chats, the integrations they may use themselves.
  • list_groups lists the groups of the platform with their number of members, so the agent can find the group to share with and say who an existing share reaches. Administrators' agents can also list the members of each group.
  • run_agent_once runs an agent once on a prompt and returns its answer, so you can try a new agent without leaving an assignment behind.

An agent given the agent_builder built-in tool can also hand background tasks to any agent you own, the ones it just created included, without adding them to its handover agents first. Other agents only reach the agents set up in their handover configuration, and when a handover is not possible the answer says why. The General Assistant tries an agent it just built with run_agent_once.

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.

An assignment limited to some of the agent's MCP servers keeps that limit. A server included in the file is mapped onto the copy the import creates, and a server outside the file is kept only if you can already use it on this instance; any other server is removed from the assignment's scope and the import says so. An assignment left with none of its servers runs without MCP tools rather than with every server of the agent.

An assignment's integration setting is never widened on the way in. An assignment set to use no integrations imports the same way, and one limited to specific integrations imports with no integrations at all, because those integrations do not exist here: the import report names it so you can re-select them. An assignment that uses all of the agent's integrations keeps doing so, as does any assignment from a file exported before this setting was carried.

An assignment whose trigger listens to an integration keeps it only if you can already see that integration on this instance (an admin keeps any that exists here). Otherwise the integration is removed from the trigger and the import names the assignment, so you can pick one of your integrations before enabling 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.

When an assignment shows Emergency stop

An assignment paused by the emergency stop shows a red Emergency stop badge instead of Paused, in the agent's assignment list and on its own page, with who pressed the stop, when and why. Its on/off switch is disabled: the assignment comes back when the stop is lifted, not one at a time.

Next step

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