Configure an agent

Open an agent from Agents to manage its integrations, runtime, workspace, access, memory, tools, and skills.

ConfigurationCopy Anchor Link

The Configuration tab groups Basics, Runtime, Description, Access, Variables, and Secrets. Edit lets you change the display name, daemon, runtime, model, effort/reasoning, fast mode, permission mode and execution strategy. The exact runtime controls come from the selected daemon's advertised capabilities. Switch Runtime to By decision to let a Decision pick the runtime and model for each new session.

Output mode controls what reaches connected chat platforms; the full transcript remains available in Sessions:

• Minimal — one live-updating reply that settles on the final answer; intermediate steps stay in the status.
• Low — replies only.
• Medium — replies plus tool activity and plans.
• High — Medium plus reasoning and tool outputs.
• None — nothing is posted to the channel; the run remains visible in its web session.

Other runtime behavior settings include:

• What people can do in chat — whether people in a conversation may also approve tool calls and change runtime settings; see below.
• Show footer — add the agent, runtime, model and session links to replies.
• Introduce on channel join — have the agent introduce itself to agents already in a channel, so they know when to delegate to it.
• Execution strategy — the boundary the agent's sessions run in: Host (no boundary), Sandbox (an SRT process sandbox) or VM (a microsandbox VM). The picker lists what the agent's placement offers. A strategy that can't run there stays listed as unavailable; hover over it to see why. If the placement no longer offers the saved strategy, it stays selected and is marked "Not offered where this agent is placed." The Runtime card shows the choice as an Execution strategy row. Agents on AgentConnect Cloud have neither the picker nor the row, because each session already runs in its own pod. This outer boundary is separate from the runtime's permission mode; see Sandboxing.

What people can do in chatCopy Anchor Link

What people can do in chat sits beside the model in Edit, and the Runtime card shows the current level. Each level includes the one before it:

• Talk to the agent — people only talk to the agent. A tool call that needs approval goes to the agent's editors, in the console or in a direct message.
• Talk and approve tool calls — the default. People can also answer a tool call that the agent's permission mode asks about: allow it once, always allow that tool, or deny it.
• Talk, approve and change settings — people can also change the model, effort, permission mode and fast mode from chat, with the in-conversation commands or the Playground's controls.

Who counts as people depends on whether AgentConnect knows who someone is:

• Slack, with Follow Slack access on — only the agent's editors, recognized by the Slack account each one linked under Your profile → Sign-in methods (see Linked accounts). Anyone else who tries is told privately that only an Agent editor can, and someone whose Slack account is not linked is told how to link it. When the person who asked is not an editor, an editor also gets the approval card in a direct message.
• Microsoft Teams, with Require Microsoft Teams access on — only the agent's editors, recognized by the Microsoft account each one linked. Anyone else who tries is told privately that only an Agent editor can. When the person who asked is not an editor, an editor also gets the approval card in their 1:1 chat with the bot.
• Other chat platforms, or Slack and Teams with that setting off — anyone who can talk to the agent in that conversation.
• The Playground and the agent chat API — the agent's editors, and at the second and third levels also the conversation's owner, even one who can only view the agent. A chat API conversation belongs to the key's owner.

Every level keeps these rules:

• A conversation switched Off, or answered By decision, takes no approvals or setting changes from chat.
• A conversation shared with another organization, such as a Slack Connect channel, gets no approval card. The approval goes to a member of your organization in a direct message.
• The first answer decides, whether it comes from the conversation, a direct message or the console.
• The setting never changes the permission mode: an agent with full access still never asks, and a tool someone chose to always allow stays allowed.

For an agent in a public group, choose Talk to the agent, so nobody there can approve its tool calls.

This setting replaced Allow change in chat. Existing agents moved to Talk and approve tool calls, or to Talk, approve and change settings if they allowed changes in chat. On a self-hosted deployment, Feishu / Lark with Follow Feishu / Lark access on works like Slack above.

Description and personaCopy Anchor Link

The Description card is edited separately. It is not just display copy: AgentConnect uses it as the agent's persona and system-prompt seed in every session. Describe the role, responsibilities and durable operating guidance that should apply wherever the agent is invoked.

Move an agentCopy Anchor Link

Choose another daemon or daemon group in Runs on in Edit to move the agent. The target must be online and support the selected runtime, model, tools, and skills. While the move is pending, the Execution strategy picker is locked; save the move first, then change the strategy.

AgentConnect waits for active work to stop and reprovisions the saved definition on the target. It does not copy daemon-local workspace files, managed or native memory, or transcripts. Commit or back up local work first; GitHub workspaces are cloned again on the new machine.

Variables and secretsCopy Anchor Link

The Variables and Secrets cards set environment values owned by this agent — API endpoints, feature flags, and credentials its tools need. Secrets are write-only after saving.

Organization Owners can define a value once under Settings → Variables & secrets and assign it to all or selected agents. Assigned rows carry an Organization label and are read-only from the agent page. See Variables & secrets for precedence, rotation, and secret handling.

Agent visibility (sub-agent calls)Copy Anchor Link

Agents can call each other as sub-agents. The Agent visibility card controls both sides of that relationship:

• Inbound: Which agents can call this agent?
• Outbound: Which agents can this agent call?

Each direction can allow All agents or a Selected list. A call is permitted only when the source's outbound policy and the target's inbound policy both allow it. Discovery and calls are organization-scoped; the agents do not need to share a chat integration or channel.

The agent's initial values come from the organization's Default agent visibility setting. Organizations start with All agents in both directions, while an Owner can choose Isolated in the Default agent visibility card under Settings. Changing that organization setting affects only future agents; edits in this card affect this agent only.

See Multi-agent work modes to choose a collaboration pattern and Agent visibility for the full call policy. Who on the team can see the agent is controlled separately by Team visibility.

MemoryCopy Anchor Link

The Memory tab shows the agent's persistent memory and is the one place to switch its backend: Managed, Native, External, or Off. Managed memory can be edited as files; an external backend exposes capability-driven records instead. Switching does not migrate existing memory — the old store remains in place but is no longer loaded. Organization Owners register external services under Knowledge → External memory before an agent can select one.

For a complete external-backend walkthrough, including recall/capture policies and a self-hosted Mem0 example, see the guide to using Mem0 OSS as external memory.

DreamingCopy Anchor Link

With Managed memory, Dreaming can periodically consolidate recent memory and session history. Its default policy schedules a run every day at 04:00 in the daemon's timezone and leaves completed memory results for review. A scheduled Dream considers sessions updated since the last successful run and skips when there is nothing new. You can turn Dreaming off, remove the schedule for manual-only runs, explicitly opt in to automatic adoption, and optionally mine reusable skills. A Dream may also propose Knowledge or managed skills, but an organization Owner must review each shared proposal before it is published.

Tools & SkillsCopy Anchor Link

Shows the MCP tools available to this agent and the skills it has enabled. Organization-level providers and skill sources are managed separately, so adding one to the library does not enable it automatically. See Tools & Skills for connectors, MCP servers, Git sources, managed skills, and per-agent enablement.

DeleteCopy Anchor Link

Delete (⋯ menu) removes the agent and its triggers from the organization. Its integrations are released so their bots can be reused.