Verify your Agent

Switch to the Organization that owns the Agent, then select the Agent card on Home.

The Agent detail page shows:

• The Agent name
• The configured model
• A Runtime badge
• A communication-platform badge
• The current status
• The lifecycle and configuration actions available to you
• The activity tabs permitted by your Agent Access Role

Confirm that the displayed name, model, Runtime, and platform match the choices you made while hiring.

The default Agent detail tab is Conversations. Users with activity permission also see Tool calls, Logs, and Work.

Review the status shown beneath the Agent's identity. Each state is labeled in text, so you do not need to rely on the badge color.

Agent Barn persists three Agent states — STOPPED, RUNNING, and ERROR — and presents them as Idle, Working or Initializing, and Needs attention. A failed health check may surface as Disconnected. Health is evaluated for Running or Error Agents when your account holds activity.read, and it refreshes periodically, so allow the Runtime time to create its resources and connect.

If the Agent is Idle, select Start. Starting the Agent:

• Renders the pinned Template
• Loads the pinned Skills
• Decrypts the required Runtime credentials
• Generates a fresh ingest identity
• Creates or refreshes its Runtime resources
• Connects to its configured communication platform

Expected: The Agent displays Working. Continue only once it does.

Optional Kubernetes check

Self-hosted operators can confirm that Agent resources exist in the production 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.

The Agent Barn UI remains the preferred place to associate a Runtime with its Agent and to inspect its logs.

Use an allowed shared channel or group for the first test, and confirm that:

• The Slack app is installed in the workspace and invited to the channel
• The Telegram bot is added to the group
• The Discord bot is invited to the server
• The location is allowed by the Agent's platform configuration
• You are permitted to interact with the bot

Send a deterministic prompt that explicitly mentions the bot:

@agent-bot Respond with exactly: verification-ok

Replace @agent-bot with the bot's actual Slack handle, Telegram username, or Discord mention.

Record the platform, the channel or group, the approximate send time, and the expected response.

Expected: The Agent returns verification-ok without invoking an unexpected Skill or tool.

Minor formatting differences do not necessarily indicate a connection failure. What matters is that the correct Agent received the request and produced one relevant response.

A reachable Agent must also ignore messages outside its intended scope. Run only the tests that apply to this Agent's configuration.

Verify mention gating

In the same shared location, send a new message without mentioning the Agent:

verification-no-mention

Expected: The Agent does not respond.

On Telegram or Discord, use a new group message for this negative test. Do not use a direct reply to the Agent's previous message, because platform reply behavior can differ from an unrelated unmentioned message.

Verify Slack thread behavior

If the Agent uses Slack:

1. Reply inside the verification thread without mentioning the Agent.
2. Confirm that it does not respond.
3. Send another thread reply with a fresh mention.
4. Confirm that it responds.

Slack requires a fresh explicit mention on every message. Participation earlier in a thread does not keep the Agent engaged automatically.

Verify an allowlist

If channel or group access uses an allowlist, run a negative test from a location that is not allowed. The test passes when the Agent does not respond.

Do not add the Agent to a sensitive or production channel solely to run this test. Use a temporary controlled location instead.

Return to the Agent detail page and open Conversations. If the verification exchange is not visible, reload the Agent page or reopen the tab after the platform response completes.

The sidebar groups activity into channels or groups and direct messages. Select the location used for the test, then confirm that the conversation contains:

• The inbound verification prompt
• The correct sender or platform identity
• The correct channel or direct-message location
• The outbound Agent response
• The expected occurrence times
• The correct thread grouping, where the platform supplied a thread

The positive test should show both directions:

Use the From and To filters if the Agent already has substantial conversation history.

Conversation telemetry proves that the Runtime reported the interaction back to Agent Barn. A platform reply with no corresponding Agent Barn activity indicates a telemetry or ingest problem.

Review Tool calls

Open Tool calls.

The first connection prompt should not require a tool, so for a new General Purpose Agent No tool calls yet can be the correct result.

If the Agent has an assigned Skill, run a separate read-only test appropriate to that Skill. 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.

Tool calls can be filtered by tool name, status, start date and time, and end date and time.

Expand a Tool call to review its arguments and result, then confirm that:

• The expected tool was selected
• The call stayed inside the requested scope
• No unexpected write operation occurred
• The result matches the platform or integration response

Treat Tool-call arguments and results as potentially sensitive operational information.

Review Logs

Open Logs. While the Agent is running, the page shows Live logs, and it reports Streaming once the stream is connected.

Review the lines around:

• Runtime startup
• The platform connection
• The verification request
• Any Tool-call failure
• Health or credential errors

Expected: The Runtime starts with no unresolved error, and the test request produces no repeated connection, authentication, or crash messages.

When an Agent is stopped, Agent Barn may show saved log snapshots from earlier Runtime sessions. Earlier snapshots load as you move toward the beginning of the log history.

Platform routing determines who can communicate with the Agent through Slack, Telegram, or Discord. Agent Access determines who can open and operate the Agent inside Agent Barn.

If you have access-management permission, select 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 in the Share dialog.

Review direct access

The Agent creator should appear with explicit Agent Owner access. Review every additional direct assignment:

For an observer helping with verification, Agent Viewer is normally sufficient.

Test access with another member

Where possible, use a separate accepted Organization Member account and verify one of these intended outcomes:

• A member with neither direct nor General access cannot discover or open the Agent
• A member with Agent Viewer access can inspect the Agent and its activity, but cannot start, pause, or configure it
• A member with Agent Editor access can manage configuration and lifecycle, but cannot manage sharing
• A member with Agent Owner access can manage sharing and deletion

If General access is changed to All Organization Members, choose the Agent Access Role that all current and future accepted members should receive. Keep Restricted access unless broad Organization-wide visibility is intentional.

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

Organization Owners and Organization Administrators can open Costs from the Organization navigation. The page is titled Usage & Billing. The current Organization cost dashboard is limited to those two roles.

Under Agent breakdown, locate the verified Agent. Once it has completed a model request, confirm that the row attributes:

• The correct Agent
• Its current cost-facing status
• The configured model
• Input tokens
• Output tokens
• Total cost

Expand the Agent row to review its per-model breakdown where one is available.

Cost reporting follows a separate path from activity:

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

Costs come from LiteLLM and are not calculated from Conversations or Tool calls. An Agent can therefore show conversation telemetry while cost reporting remains unavailable because LiteLLM reporting is not configured. A deployment without a per-Agent LiteLLM key may show no Agent cost row, or zero-valued cost data.