When people talk about Claude agents, they usually talk about the model. That matters, but it is only half the architecture. The better platform question is: where should the agent harness run?

The harness is the part that actually does work. It holds the session, runs commands, edits files, calls tools, and reaches the systems the task depends on. If that harness runs on a laptop, it inherits laptop problems: sleep, VPN drift, local secrets, local network shape, and whatever happens to be installed that day.

This series explores a different pattern: keep the model call with Anthropic, Bedrock, or Vertex, but run the Claude agent harness on Tanzu Platform. The agent becomes a CF app with routes, logs, health checks, egress controls, service bindings, quotas, and lifecycle managed by the platform you already operate.

This is Part 1 of a three-part Claude-on-Tanzu series. It explains why Tanzu Platform is a compelling runtime for Claude agents, then shows the container shape I used. Part 2 turns that image into a remote-control worker you can drive from Claude mobile or claude.ai. Part 3 wraps the Claude Agent SDK as an internal HTTP service for CI, triage, chat, and platform workflows.

Why Tanzu is a great host for an agent

An autonomous agent is an unusual workload — it runs commands and makes network calls on its own. The interesting question isn't "can I run the container" (anything runs a container); it's "can I give the agent the right guardrails using machinery I already operate?" On Tanzu Platform, the answer is yes, and it's already there:

  • One cf push is the whole deploy. App, route, health check, logging, scaling — the same workflow you use for every other app.
  • Application Security Groups give you per-space egress control. You decide exactly which endpoints the agent can reach.
  • Diego containers isolate each session by default — userns remap, seccomp, AppArmor, dropped capabilities — no extra YAML; you start from the blueprint of a sandbox by default.
  • Volume services give an agent durable, per-session state with a single cf bind-service (great write-up on enabling that here).
  • CredHub-backed bindings keep tokens encrypted at rest instead of pasted into a manifest.

The main takeaway: Tanzu Platform is already giving you the fundamentals of a strong agent runtime. The agent inherits the governance, logging, identity, networking, isolation, and lifecycle model your platform team already runs. There's no new control plane to certify — it's a CF app.

What this gives an organization

This pattern is useful when an org wants AI-assisted work without moving the execution environment out of its platform boundary. Developers still get a capable agent, but the organization keeps familiar controls around where commands run, what network paths are allowed, how logs are collected, and how secrets are bound.

Concern Tanzu control Why it matters for agents
Network reach Application Security Groups Limit the agent to approved APIs, repos, registries, and model endpoints.
Secrets Service bindings / CredHub Keep tokens out of images, prompts, and copied local config files.
Operations cf logs, routes, scale, quotas Run agents like apps instead of introducing a separate runner platform.

One image, two operating modes

Now that the use case is clear — run the Claude harness inside the platform boundary — the next question is how to package it for Tanzu Platform. I want one deployable artifact that can run in two shapes: an API service for apps and pipelines, or a remote-control runner for interactive work. That keeps the operational model simple even though the user experience changes.

I package the agent as a single container image and pick its behavior with one environment variable, SANDBOX_MODE. I used a Docker image here instead of trying to force this through a buildpack because the agent needs the Claude CLI, the Agent SDK dependencies, a known Node runtime, and a small entrypoint that can switch between API mode and Remote Control mode. A buildpack is great when the app shape is conventional; for this experiment, a tiny explicit image makes the moving parts visible.

I am not publishing the exact image I used, but the shape is straightforward. This is the kind of Dockerfile you can adapt for your own registry and policy:

FROM node:22-bookworm-slim

WORKDIR /workspace

