Verify your Agent

Review the configuration before testing anything operational. Open the Agent, then confirm:

• The intended Organization owns the Agent
• The intended Hermes or OpenClaw Runtime is selected
• The intended Template and exact Template Version are pinned
• Required Skill Versions are assigned
• Required tool Integration credentials are configured
• Agent Access is appropriate
• Agent General Access remains Restricted, unless broader Organization access was intentionally configured
• The model follows the Organization default or pins the intended explicit model

Make sure you understand the effective model: the model the Agent resolves to right now. If the Agent is already running, the displayed running model may differ from the currently effective model until the Agent restarts.

If anything here is wrong, correct it in Configuration before continuing. See Hire your first Agent for how these choices were made.

Inspect the Agent's lifecycle state on its own, before considering communication. Agent Barn persists three states.

The interface presents these as operator-facing labels such as Idle, Initializing, Working, Disconnected, and Needs attention. The underlying meanings above do not change.

How an Agent arrives at a state:

• Agent creation first persists a headless STOPPED Agent.
• The web hiring flow may issue a separate start operation immediately afterward.
• Starting renders the pinned configuration and creates Runtime Kubernetes resources.

If the Agent is stopped and you hold lifecycle permission, select Start. See Manage the Agent lifecycle.

This check applies whether or not the Agent has any Connections.

1. Confirm the Agent is in the active running state.
2. Open the Agent health surface.
3. Confirm the Runtime health endpoint is reachable.
4. Review recent Runtime logs for startup or execution errors.
5. Confirm the configured Runtime image was pulled.
6. Confirm Kubernetes created the expected Deployment, Service, Secret, ConfigMap, and PVC, where those details are exposed.
7. Confirm the effective configuration rendered without missing Template, Skill, model, or Integration requirements.

Expected: Runtime health is reachable and the startup sequence completes without an unexplained failure.

Runtime logs primarily diagnose:

• Template rendering
• Skill materialization
• Integration configuration
• Model access
• Kubernetes startup
• Runtime execution
• Local Runtime request processing

Runtime logs are not the canonical source for provider Connection health or Communication Delivery history. Use the Connection surface for those. See Review Agent health and logs.

Optional Kubernetes check

Self-hosted operators can confirm that Agent resources exist in the namespace:

kubectl get pods \
  --namespace agent-farm \
  --selector agentbarn.io/component=agent

For staging, use the configured staging namespace, commonly agent-farm-staging. The relevant Agent pod should be running and ready.

When provider messaging is being tested, inspect the specific Connection rather than the Agent as a whole. Confirm:

• The intended Connection belongs to this Agent
• The intended Platform Plugin is selected
• The Connection is enabled
• Provider credentials were accepted
• The provider application or bot is installed in the intended location
• The Connection's routing and admission settings allow the intended location and user
• The Connection does not show an unresolved provider health error
• The provider-side scopes, permissions, events, intents, channel configuration, or webhook are complete

Connection health is independent of Agent lifecycle. A running Agent can hold one healthy Connection and one failing Connection at the same time, and each is diagnosed on its own.

For provider-side completeness, use the guide for your Platform: Slack, Microsoft Teams, Telegram, or Discord.

Use a controlled provider location.

1. Confirm the Agent Runtime is running.
2. Confirm the Connection is enabled.
3. Send a message from an allowed user in an allowed location.
4. Include an explicit mention when required by the Connection policy.
5. Wait for the Agent's response.
6. Confirm the reply arrives through the same provider application and Connection.

Use a deterministic prompt:

@agent-bot Respond with exactly: verification-ok

Replace @agent-bot with the provider-side handle of the application attached to this Connection.

Expected: the Agent returns verification-ok in the same location, through the same Connection.

Admission behavior differs by Platform and by Connection policy:

• Shared spaces may require an explicit mention.
• Direct messages may be off, open, or allowlisted.
• Slack thread behavior depends on the Connection's thread mention policy.
• Discord server messages may be narrowed by server, channel, user, role, and mention settings.
• Microsoft Teams and Telegram retain their provider-specific admission rules.

