Deployment & Operations — How Agents Actually Run

Every domain so far explained what the pieces are. This page answers the architect's next question: where does this code physically run, who starts it, and how do you assemble it in an enterprise cloud project?

The five runtime forms — recognize which one a scenario implies

The first two run Claude Code itself; the last three run your own harness built on the Claude API or Agent SDK. That's the whole taxonomy — every "how do we ship this?" conversation starts by picking a row.

Headless mode — the agent with nobody at the terminal

Headless means Claude Code running non-interactively: you pass the prompt as an argument, it does the work, prints machine-readable output, and exits. Same engine, same tools, same CLAUDE.md loading — but no human to approve anything, which is why the flags below exist:

claude -p "Triage the new GitHub issues: label severity, close duplicates." \
  --output-format stream-json \
  --allowedTools "Read,Grep,Bash(gh issue:*)" \
  --max-turns 15

• -p (print mode) is the headless switch — prompt in, result out, exit code for the pipeline.
• --output-format json / stream-json makes the output parseable by the calling system (CI step, another program).
• --allowedTools is the deterministic leash: with no human watching, permissions are the gate — allowlist exactly what the job needs, nothing more.
• --max-turns is the budget: a runaway loop in CI burns money silently; the ceiling makes it terminal.

In a CI pipeline it's just a step:

# .github/workflows/triage.yml — an agent as a CI step
on:
  issues: { types: [opened] }
jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g @anthropic-ai/claude-code
      - run: |
          claude -p "Triage issue #${{ github.event.issue.number }}: apply severity label." \
            --allowedTools "Bash(gh issue:*)" \
            --max-turns 10
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

The API key comes from the pipeline's secret store — never from a file in the repo. This one YAML block is the entire "AI in CI/CD" story the exam gestures at.

The harness as a service — it's just a program

When the agent must serve users or systems (rows 3–5), you deploy your own harness: an ordinary containerized service that happens to call the Claude API. Nothing about it is exotic — it follows the same operational rules as any ordinary web service: config in the environment, logs to stdout, no state baked into the container.

# app.py — the support agent as a plain web service (FastAPI)
# shape-only sketch — production adds auth, a typed/validated request model, size limits, error handling
from anthropic import Anthropic
from fastapi import FastAPI

app = FastAPI()
client = Anthropic()                       # reads ANTHROPIC_API_KEY from the environment

@app.post("/support")
def handle(ticket: dict):
    result = run_agent_loop(client, ticket)   # the Domain-1 loop, verbatim
    return {"resolution": result.text, "state": result.terminal_state}

Containerize it, and every platform question becomes a standard one: where do containers run, where do secrets live, where do logs go. Which brings us to the concrete version.

Reference architecture — the support agent on GCP

The Domain-1 walkthrough's support agent, deployed for real on Google Cloud:

flowchart TD
  U[Customer email / chat] --> GW[API Gateway / webhook endpoint]
  GW --> PS[Pub/Sub topic: support-tickets]
  PS --> CR[Cloud Run: the harness container]
  SM[Secret Manager: ANTHROPIC_API_KEY] -.mounted at startup.-> CR
  CR -->|HTTPS: model calls| CAPI[Claude API — api.anthropic.com]
  CR -->|tool calls| SQL[(Cloud SQL: orders DB)]
  CR -->|tool calls| MCP[MCP server: internal customer-records CRM — Cloud Run service]
  CR --> LOG[Cloud Logging → BigQuery: traces, tokens, gate verdicts]
  SCH[Cloud Scheduler: nightly] --> EV[Eval job: golden set vs staging]
  EV --> LOG
  HITL[Approval queue: escalations UI] --- CR

The same shape on any cloud

The names change; the topology — queue in front, stateless harness container, secret store, single allowlisted egress, traces out — does not. (Amazon Bedrock (AWS) and Vertex AI (Google Cloud) — each cloud's own managed model service — add a variation: Claude is called through the cloud's endpoint instead of directly to api.anthropic.com — same harness, different base URL and cloud-IAM authentication (the cloud's own Identity and Access Management, instead of an Anthropic API key).)

Enterprise assembly checklist — what the architect signs off

1. Identity & secrets: API keys in the secret store, rotated; one service account per tool backend, least-privilege each.
2. Egress control: the harness can reach the Claude API and its tool backends — and nothing else. This single network rule is your strongest defense against exfiltration (smuggling data out): even a prompt-injected agent has nowhere to send it (Domain 3's layer 3, at the network layer).
3. Budgets as infrastructure: max-turns/cost ceilings in the harness AND platform quotas (Cloud Run concurrency, spend alerts) — two independent layers.
4. Observability first-class: per-run traces with correlation ids landing in a queryable store before launch, not after the first incident.
5. Evals in the deploy path: golden set green = deployable; a config/prompt/model change that can't turn the suite red proves nothing (Domain 5's negative controls).
6. HITL has a real surface: escalations land in a queue humans actually monitor, with an SLA — an unmonitored approval queue is a silent-failure machine.

🪤 Trap: "we need GPUs to deploy the agent" — no. Inference runs on Anthropic's side of the Claude API; your side is an ordinary container that makes HTTPS calls. The trap answer provisions infrastructure for a problem you don't have; the architect answer is the checklist above.