Production Deployment Guide

A working agent in the playground is not a production agent. This guide covers what it takes to deploy reliably.

Don’t skip this guide. The most common failure mode is deploying a “good enough” agent that breaks in edge cases real users hit within the first hour. Production readiness is a checklist, not a feeling.

The production readiness standard

Your agent is production-ready when:

It handles failures gracefully

When a tool fails, the agent explains what happened and offers a retry path — it doesn’t crash or hallucinate an answer.

Traces are meaningful

Every run produces a trace that tells you what happened, why, and how to fix it if something went wrong.

Memory works end-to-end

A user can come back hours later and the agent remembers the important context from their last session.

Limits are configured

Rate limits, cost caps, and usage limits are set before real users arrive — not after.

Deployment steps

Finalize your HiveLang definition

Your bot’s HiveLang file should be in version control. Every deployment should come from a committed file, not a manual edit in the UI.

bot ProductionBot {
  description: "Production support agent for AcmeSaaS"

  capabilities {
    knowledgebase.search
    billing.getSubscription
    support.createTicket
  }

  instructions {
    You are a production support agent for AcmeSaaS.

    Priority order for resolving requests:
    1. Search the knowledge base first
    2. If KB has no answer, check billing status
    3. If still unresolved, create a support ticket

    Rules:
    - Never guess — only assert what tools confirm
    - Always end with a next step
    - Escalate if the user is frustrated after 2 turns
  }

  before input {
    log info: "Production request: {input}"
  }
}

Configure environment variables

Set all required secrets in Settings → Environment Variables. Never hardcode them in HiveLang.

Variable	Used for
`OPENAI_API_KEY`	Model inference
`SLACK_BOT_TOKEN`	Slack channel
`TELEGRAM_BOT_TOKEN`	Telegram channel
`CUSTOM_API_KEY`	Your custom integration

Set rate limits

In your bot settings → Usage Limits:

Max runs/user/hour — prevent abuse
Max runs/day — protect your budget
Max tokens/run — cap response length and cost

Start conservative. You can loosen limits after observing real traffic.

Deploy to production

Using the dashboard:

Bot → Deploy → Production
Review the parse output for errors or warnings
Confirm deployment

Using the API:

curl -X POST https://api.bothive.cloud/v1/bots/{bot_id}/deploy \
  -H "Authorization: Bearer bh_sk_xxxxxxxxx" \
  -d '{"hivelang": "...", "environment": "production"}'

Deploy your first channel

Connect one channel and verify it end-to-end with real messages before adding more. Confirm:

Message delivery works
Session persistence works across 2+ messages
Tool calls succeed
Traces appear in the Runs tab

Set up monitoring

In Settings → Alerting, configure:

High error rate alert (>10% failures in 1 hour → notify via Slack or email)
Slow latency alert (P95 > 5s)
Tool failure spike (same tool fails 3+ times in 10 minutes)

Environment checklist

Before going live, confirm each item:

Check	Command / Location
All env vars set	Settings → Environment Variables
Bot deploys without parse errors	Bot → Deploy → check output
Playground passes all test cases	Bot → Playground
Rate limits configured	Settings → Usage Limits
One channel deployed and tested	Channels tab
Alerting configured	Settings → Alerting
Observability traces visible	Bot → Runs

Rollback strategy

If a production deployment breaks:

Identify the issue

Open Runs → filter by status: error → read the trace.

Roll back immediately

In Bot → Deployments, click the last stable deployment → Rollback. This takes ~10 seconds.

Fix in staging

Use a staging environment to fix the issue. Only redeploy to production when staging is verified.

Common production issues

Agent gives inconsistent answers

Increase instruction specificity. Add explicit rules for edge cases you’ve observed in traces. Consider lowering the model temperature.

Tool calls fail in production but work in staging

Production OAuth tokens may have different scopes or may have expired. Re-authenticate each integration in the production environment settings.

Memory not persisting between sessions

Check that you’re passing a stable X-Session-ID header (for API channel) or that the Telegram/Slack user IDs are consistent. Ephemeral memory clears after each session by design.

High latency on first message

This is usually cold-start on the integration layer. Add a before input hook that pre-fetches common data to warm up the context before the model runs.

Start Here

Getting Started

Core Concepts

Building Agents

Deployment & Operations

Teams & Organisations

Integrations

API Reference

Resources

Production Deployment Guide

Production Deployment Guide

The production readiness standard

It handles failures gracefully

Traces are meaningful

Memory works end-to-end

Limits are configured

Deployment steps

Environment checklist

Rollback strategy

Common production issues

Next reads

Deploy to Channels

Launch Checklist

Observability

​Production Deployment Guide

​The production readiness standard

It handles failures gracefully

Traces are meaningful

Memory works end-to-end

Limits are configured

​Deployment steps

​Environment checklist

​Rollback strategy

​Common production issues

​Next reads

Deploy to Channels

Launch Checklist

Observability

Production Deployment Guide

The production readiness standard

Deployment steps

Environment checklist

Rollback strategy

Common production issues

Next reads