Record the Connection, the location, the approximate send time, and the expected response. Minor formatting differences do not indicate a delivery failure; what matters is that the correct Agent produced one relevant response on the expected Connection.

A reachable Agent must also ignore what its policy excludes. Test one deliberately blocked case that applies to this Connection, such as:

• A location outside the allowlist
• A user outside the user or role policy
• A direct message when direct messages are off
• An unmentioned shared-space message when mention gating applies

For the mention case, send a new message in the shared location without mentioning the Agent:

verification-no-mention

Expected: the Agent does not respond.

What should happen behind that silence:

• A policy-rejected provider payload does not create a canonical inbound Conversation Message.
• Operational diagnostics may record a content-free policy disposition.

Return to the Agent and check that the exchange was recorded where you expect it.

1. Open Agent Activity.
2. Open Conversations.
3. Select the expected Communication Connection and provider location.
4. Confirm the allowed inbound message appears.
5. Confirm the outbound Agent response appears in the same conversation.
6. Confirm sender and location names, where provider enrichment is available.
7. Confirm the blocked test did not become a canonical Conversation Message.

How Conversation identity works:

• The Communications Gateway writes canonical Conversation Messages.
• Conversation identity includes both connection_id and provider channel_id.
• Two Connections can safely use the same provider channel identifier.
• Replies remain bound to the source Connection.
• Conversation persistence is not written through Ingest.

If the reply arrived in the provider but no Conversation appears, treat it as a Communications or permission question, not a Runtime telemetry question. See Review Agent activity.

Tool Calls follow a different path from Conversations.

• Hermes or OpenClaw reports Tool Call telemetry through Ingest.
• Ingest authenticates with Agent identity and a per-start Ingest key.
• Tool Calls use Runtime invocation identity for correlation.
• A request that invokes no tool is not expected to create a Tool Call.
• A successful chat reply does not guarantee that a Tool Call should exist.

So No tool calls yet can be the correct result for a first verification prompt. To verify the path itself, send a controlled request that is expected to invoke one configured tool, then open Tool calls.

Prefer a read-only request. Avoid creating, updating, deleting, sending, or publishing external data during initial verification: for example, ask a repository-enabled Agent to list an allowed repository rather than to modify it.

Confirm that:

• The Tool Call appears under the correct Agent
• The tool name is expected
• The status reaches the expected terminal state
• The result is correlated to the intended invocation
• No unexpected write operation occurred

Review a failure as an Integration or Runtime problem first, rather than automatically as a Connection problem. Treat Tool Call arguments and results as potentially sensitive operational information.

Two access surfaces exist, and verifying one says nothing about the other:

• A Communication Connection's admission policy determines who can talk to the Agent through a provider.
• Agent Access determines who can open and operate the Agent inside Agent Barn.

If you have access-management permission, open Share on the Agent page and confirm that General access matches the intended policy. New Agents default to:

Restricted

With Restricted access, only users with direct Agent Access can open the Agent. Organization Owners and Organization Administrators retain implicit full authority over every Agent, and they are not listed as direct assignments.

The Agent Creator should appear with explicit Agent Owner access. For an observer helping with verification, Agent Viewer is normally sufficient.

Optional This check applies only when LiteLLM cost reporting is configured.

Organization Owners and Organization Administrators can open Costs from the Organization navigation. Under the Agent breakdown, locate the verified Agent and confirm the row attributes the correct Agent, model, tokens, and total cost.

Cost reporting follows a separate path:

Agent model request
        ↓
LiteLLM
        ↓
LiteLLM key identity
        ↓
Agent Barn cost attribution

• Costs come from LiteLLM reporting.
• Costs are attributed through the Agent's LiteLLM key identity.
• Conversation Messages and Tool Calls do not calculate cost.
• A Conversation can exist before cost reporting appears.
• Tool Call state does not prove that LiteLLM cost ingestion is healthy.

See Review costs for the full reporting model.