Relationships and Nesting in XTM One
Objects in XTM One are rarely isolated. Most of the platform works because one object references, includes, or configures another.
Why this matters
When you look at a page, you need to know whether you are:
- editing the object itself
- editing a child object that belongs to it
- linking an external object that is reused elsewhere
That distinction explains a lot of the product behavior.
Direct relationships
Some relationships are simple references between standalone objects.
Common examples:
- an agent references one or more knowledge bases
- an agent references prompts and skills
- an agent references integrations, MCP servers, and tools
- a flow references agents
- a group gives users access to shared objects
These links matter because the referenced object still has its own life elsewhere in the platform.
Nested configuration
Some information is stored inside the parent object rather than as a separate shared object.
Common examples:
- an assignment belongs to one agent
- an agent’s persona belongs to that agent
- channel behavior belongs to the agent or the shared bot configuration
- personal tool overrides belong to the user profile
In these cases, you are not linking to a reusable library item. You are editing the configuration of the current object.
Agent relationships
Agents are where most relationships come together.
An agent can:
- contain assignments
- reference reusable resources
- point to handover targets
- belong to one or more flows
- expose itself through chat, channels, or MCP
This is why the agent detail page is often the best place to understand the rest of the model.
Flow relationships
Flows do not replace agents. They organize them.
This is important:
- removing an agent from a flow does not necessarily delete the agent
- deleting a flow removes the grouping, not always the agents themselves
- one agent can participate in more than one flow
Flows are therefore coordination objects, not ownership objects.
Shared resource relationships
Reusable resources keep their own identity even when many agents use them.
Examples:
- one prompt can be attached to several agents
- one skill can shape several agents
- one company-managed MCP server can be reused broadly
- one knowledge base can support multiple assistants
This is why changing a shared resource can have effects beyond one page.
Overrides and inheritance
Some settings in XTM One follow inheritance rather than a simple one-to-one link.
Examples include:
- channel behavior that can inherit from the channel bot
- profile preferences that can override platform defaults
- user-level MCP exposure that can be narrower than global exposure
When a value is empty, it often means inherit rather than disabled.
How to read a page correctly
A useful rule is:
- if the page shows a reusable entity card or picker, you are usually linking objects
- if the page shows inline form fields without a separate entity page, you are usually editing nested configuration
This helps you predict whether a change stays local or affects shared behavior.
Next step
Continue with Containers and scopes, which explains how work is grouped and where organizational boundaries apply.