Part 10

Interfaces

This page covers how clients and agents talk to each project: control plane APIs, A2A and MCP endpoints, tools and skills, model providers and credentials, and egress rules.

After this page you can:

List the APIs each control plane exposes.
Explain why a kagent agent is directly callable over A2A and MCP and an ax Task is not.
Configure model credentials and egress endpoints the way each project expects.

Control plane APIs

ax One gRPC service

The ax.v1alpha1.AX gRPC service has Get, List, Create, Delete, Suspend, Resume, and Watch for Tasks, and Get, List, Update, and Delete for Workspaces and Models.²
The ax CLI is deliberately kubectl-shaped and talks to the control plane over gRPC.¹
Inside the sandbox, an HTTP metadata server on port 80 serves /healthz, /readyz, and the Task and Workspace specs.⁵
With spec.debug: true, the same port serves Substrate guest services (process and file system) over gRPC, which ax ssh needs.⁵

kagent Four public surfaces

The Kubernetes API, for authoring Agents, Harnesses, AgentTemplates, SandboxTemplates, models, prompts, and remote MCP servers.⁹
gRPC and gRPC-Web, for Sessions, sharing, checkpoints, sandboxes, and control-plane reads.⁹
A2A, for invoking agents and managing durable tasks and streams.⁹
MCP, for discovering, invoking, checkpointing, and forking Sessions, and for standalone sandboxes.⁹

All four kagent surfaces are served on controller port 8083.¹⁰ The alpha6 CLI first checks the configured server. If that server is the default local endpoint and it is unreachable, the CLI runs kubectl -n <namespace> port-forward service/kagent-controller 8083:8083 itself. It does not port-forward when you set a different endpoint, a CA file, or a server name.²⁸

A2A and MCP endpoints

A2A (the agent-to-agent protocol) and MCP (Model Context Protocol) are the two protocols kagent exposes for agents. kagent does not maintain a parallel session or task API: A2A owns public interaction semantics, and the public A2A gateway exposes each Agent.⁹ In practice, other agents and MCP clients can call a kagent agent directly.

An ax Task has no built-in conversational endpoint. Requests reach a running Task through the Substrate atenet-router with the ate-target-actor header set to <atespace>/<task>, and anything conversational is whatever your image serves.⁷

kubectl -n ate-system port-forward svc/atenet-router 8001:80
curl -H "ate-target-actor: default/task123" http://localhost:8001/readyz

The commands above come from ax's networking doc and reach the readiness endpoint of Task task123 in atespace default.⁷

Tools, MCP servers, and skills

How each project gives an agent tools and skills
Capability	ax	kagent
MCP servers	ax: declared per Workspace, as static endpoints or registry queries such as `provider: google`.⁴	kagent: `RemoteMCPServer` resources shared across agents. kagent ships an MCP server with tools for Kubernetes, Istio, Helm, Argo, Prometheus, Grafana, Cilium, and others.⁸
Skills	ax: skill registries materialized to a path, such as `/.agents/skills`.⁴	kagent: skills and plugin bundles attached to the AgentTemplate.⁹
Repository checkout	ax: first-class, through `Workspace.spec.git`.⁴	kagent: No equivalent in the AgentTemplate. Harnesses keep workspaces and downloaded assets in `/data`.¹⁰
Environment bootstrap	ax: the Workspace binding's `goal` field, which `ax-task-runner` hands to an Antigravity agent (Google's coding agent) on first boot. It needs `GEMINI_API_KEY` and has 10 minutes by default.⁵	kagent: No equivalent documented for agents. SandboxTemplate carries a preparation policy for standalone sandboxes.⁹

ax optimizes for every Task starting with the right repositories and tools already in place.³ kagent optimizes for agents that share tool servers and call each other.⁸

Models and credentials

Both projects read model credentials from a Kubernetes Secret that a model resource references. ax's Model documents the google and anthropic providers, and ax's own components also read Model resources, for example when planning a workspace from a goal.⁴³

Model providers accepted by each project
Project	Resource	Providers
ax	`Model`	`google`, `anthropic`⁴
kagent	`ModelConfig`	`Anthropic`, `OpenAI`, `AzureOpenAI`, `Ollama`, `Gemini`, `GeminiVertexAI`, `AnthropicVertexAI`, `Bedrock`, `SAPAICore`, `Foundry`, `Mistral`²²

The kagent README also names custom providers through AI gateways.⁸

Egress endpoints

kagent's runtime doc states that Substrate v0.3.0-alpha3 requires protocol-specific egress policies. kagent allows each configured HTTP(S) origin, keeping its scheme, DNS name, and port, and replaces credential headers in that destination's rule. Literal IP allowlists are unsupported, so model, MCP, and telemetry endpoints must be DNS names.¹⁰ v0.3.0-alpha3 is the version kagent alpha6 builds against: its go.mod replaces upstream Substrate with the kagent-dev/substrate fork at v0.3.0-alpha3, not upstream v0.3.0.³⁰

ax documents no egress policy of its own today. Least-privilege egress for the setup and task actors is a roadmap item.⁶