Agent Management¶

When creating an Agent, the key is not to describe as many capabilities as possible, but to give the Agent clear responsibilities and security boundaries. A good Agent should know what it is responsible for, what it can do, what it cannot do, and how to handle risks.

Create an Agent¶

After entering the Agent list, click Create Agent and follow the on-screen prompts to complete the basic configuration. It is recommended to first clarify the service target and typical scenarios for this Agent, then fill in the name, description, available scope, identity definition, and behavioral boundaries.

Only workspace owners and administrators can create Agents.

Name and Description¶

The Agent name helps the team quickly determine what it is suitable for handling. It is recommended to use clear role names, such as:

Development Review Assistant.
Observability Troubleshooting Agent.
Test Case Generation Assistant.
Operations Release Check Agent.

It is not recommended to use generic names like "My Agent", "Smart Assistant", or "Test".

The description is recommended to be written as "Who it helps and what it does", for example:

Helps development teams with code reviews, issue localization, and refactoring suggestions.
Helps SREs analyze alert impact scope, investigate clues, and provide next-step handling suggestions.
Helps testing teams generate test cases, organize regression scopes, and risk lists.

The avatar is used for quick identification of the Agent in lists and tasks. If the team has a fixed role system, it is recommended to keep the avatar consistent with the responsibilities.

Available Scope¶

The available scope determines which personnel can use the current Agent. It is recommended to follow the principle of "who needs it, who can use it".

Administrators and workspace owners are not restricted by the available scope and can view all Agents within the workspace.

When creating an Agent, the available personnel scope should be assigned based on workspace members, team division of labor, and the Agent's responsibilities and capability boundaries, to avoid granting usage permissions to members unrelated to the current Agent's work.

Optional scopes typically include:

All Members: Suitable for general-purpose Agents, such as knowledge Q&A, basic document organization, general observability analysis.
Specified Members or Roles: Suitable for Agents with permission boundaries or professional responsibilities, such as production troubleshooting, release checks, cost analysis, security analysis.

If the Agent can access sensitive data, internal systems, production environment tools, or external services, it is not recommended to open it to all members. It can first be opened to clearly needed roles, and then gradually expanded based on usage.

Agent Permissions¶

The permission settings for an Agent within a workspace are similar to those of ordinary users, controlled by Roles that define accessible features, data, and operational scope. By default, Agents use a read-only role, suitable for querying, analyzing, summarizing, and suggestion tasks. Users can adjust the Agent's role within the workspace according to actual usage needs, aligning its permissions with its responsibilities and operational boundaries.

Identity Definition¶

The identity definition is used to tell the Agent "who you are, who you serve, and how you should express yourself". It affects the Agent's collaboration style.

It is recommended to include the following:

Core Identity: The Agent's position or role.
Service Target: Which teams or members it primarily helps.
Typical Work Scenarios: Tasks suitable for it to handle.
Output Habits: Whether to use lists, conclusions, steps, risk warnings, or report formats in replies.

Example:

You are an intelligent operations Agent for SRE and operations teams.
You primarily help teams analyze alerts, locate anomalies, sort out impact scopes, and provide next-step handling suggestions.
In replies, prioritize giving current conclusions, key evidence, risk impact, suggested actions, and validation items that need to be supplemented.
If monitoring data, logs, traces, or change information is insufficient, first explain the missing context and propose the information that needs to be supplemented, do not draw conclusions directly.

Behavioral Boundaries¶

Behavioral boundaries are used to tell the Agent what it can do directly, what it must be cautious about, and what it cannot do. It is recommended to clearly write at least the following three types of boundaries:

Can Do Directly: Read-only queries, organizing materials, generating reports, summarizing risks.
Requires Confirmation or Approval: Modifying configurations, executing releases, deleting resources, sending external notifications.
Not Allowed: Bypassing approvals, accessing unauthorized data, leaking keys, fabricating evidence.