Agent Settings

Configure retention, sharing, memory, and safety controls

Agent settings let you control how your agent stores data, who can access it, and what safety measures are in place. Because the platform is governed by design, these controls inherit from your organization’s central policies while letting you tune retention, access, and guardrails per agent.

Accessing Settings

1. Open any agent in Agent Creator
2. Go to the Settings section
3. Navigate between tabs for different configuration areas

General Settings

Basic agent configuration:

Setting	Description
Name	Display name for the agent
Description	What the agent does
Category	Organizational category
Tags	Keywords for discovery
Icon	Visual identifier

Sharing & Access

Control who can use your agent.

Visibility Levels

When you publish, choose visibility:

Level	Who Can Access
Private	Only you
Organization	Anyone in your organization
Public	All platform users
Restricted	Specific users or groups you choose

Sharing Levels

From most private to most open, an agent can be shared with:

1. Specific users or groups in the agent’s organization.
2. The agent’s organization — every member gets access.
3. Another organization you belong to — pick the target in the organization selector.
4. All authenticated users — the “All” entry.
5. Anonymous / public link — access without signing in, through the anonymous sharing mechanism.

Sharing with “All” — every authenticated user

Choosing All in the organization selector shares the agent with every signed-in user of the platform who belongs to at least one organization — including users who are not members of the agent’s organization. It is the authenticated counterpart of the anonymous link:

	Anonymous / public link	Shared with “All”
Sign-in required	No	Yes
Caller identity known	No	Yes — quotas, retention, audit and analytics apply per user
Who is covered	Anyone with the link	Every authenticated user belonging to an organization

Typical use cases — opening an agent to the whole platform in authenticated mode, to users who have a platform account but are not members of the publishing organization:

• Mutualized compliance and governance agents: an AI Act compliance assistant, a security-review agent or a legal/GDPR advisor built and maintained once by a central team (compliance, CISO, legal) in its own organization, and served to every organization of the platform — one agent to keep up to date, every entity gets the same vetted answers, and each caller’s usage stays attributed, quota’d and auditable in their own organization.
• Internal assistants for a multi-entity company: HR, IT-support or onboarding agents offered to every subsidiary’s organization without duplicating them.
• Selective mutualization: the same pattern org-by-org — share the agent with the specific organizations that subscribe to it, rather than with everyone.

If callers should not need an account at all, use the anonymous link instead; it does not require this feature.

The cross-org sharing permission

Sharing beyond the agent’s own organization (a specific other organization, or “All”) requires the agent-factory:sharing:cross-org permission:

• Held by default by organization Owners (via *) and Admins (via agent-factory:*). Opt-in for every other role — crossing organization isolation is a deliberate decision, and the role receiving it becomes accountable for inter-organization sharing.
• Grantable to custom roles in AI Governance’s role editor, in the Agents permissions (“Share Agents Across Organizations”).
• Deliberately not covered by the agent-factory:agents:* wildcard: being allowed to edit agents does not imply being allowed to expose them outside the organization.

To share with a specific other organization you must be an active member of it (the selector only lists your own organizations). Platform administrators are not bound by this membership rule. Shares beyond your own organization default to the user role unless you pick one explicitly.

Managing Access

For restricted visibility:

1. Go to Settings > Sharing
2. Click Add Access
3. Search for users or groups — or pick an organization (your current one, another of your organizations, or “All”) if you hold the cross-org sharing permission
4. Select the access level
5. Save

Access Requests

When users request access to your agent:

1. You’ll receive a notification
2. Go to Settings > Sharing > Requests
3. Review the request and message
4. Approve or deny

Retention

Control how long data is kept.

Conversation Retention

How long to keep chat history:

• Inherit from organization - Use org-wide default
• Custom - Set specific retention period (7-365 days)
• No limit - Keep indefinitely

Document Retention

For uploaded files:

• Same options as conversation retention
• Applies to files attached in conversations

Artifact Retention

For generated content (code, documents):

• Controls how long canvas artifacts are stored

Retention settings affect only future data. Existing data follows the policy that was active when it was created.

Memory

Memory is not set in Settings: it is configured in the Memory capability, under Capabilities → Memory → Parameters (JSON). See Agent Memory for the full picture.

Session Memory

Carries a summary of past conversations into new ones, for the same user and the same agent:

• Enabled by the Workflow, Light Agent, Full Agent and Orchestrator profiles (session_memory: true), off on Simple
• Kept in the user’s login session: a new login starts from an empty summary
• To keep conversations strictly isolated, set session_memory to false and republish the agent (see Turn off cross-conversation memory)

Long-term Memory

Keeps facts and preferences the agent explicitly saves, across conversations and sessions:

• Enabled by the Full Agent and Orchestrator profiles
• The agent saves a memory by calling memory_remember; memories stay stored after the user logs out
• At each message, the user’s most recent memories for this agent are loaded, up to max_memories (default: 50)

To change it, edit the long_term entry of the Memory capability’s Parameters (JSON) (enabled, config.max_memories), save, then republish the agent.

