Create an Agent¶

Creating an Agent involves defining its responsibilities, entering basic information, choosing a deployment method, and installing its runtime service. After installation, the Agent connects to the current workspace and team members can open its workspace from the Agent list.

Only workspace Owners and administrators can create Agents. Before you begin, define who the Agent serves, its primary responsibility, and the access it requires.

Step 1: Start Creating¶

Open the Agent list and select New Agent in the upper-right corner. Choose one of these starting points:

• Describe your needs: Explain the role, intended users, common tasks, and expected behavior in natural language. The system generates recommended configurations that you can select and adjust.
• Quick start: Choose a preset Agent close to your use case.
• Create a blank Agent: Skip recommendations and configure basic information directly.

Recommendations and presets reduce initial setup work, but review the responsibilities, access, and behavior boundaries before creation so they match your team's actual requirements.

Step 2: Configure Agent Information¶

Configure the Agent name, availability, description, identity, and behavior boundaries. The goal is not to list every possible capability. It is to make clear what the Agent is responsible for, who it serves, what it may do, and when it must stop and request human confirmation.

Name and Description¶

Choose a name that lets team members recognize the responsibility quickly, such as "Development Review Assistant," "Observability Troubleshooting Agent," or "Release Readiness Agent." Avoid names such as "My Agent," "Assistant," or "Test" that do not distinguish the use case.

Write the description as "who this helps and what problem it solves," for example:

• Helps developers review code, locate issues, and prepare refactoring recommendations.
• Helps SRE teams summarize alert impact, investigation evidence, and recommended next steps.
• Helps QA teams generate test cases, organize regression scope, and identify risks.

The avatar makes the role easier to recognize in the Agent list and tasks. If the team uses a consistent role system, align the avatar with the responsibility.

Availability¶

Availability determines which members can use the Agent. Follow the least-access principle:

• All members: Suitable for shared knowledge, documentation, and general analysis Agents.
• Selected members or roles: Suitable for production troubleshooting, release checks, cost analysis, security analysis, or other Agents with restricted access.

If the Agent accesses sensitive data, internal systems, production tools, or external services, begin with the members who need it and expand availability gradually.

Identity¶

The identity explains the Agent's role, intended users, typical scenarios, and expected output. Include at least:

• The role or primary responsibility.
• The team members it serves.
• The tasks it is suited to handle.
• The expected tone and output structure.

Example:

You are an operations Agent for SRE and infrastructure teams.
You help analyze alerts, locate anomalies, assess impact, and recommend next steps.
Lead with the current conclusion, key evidence, risk and impact, recommended actions, and remaining validation.
If monitoring data, logs, traces, or change information are insufficient, state what is missing and ask for the required context instead of reaching a conclusion.

Behavior Boundaries¶

Behavior boundaries state which actions may be performed directly, which require confirmation, and which are prohibited. Cover at least:

• Allowed directly: Read-only queries against authorized data, information organization, report generation, and risk summaries.
• Require human confirmation: Configuration changes, releases or rollbacks, scaling, deleting resources, and formal external notifications.
• Prohibited: Bypassing approval, accessing unauthorized data, exposing secrets or private information, and inventing conclusions when evidence is insufficient.

For production, permissions, security, and customer communication, make confirmation conditions and prohibited actions specific enough to evaluate.

Step 3: Confirm Creation¶

Review the Agent name, description, and deployment information on the confirmation page. Agents use a self-hosted runtime, so your team manages the runtime environment, network access, permission policies, and dependencies.

After confirmation, the system generates an installation command for this Agent. Do not create another Agent while waiting for the command; stay on the page or retrieve the command later.

Step 4: Install the Agent Runtime¶

Choose Linux Installation or Container Installation for the target environment.

Linux Installation¶

1. Prepare a Linux host or virtual machine that can access Obsy Agent Teams.
2. Choose whether to enable Agent Self-Observability Collection. When enabled, the workspace can receive and display observability data from the Agent runtime.
3. Select Linux Installation and copy the generated installation command.
4. Sign in to the target host or virtual machine and run the command.
5. Wait for the Agent to connect to the current workspace.
6. Select Done, return to the Agent list, and check its latest status.

Container Installation¶

1. Select Container Installation and copy the connection settings shown on the page.
2. Open Agent Container Installation and choose Docker, Kubernetes YAML, or Helm for your environment.
3. Follow that guide to start the image and configure persistent storage and the connection. Copying the connection settings alone does not start the Agent.
4. After the Agent connects, select Done, return to the Agent list, and check its latest status.

If you do not install the Agent immediately or need to retrieve the command again, open the Agent workspace and go to Agent Info > Runtime & Deployment. This area is visible only to users with Agent management permission.

Step 5: Open the Agent Workspace¶

After installation and connection, return to the Agent list, locate the Agent, and select Open Workspace. From the workspace, you can create or continue tasks and configure Skills, MCP services, Automation, Task Intake, Agent Collaboration, and Message Channels for its responsibilities.

If the Agent status is abnormal, check:

• Whether the target host can access Obsy Agent Teams.
• Whether the installation command belongs to this Agent.
• Whether host time, proxy, or firewall policies affect the connection.
• Whether system security, process management, or container policies block the runtime.
• Whether related credentials have expired, been revoked, or reset after exposure.

Configuration and Deployment Recommendations¶

• Give one Agent one primary responsibility; create separate Agents for substantially different roles.
• Define identity and behavior boundaries before adding Skills, MCP services, or Message Channels.
• Deploy the Agent in a controlled environment that can access the required tools and data sources.
• Use team-managed hosts for production-related Agents and limit their network and credential permissions.
• Share installation commands, API keys, platform credentials, secrets, and tokens only with authorized users.
• Review unused Agents and runtime services regularly and disable or remove them when appropriate.