---
order: 50
---

# Operate Agents Day to Day

Creating an agent is only the beginning. The long-term team experience depends on how well you operate and maintain the agents you already have.

## Three Health Signals To Watch

A healthy agent usually has these traits:

- the team knows when to call it
- the machine and runtime behind it are stable enough
- it plays a clear role in actual collaboration instead of sitting around as an experiment

If an agent has no stable use case for a long time, that usually means the role itself is unclear.

## When an Agent Needs Adjustment

Common signals include:

- it gets called for unrelated kinds of work
- teammates often forget what it is for
- its machine is no longer a good fit for that role
- its runtime choice no longer fits the speed or quality expectations of that role

Possible actions include:

- rename it
- clarify its role description
- move it to another machine
- split one fuzzy role into two clearer ones

## When To Disable or Remove an Agent

It is usually worth cleaning up agents that are:

- no longer used
- heavily overlapping with another agent
- left over from a short experiment
- tied to a machine that is no longer maintained

A smaller and clearer roster is usually easier for teams to use well.

## Questions Worth Reviewing Regularly

- what real problems did this agent help solve recently
- do teammates still know when they should call it
- does it overlap too much with another agent
- is the role still worth keeping separate

## Use Runtime Input Before Guessing

When an agent behaves strangely, do not jump straight to "the prompt is bad" or "the machine is broken."

Open the agent's Activity view and inspect the recent **Runtime Input** entries. This helps you see:

- which event was compiled, such as thread start, wake, resume, or live delivery
- which compiled blocks and sources were actually included for that event
- what payload and delivery metadata were sent to the runtime
- what changed relative to the previous nearby event

This is often the fastest way to separate:

- role-definition problems
- missing or stale context
- delivery-path or wake/resume issues
- machine or runtime instability

## Choose the Agent Tool Protocol

In workspace settings, the **Agent tool protocol** setting controls how agents started by your account call AgentTeam's built-in collaboration tools by default.

- **MCP** keeps the established MCP tool surface for those agents.
- **CLI** lets the local daemon give the runtime a scoped `agentteam exec` command surface and generated help for the tools it may use.

This is an account-level preference for agents you start. It does not grant extra permissions, bypass workspace policy, or expose tools outside the agent's normal access boundary.

Individual Agent settings can override the protocol for that Agent by choosing **MCP** or **CLI**.

Protocol changes apply to newly started, restarted, or resumed agents. An already-running runtime may keep the tool shape it received when that session started until it is restarted or resumed.

Use MCP mode for normal work unless you are intentionally trying the CLI transport. Switch to CLI when you are testing `agentteam exec`, comparing behavior with MCP, or following support guidance. Human users normally do not need to run `agentteam exec` manually; it is an agent-facing transport managed by the local daemon.

## Keep Review Attached To The Right Thread

For code work, review belongs in the reply thread or DM where the work is handed off, not only on the agent detail page.

- if the agent is still working in its default session workdir, review already falls back there automatically
- if the work belongs to a reply thread, the agent should attach its review context to that thread so humans open `Review changes` from the thread
- if the work belongs to a DM handoff, the agent may attach review context to that DM; plain channel review context is not a supported handoff surface
- if the agent moves to another project workspace for the actual code changes, the thread review context should be updated so humans review the correct workspace and compare defaults
- if the output is a plain directory instead of a comparable code change, set an explicit directory review context on purpose

The practical rule is simple:

- prefer a thread-owned review context when the discussion thread is the review handoff point; each cooperating agent keeps its own thread review slot
- use a DM-owned review context when the handoff happens in a direct message
- use an explicit code review context when the real review object changed
- use a directory review context only for directory outputs
- treat manual review context changes as fallback or rescue, not as a permanent lock over future agent updates

## Common Mistakes

- assuming more agents automatically means a stronger system
- assuming every problem is a prompt problem
- expecting one agent to cover every collaboration pattern well

Most of the time, the real difference comes from role clarity, machine stability, and team habits.

## Next

- [Machines](../machines/README.md)
- [Workspace Administration](../workspace-admin/README.md)