feat(harness): support Runtime network configuration

[zakahan]

Summary

Add Runtime network configuration support to Harness deployments.

This change lets users select the network mode and provide VPC-related settings when agentkit deploy --harness creates a new Runtime. The CLI forwards the settings through the Harness deployment layer and into the cloud launch configuration consumed by the Runtime creation path.

Motivation

Harness deployments currently rely on the platform's default Runtime network configuration. That is insufficient for agents that must:

• run only inside a private VPC;
• attach to specific subnets;
• expose both public and private network access; or
• use shared internet egress from a private network.

Users need to express these settings at deployment time without manually modifying the generated launch configuration.

What changed

CLI options

agentkit deploy --harness now accepts:

• --runtime-network-mode: Runtime network mode (public, private, or both);
• --runtime-vpc-id: VPC ID used by private or combined networking;
• --runtime-subnet-id / --runtime-subnet-ids: repeatable subnet ID option;
• --runtime-enable-shared-internet-access and its negative form, --no-runtime-enable-shared-internet-access.

The options are Harness-specific. Passing any of them without --harness returns a CLI parameter error instead of silently ignoring the values.

Configuration flow

The deployment path collects the explicitly supplied values into a runtime_network mapping and passes it through build_agentkit_config. Empty network configuration is omitted, preserving the existing launch configuration for users who do not opt in.

The generated cloud section can now contain a structure such as:

{
  "runtime_network": {
    "mode": "private",
    "vpc_id": "vpc-123",
    "subnet_ids": ["subnet-a", "subnet-b"],
    "enable_shared_internet_access": true
  }
}

The cloud runner consumes this mapping when creating the Runtime and converts it to the platform-specific public/private network fields.

Create-versus-update behavior

Runtime network configuration is applied only when creating a Runtime. If deployment resolves a name collision to an update of an existing Runtime, the command fails with an actionable error explaining that the existing Runtime must be deleted and recreated to change its network configuration.

This avoids accepting settings that the update/version path cannot apply.

Example

agentkit deploy \
  --harness my-agent \
  --runtime-network-mode private \
  --runtime-vpc-id vpc-123 \
  --runtime-subnet-id subnet-a \
  --runtime-subnet-id subnet-b \
  --runtime-enable-shared-internet-access

Compatibility

• Existing Harness deployments are unchanged when no network options are provided.
• Non-Harness deployment behavior is unchanged, apart from rejecting Harness-only network flags explicitly.
• The build_agentkit_config API remains backward compatible because runtime_network is optional and defaults to None.

Validation

• UV_CACHE_DIR=/tmp/uv-cache uv run --no-sync --with pytest python -m pytest tests/toolkit/cli/test_cli_deploy_harness_network.py — 4 passed
• Ruff checks passed for all four changed files.
• git diff --check upstream/main...HEAD passed.

The tests cover CLI forwarding, rejection without --harness, inclusion of an explicit network mapping, and omission of empty network configuration.