RUN apt-get update \
  && apt-get install -y --no-install-recommends git ca-certificates openssh-client \
  && rm -rf /var/lib/apt/lists/*

RUN npm install -g @anthropic-ai/claude-code @anthropic-ai/claude-agent-sdk

COPY server.js /app/server.js
COPY entrypoint.sh /app/entrypoint.sh
RUN chmod +x /app/entrypoint.sh

ENV PORT=8080
ENV SANDBOX_MODE=api

EXPOSE 8080
ENTRYPOINT ["/app/entrypoint.sh"]

The entrypoint is the switchboard. In API mode it starts the small HTTP wrapper around the Agent SDK. In Remote Control mode it starts claude remote-control so you can drive the runner from Claude mobile or claude.ai:

#!/usr/bin/env bash
set -euo pipefail

case "${SANDBOX_MODE:-api}" in
  api)
    exec node /app/server.js
    ;;
  rc)
    exec claude remote-control \
      --name "${RC_SESSION_NAME:-tanzu-runner}" \
      --permission-mode bypassPermissions \
      --spawn same-dir
    ;;
  *)
    echo "unknown SANDBOX_MODE: ${SANDBOX_MODE}" >&2
    exit 1
    ;;
esac

With that one artifact, two shapes cover the use cases:

# API mode — a small HTTP service wrapping the Agent SDK.
# POST a prompt, stream the agent's work back as it happens.
SANDBOX_MODE=api

# Remote Control mode — runs `claude remote-control`, which you
# drive from claude.ai or the Claude mobile app.
SANDBOX_MODE=rc

Same artifact, same cf push, two very different experiences. API mode is for wiring an agent into an app or a pipeline. Remote Control mode is for driving one interactively from your phone while it executes inside your foundation.

The deploy is intentionally ordinary

The deployment should feel familiar to anyone who already operates Cloud Foundry: push the image, bind the network/security controls, optionally bind state, and let the platform own health, logs, and lifecycle. Cloud Foundry can stage buildpack apps and it can also run Docker images; in this case that means the Claude harness can be packaged explicitly, pushed quickly, and still consume the same services and platform controls as the rest of your apps.

cf push claude-agent \
  --docker-image <your-registry>/claude-on-cf:latest \
  --health-check-type http \
  --endpoint /healthz \
  -f manifest.yml

# lock egress to just what the agent needs
cf bind-security-group claude-egress <org> --space <space>

# give it durable state (optional)
cf bind-service claude-agent claude-state && cf restart claude-agent

A minute later you have a running Claude agent on a route, with egress you control and state you can keep. The important bit is how ordinary it feels: a Docker image, a cf push, a couple of bindings, and the agent is running inside the same platform boundary as the systems it needs to work with.

Three use cases — the rest of this series

Once the harness runs on your foundation, three patterns fall out naturally. The common thread is execution inside your four walls: the control surface can be hosted or mobile, but the worker runs near private repos, internal APIs, logs, package mirrors, and service credentials. If you already understand on-prem or private GitHub runners, this should feel familiar.

Each pattern gets its own post:

  • The self-hosted runner you drive from your phone. Think GitHub self-hosted runners, but for AI: claude.ai is the control plane, your CF container is where the work actually happens. Part 2 walks through that runner.
  • Internal AI tools that run near your systems. Wrap the Agent SDK in a tiny service and call it from your apps and pipelines — a code reviewer, an incident triager, a docs generator. Part 3 builds that service.
  • Governed Claude Code for developers. The same image gives your team Claude Code sessions that run inside a foundation your platform team operates — with the egress, logging, and identity already in place.

Why I think this matters

The pitch isn't "replace the hosted service" — the hosted Claude experience is excellent and I use it daily. The pitch is reach: many teams already standardize on Tanzu and want their agents to run where their governance already lives. The Agent SDK plus cf push meets them there. The agent becomes one more well-behaved app on the platform.

TL;DR

  • Anthropic provides the model; the Claude Agent SDK lets you run the harness on your own Tanzu foundation.
  • Tanzu gives an agent great guardrails out of the box: ASGs for egress, Diego for isolation, volume services for state, CredHub for secrets — all via cf push / cf bind-service.
  • One image, two modes: api (an HTTP service) and rc (Remote Control, driven from your phone).
  • Next up: Part 2 drives a runner from your phone; Part 3 builds internal AI tools around the SDK.