Run the sandbox demo
Install the evaluation fleet from your onboarding bundle and send a governed request end to end without connecting a payment, ticketing, or model provider.
What you will prove#
The sandbox installs three deterministic evaluation agents and routes a refund request to one of them. The point is not that an agent answers — it is what the control plane does around the answer:
- The gateway selects an agent by capability, and refuses to route to an unhealthy one.
- Policy evaluates the request before the agent runs.
- The agent's attempt to move money comes back as a governed intent, never an execution.
- Every decision emits audit evidence without capturing the payload.
The demo agents return canned, deterministic responses. Nothing here calls Stripe, SAP, or a model provider, so it runs without third-party credentials.
Before you begin#
You need the AgentFleetGateway onboarding bundle, kubectl, Helm 3, registry access, and a running Minikube cluster. Give the cluster at least 6 GB of memory for the control plane and evaluation agents.
minikube start --memory=6144 --cpus=4
kubectl get nodes
Install the demo#
-
Verify the supplied artifacts#
Use the chart and versioned image values from your onboarding bundle.
sha256sum --check SHA256SUMS ls agentfleet-<version>.tgz agentfleet-images.values.jsonVerifyThe checksum command completes without a mismatch.
-
Install the control plane and demo fleet#
This installs the CRDs, the control plane, and an
agentfleet-demonamespace holding the refund, order, and IT support agents with their routes and policies.kubectl apply -f crds/ tar -xzf agentfleet-<version>.tgz helm upgrade --install agentfleet ./agentfleet \ --namespace agentfleet-system --create-namespace \ -f agentfleet/profiles/local-durable.yaml \ -f agentfleet-images.values.json \ --set console.enabled=true \ --set console.config.defaultTenant=retail \ --set console.inventory.kubernetes.enabled=true \ --set console.demoCatalog.enabled=true kubectl apply -f examples/demo-agents/manifests/VerifyPods reach
Runningand the agents reportReady:kubectl get pods -n agentfleet-system kubectl get agents -AA restart or two on first install is expectedServices start before PostgreSQL is accepting connections and retry until it is, so a low restart count on a fresh install is normal. Sustained
CrashLoopBackOffis not — see Troubleshooting. -
Send a governed request#
Port-forward the gateway, then ask for a capability rather than naming an agent. Choosing the agent is the gateway's job, not the caller's.
kubectl port-forward -n agentfleet-system svc/agentfleet-gateway 8080:8080 & curl -s http://127.0.0.1:8080/v1/run \ -H 'Content-Type: application/json' \ -d '{"tenant":"retail","capability":"refund-processing", "input":{"message":"refund order 123"}}'# Global flags (tenant, gateway) come before the command. agentfleetctl --tenant retail \ --gateway http://127.0.0.1:8080 \ run --capability refund-processing \ --input 'refund order 123'Trimmed to the fields that matter, the response looks like this:
{ "agent": { "name": "refund-agent", "runtime": "langgraph" }, "route": { "mode": "capability", "reason": "Matched healthy agent by capability." }, "output": { "status": "denied", "toolCalls": [ { "name": "stripe-refunds", "action": "create_refund_intent", "status": "intent" } ] } }What this provesThe agent asked to move money and the control plane held it.
"status": "intent"on the Stripe call is the whole thesis in one field — the tool call was recorded and governed, never executed.route.reasonshows the selection was explainable rather than arbitrary. -
See the same decision in the Console#
The Console shows the request from the operator's side: which agent served it, what policy decided, and what evidence was emitted.
kubectl port-forward -n agentfleet-system svc/agentfleet-console 8089:8089 & open http://127.0.0.1:8089
Try the interesting failure#
The demo is more convincing when you make it say no. Ask on behalf of a tenant no policy covers:
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/v1/run \
-H 'Content-Type: application/json' \
-d '{"tenant":"unknown-tenant","capability":"refund-processing",
"input":{"message":"refund order 123"}}'
You get 403 and policy_denied. The request never reached an agent. That is policy
working, not an error — Write a policy that allows traffic explains
how the allow list is built.
What got installed#
See it in Grafana#
The steps above are enough to prove routing. If you want to watch it instead — request rates, audit events, model cost — layer the optional observability profile onto the same install. It packages Prometheus, Grafana, and ClickHouse, with two dashboards provisioned automatically:
helm upgrade agentfleet ./agentfleet \
--namespace agentfleet-system \
-f agentfleet/profiles/local-durable.yaml \
-f agentfleet/profiles/demo-observability.yaml \
-f agentfleet-images.values.json \
--set console.enabled=true
kubectl -n agentfleet-system port-forward svc/agentfleet-demo-grafana 13000:3000
Open http://localhost:13000 (admin / agentfleet-demo) and re-run
the governed request from step 3. Both dashboards update live. Details on what each one shows —
including policy decisions and audit delivery — are in Operations.
Helm recalculates values during an upgrade. Pass the base profile, observability profile, and digest-pinned image values together. The bundled single-node PostgreSQL database is suitable only for this sandbox; see Profiles for shared-environment deployment options.
Clean up#
kubectl delete -f examples/demo-agents/manifests/ --ignore-not-found
helm uninstall agentfleet --namespace agentfleet-system
kubectl delete namespace agentfleet-demo --ignore-not-found
Where to go next#
- Write a policy that allows traffic — turn default-deny into a working allow list.
- Require approval for an action — make that refund wait for a human.
- Operations — the Grafana dashboards, Usage Center, and Approval Inbox in full.
- Architecture — what happened between the request and the response.
- Install with Helm — move off the demo profile onto a real cluster.