Operate workflow

AI Agent Deployment

The gap between an agent demo and an agent in production is not model quality, it is engineering. On a laptop, the agent has its author's credentials, full filesystem access, and a human watching every step; none of that survives contact with production. Our deployment process closes that gap deliberately: the agent gets the minimum permissions it needs and nothing more, secrets move out of prompts and env files into proper management, risky actions run sandboxed, an eval suite gates every change, and everything the agent does is observable and reversible. Outward-facing actions keep a human checkpoint until the record says otherwise.

Typical timeline

2-6 weeks depending on how many systems the agent touches and the state of the existing code

Stack

Claude Code and the Claude API · GitHub for versioning, review gates, and CI · Supabase or Postgres for state and audit logs · PostHog for tracing agent behavior in production · Slack for human checkpoints and alerts

What we need to start

  • · The working agent: code, prompts, and tool definitions as they run today
  • · An inventory of every system the agent touches, and what it is allowed to do in each
  • · Your risk lines: which actions are acceptable to automate, and which always need a human sign-off

How it works

  1. 01

    Permission scoping

    We map every tool call the agent can make against what it actually needs, then cut everything else: read-only where read-only suffices, scoped API keys instead of admin ones, per-tool allowlists instead of broad access. Most laptop agents run with their creator's full permissions, and that is the first thing that cannot ship.

  2. 02

    Secrets and configuration

    Credentials come out of prompts, code, and .env files and move into proper secret management with rotation, and the agent's runtime gets injected only the secrets its scoped role requires. We also check the uncomfortable places: prompt logs and conversation history are a common spot for a key to leak.

    Tools: GitHub

  3. 03

    Sandboxing

    Anything the agent executes runs inside a boundary: containerized execution, egress restrictions, and filesystem limits sized to the task. The design assumption is that the agent will eventually attempt something wrong, whether from a bad plan or a prompt injection riding in on external content, and the blast radius has to be bounded before that day, not after.

  4. 04

    Eval gates in CI

    The agent's key behaviors become an automated eval suite that runs on every prompt, tool, or model change; a change that regresses the suite does not deploy. This is the mechanism that makes iteration safe: without it, every improvement is a blind bet on not having broken something else.

    Tools: GitHub, Claude Code

  5. 05

    Observability and rollback

    Every run gets traced: which tools were called, with what arguments, what it cost, and where it failed, feeding dashboards and alerts on error rates and cost spikes. Deploys are versioned with a one-step rollback, because when an agent misbehaves in production you want it back on the last good version in minutes while you read the traces.

    Tools: PostHog, Supabase

  6. 06

    Human checkpoints for outward actions

    Anything that leaves the building, emails, posts, purchases, and customer-visible writes, routes through an approval step with full context in Slack. Autonomy on a category is widened only when the approval record shows the agent consistently getting it right, per action type, based on evidence rather than a launch date.

    Tools: Slack

You get
  • ✓ The agent deployed on production infrastructure with scoped permissions and managed secrets
  • ✓ An eval suite wired into CI as a deploy gate
  • ✓ Tracing, dashboards, alerts, and a tested one-step rollback
  • ✓ A runbook: incident response, permission map, and how to widen autonomy safely
When NOT to use this
  • · The agent does not reliably do its job on a laptop yet; deployment hardens behavior, it does not fix it
  • · The task is a deterministic pipeline in disguise; a plain workflow is cheaper, safer, and easier to debug than an agent
  • · No one on your team will own the agent in production; an unowned agent with real permissions is a liability, not an asset

Frequently asked

What usually breaks when an agent moves from laptop to production?

Permissions and inputs. On the laptop the agent borrowed its author's full access and saw curated inputs; in production the credentials must be scoped, and real-world inputs include malformed data and adversarial content the demo never faced. Most of this process exists to absorb exactly those two shifts.

Why sandbox an agent we already trust?

Because trust is not a security boundary. Agents ingest external content, and prompt injection means some of that content is effectively instructions from a stranger; the sandbox decides what a bad instruction can actually reach. You sandbox precisely so that trusting the agent day to day is reasonable.

When can the human checkpoints come off?

Per action type, when the approval record shows sustained correct behavior for that action, and typically never for the highest-stakes ones. Spending money and mass communication tend to keep their checkpoint permanently, and treating that as a feature rather than a limitation is the honest position.

Can you deploy an agent we built ourselves?

Yes, and it is a common engagement: the build is yours, the hardening is ours. We audit the existing code and permissions first, then run this same process on it. If the audit is really the part you need, that is our Claude Code security audit as a standalone.

Want this running in your business?

We build and run this workflow for clients.

Related services: AI agent development · Claude Code security audit · OpenClaw / NemoClaw enterprise setup

Free weekly brief

Steal this workflow

Get new teardowns like this one by email: the steps, the tools, and the honest failure modes. No spam, unsubscribe anytime.