Long-term memory works best when you instruct the agent on what’s worth remembering. Add guidance in your Instructions.

Model Settings

Advanced model configuration:

Setting	Description
Model	Primary AI model to use
Fallback Models	Backup models if primary fails
Temperature	Randomness of the output (0 = deterministic, 1 = balanced, 2 = creative)
Max Response Tokens	Maximum length of a single reply (one LLM call). Different from Message Token Budget, which limits a whole message

Budget Limits

Control resource usage per message. Each of these budgets resets at the start of every new user message and is checked at the start of each internal turn, before the next LLM call — a turn already in flight is never killed mid-way. Message Token Budget and Tool Call Budget fall back to the profile default (see below) when left empty. Max Turns is different: it is a single workspace-wide ceiling (default 50), not a per-profile value. It matches the agentic loop’s built-in hard cap of 50 turns and exists only as a backstop against a runaway loop; what actually bounds per-message consumption is the token and tool-call budgets. Set it on an agent to lower (or raise, up to the hard cap) that ceiling for that agent.

Limit	Unit	Default (global)	Description
Max Turns	LLM round-trips	50	Safety ceiling on think→act→observe cycles for one message before the agent stops and hands off to the fallback. Matches the loop’s built-in hard cap; not a per-profile setting
Message Token Budget	Cumulative input + output tokens	20,000	Total tokens spent answering one message, summed across every internal turn and tool call. Cached input reads are weighted at 0.1×. Resets for each new message
Tool Call Budget	Tool invocations	15	Total tool calls the agent may make while answering one message

These budgets are per message, not per conversation — they bound the work an agent does to answer a single user turn (which may span many internal reasoning steps and tool calls), and start fresh on the next message. The conversation-wide ceiling is a separate mechanism, context_budget, below.

The “global” defaults above are the platform baseline. In practice each agent inherits the defaults of its profile (Simple, Workflow, Light, Full, Orchestrator), which the table below spells out. Values you set on the agent override both.

Defaults per profile

Higher profiles unlock more autonomy and therefore ship with larger budgets:

Profile	Message Token Budget	Tool Calls	Cost Budget
Simple	50,000	0	—
Workflow	100,000	10	—
Light Agent	100,000	15	—
Full Agent	300,000	50	$1
Orchestrator	300,000	100	$5

Max Turns is not in this table: it is a single workspace-wide default (50, matching the loop’s hard cap) rather than a per-profile value, since the turn count is only a runaway-loop backstop — the token and tool-call budgets above are what shape each profile’s real per-message effort.

Orchestrators also cap delegation depth at 3 levels (Agent A → B → C) to prevent runaway sub-agent chains.

Conversation context ceiling

Separate from the per-message budgets above, context_budget (default 120,000 tokens) caps how large a single conversation’s live context can grow — the accumulated history + current request + tool schemas sent to the model on any one call. It is not exposed in the settings UI today; it comes from the profile / platform default.

• At 70% of the ceiling, the runtime compacts the oldest context proactively.
• At 100%, it attempts one emergency compaction; if the request still doesn’t fit, the turn fails with a “Request too large… start a new conversation” message instead of an opaque provider error.

Because context accumulates across turns, this is effectively the limit on how long one conversation can run before you need to start a fresh one — distinct from the per-message Message Token Budget, which caps the work done on a single message.

See Runtime Safeguards for what happens when a budget is reached and the other built-in protections that don’t require configuration.

Safety & Guardrails

Add per-agent safety checks that run around the model: before it (input), after the response (output), or before a tool runs (action).

• Input guardrails: PII detection (mask or block), prompt injection (block), off-topic / topic guard (redirect or block).
• Output guardrails: toxicity (flag, block, or regenerate), hallucination (checks answers against the agent’s knowledge base).

Each guardrail is added from the Capabilities catalog and tuned per agent. For the full list, the settings of each guardrail, and how to adapt them, see Guardrails.

Tool-call approval (human-in-the-loop) is configured under Tool Permissions, not here.

Channels

Configure how your agent is accessed.

Web Chat

The default chat interface:

• Enabled by default
• Customizable welcome message
• Suggested prompts for users

API Access

Programmatic access:

1. Enable API access in Settings > Channels
2. Copy the endpoint URL
3. Use your API key to authenticate

Embeds

Embed the chat widget on websites:

1. Enable embedding
2. Configure allowed domains
3. Copy the embed code
4. Add to your website

Danger Zone

Irreversible actions:

Unpublish

Remove the agent from public access while keeping the draft:

1. Go to Settings > Danger Zone
2. Click Unpublish
3. Confirm

The agent becomes draft-only. Existing conversations are preserved.

Delete

Permanently remove the agent:

1. Go to Settings > Danger Zone
2. Click Delete Agent
3. Type the agent name to confirm
4. Click Delete

Deletion is permanent. All conversations, test cases, and analytics data will be lost.

Next Steps

Publish your agent

Make your agent available to others

View analytics

See how users interact with your agent