Enterprise early access is open. Request access

Docs Setup Get started

Install AgentFleetGateway and send your first request.

This guide takes a platform team from the versioned release bundle to a healthy control plane and a governed agent request.

1. Confirm prerequisites#

  • An existing AKS, EKS, or GKE cluster running Kubernetes 1.27 or later, with permission to install CustomResourceDefinitions.
  • Helm 3 and kubectl configured for the target cluster.
  • The az, aws, or gcloud CLI when your platform team has not already supplied a kubeconfig context.
  • The AgentFleetGateway release bundle provided during onboarding and access to its image registry.
  • An enforcing Kubernetes NetworkPolicy provider when using the protected model path.

Connect kubectl to the managed cluster you intend to validate:

az aks get-credentials \
  --resource-group <resource-group> \
  --name <cluster>
aws eks update-kubeconfig \
  --region <region> \
  --name <cluster>
gcloud container clusters get-credentials <cluster> \
  --region <region> \
  --project <project>
kubectl config current-context
kubectl cluster-info
kubectl get nodes

Your onboarding materials contain the Helm chart, CRDs, versioned image values, checksums, and example resources used below. Deployment profiles are included inside the chart package.

2. Verify the release bundle#

Use the checksum and signature instructions supplied with your release before installing it. Keep the digest-pinned image values with the chart so Kubernetes pulls the reviewed images rather than mutable tags.

sha256sum --check SHA256SUMS
tar -xzf agentfleet-<version>.tgz

ls agentfleet/Chart.yaml \
   agentfleet/profiles/local-durable.yaml \
   agentfleet-images.values.json \
   crds/ examples/

3. Configure private registry access#

Skip this step when your cluster already has access through workload identity or a platform-managed registry integration.

kubectl create namespace agentfleet-system

kubectl create secret docker-registry agentfleet-registry \
  --namespace agentfleet-system \
  --docker-server=<private-registry> \
  --docker-username=<username> \
  --docker-password=<access-token>

4. Install the CRDs and control plane#

For a guided evaluation on your managed cluster, start with local-durable. It enables policy, Context, Approval, Console, and a single-node PostgreSQL database with sample rules for the supplied evaluation agents.

kubectl apply -f crds/

helm upgrade --install agentfleet ./agentfleet \
  --namespace agentfleet-system --create-namespace \
  -f agentfleet/profiles/local-durable.yaml \
  -f agentfleet-images.values.json \
  --set global.imagePullSecrets[0].name=agentfleet-registry
Choose the right profile

local-durable sets registry.operatorWritesAreApprovals=true when its file is passed, as the commands below do on a new install, which takes the Operator’s publish of each agent as its approval, so steps 6 and 7 below should route (read from the chart and the Registry code; this quickstart has not been run end to end on a cluster for this change). A local-durable release installed before this change and upgraded with --reuse-values keeps its old values: its new agents are pending and steps 6 and 7 do not route until the upgrade adds --set registry.operatorWritesAreApprovals=true or passes the profile with -f. A shared install on enterprise-baseline does not set it: there an applied agent stays pending and the request in step 7 does not route until a decision is recorded; the approval routes of issue #727 are only a first slice in the Registry, off by default and not enabled by the chart. local-durable is an evaluation shape, not a production database. For shared AKS, EKS, or GKE environments, layer enterprise-baseline with external PostgreSQL and your own policy rules by following Install with Helm. Add mesh-ready for Istio or protected-path for managed workload identity and router-only model egress. The local-durable profile sets gateway.config.auth.allowUnregisteredCallers=true itself: the Gateway’s default auth mode, off, admits any caller and is for local development only, so it suits this evaluation. A shared install chooses gateway.config.auth.mode=entra_app or oidc_jwt; the install page shows the flags and says what each mode does not check.

5. Verify service readiness#

kubectl get pods -n agentfleet-system

kubectl port-forward -n agentfleet-system \
  svc/agentfleet-gateway 8080:8080

In another terminal, check the dependency-aware readiness endpoint:

curl -s http://127.0.0.1:8080/readyz

The response should report ready. Optional modules may report disabled; required modules must not report unavailable.

6. Onboard an agent#

Review the supplied evaluation manifests before applying them. They create deterministic agents, capability routes, and policies for the retail and enterprise-it tenants.

kubectl create namespace agentfleet-demo
kubectl apply -f examples/demo-agents/manifests/

The Registry records of these agents are pending until approved. local-durable turns on registry.operatorWritesAreApprovals on a new install, which takes the Operator’s publish as the approval. On a profile that does not, such as enterprise-baseline, step 7 does not route until a decision is recorded; the approval routes of issue #727 are only a first slice in the Registry, off by default and not enabled by the chart.

Verify 
kubectl get agents,agentroutes,agentpolicies -n agentfleet-demo

7. Send a governed request#

curl -s http://127.0.0.1:8080/v1/run \
  -H 'Content-Type: application/json' \
  -d '{"tenant":"retail","capability":"refund-processing",
       "input":{"message":"check refund eligibility for order 123"}}'

The response identifies the selected agent and includes routing and policy metadata. A policy_denied response means the control plane is enforcing policy but the supplied rule does not match the request.

8. Continue the rollout#