Agent platform integration
This page shows how to connect an Agent platform to Kibotos: where the Operator identity lives, how Agent sessions map to Workspaces and Volumes, and how the platform handles failures. The code uses the Go SDK. Programs in other languages make the same calls through the native API.
Overview
Your platform backend sits between the Agent and Kibotos. It manages Workspaces through ctrl and reaches the node that runs each Workspace with a short-lived credential:
flowchart LR Agent[Agent runtime] -->|tool calls| Backend[Platform backend] Backend -->|mTLS with the Operator identity| Ctrl[ctrl] Backend -->|session credential| Node[node data plane] Node --> Workspace[Workspace]
A typical session runs in this order:
- Find or create the project's Volume.
- Create a Workspace bound to that Volume, with an expiration time.
- Run the Agent's tool calls through a data-plane session.
- Delete the Workspace when the session ends. The Volume stays for the next session.
Coding Agent with a persistent project is a complete program that follows these steps.
Identity and access
Warning
An Operator has cluster administration rights and can operate every Workspace in the deployment. Keep the identity in your backend. Never copy it into a Workspace or pass it to an Agent.
- Your platform authorizes its own users. Kibotos has no tenants. Every Operator sees every Workspace, so your backend decides which user may reach which Workspace.
- Labels are not access control. Use them to find resources. See Labels and annotations.
- Each backend instance needs its own identity directory. ctrl accepts only the current and the previous certificate of an identity, so two programs renewing one identity lock each other out. Create one enrollment key per instance with
kibo enrollment create --operator. See Connect to ctrl.
Agent access to a Workspace
Choose how the Agent's tool calls reach the Workspace:
| Approach | How it works | Use it when |
|---|---|---|
| Backend runs the tools | The backend holds a dataplane.Session and runs each tool call. The Agent receives no credential | By default. The backend can check, log, and limit every call |
| Backend hands out a credential | The backend requests a session credential and gives it to an Agent runtime outside the Workspace, which then calls the node directly | The Agent runtime needs a direct connection, for example for long output streams |
To hand out a credential, request only the scopes the Agent needs and a short lifetime:
response, err := client.DataPlaneSessions().CreateDataPlaneSession(ctx, connect.NewRequest(&ctrlv1.CreateDataPlaneSessionRequest{
Metadata: &ctrlv1.CommandMetadata{CommandId: kibotos.NewCommandID("platform")},
WorkspaceId: workspaceID,
RequestedScopes: []ctrlv1.DataPlaneScope{ctrlv1.DataPlaneScope_DATA_PLANE_SCOPE_PROCESS},
RequestedTtl: durationpb.New(5 * time.Minute),
}))
if err != nil {
log.Fatal(err)
}
endpoint := response.Msg.GetSession().GetEndpoint()
credential := response.Msg.GetCredential()- A credential is valid for one Workspace and the scopes it names. It cannot create, stop, or delete a Workspace.
- It lasts 5 minutes by default and 15 minutes at most. Your backend issues the next one.
- The Agent runtime must reach the node address and trust
server-ca.pemfrom the identity. See Calling the node. - Treat the credential as a secret. To cut off all access to a Workspace at once, call
RevokeWorkspaceDataPlane.
Mapping sessions to Kibotos objects
| On your platform | In Kibotos | Notes |
|---|---|---|
| Project or user directory | Volume | Lives until you delete it. Bind it when you create a Workspace |
| Agent session | Workspace | Bound to the project's Volume. Deleting it keeps a Volume bound this way |
| Session or request ID | Command ID | kibotos.DeriveCommandID builds it from your ID, so a restarted backend replays the same command instead of creating a second Workspace |
| Owner, project, or batch | Label | Find resources with label_selector after a restart |
| Longest allowed session | Expiration | ctrl stops or deletes the Workspace even if your backend never comes back |
A Volume is bound to one Workspace at a time. Before you bind it to a new Workspace, delete the old Workspace and wait for the delete command with Client.WaitWorkspaceDeleted.
Idle sessions
Kibotos cannot save memory state, so choose by what the session needs when it continues:
| Between turns | CPU and memory | What survives | Continue with |
|---|---|---|---|
| Keep it running | Held | Everything, including processes | The same data-plane session |
| Stop | Released | The Volume, and the writable layer on a best-effort basis | StartWorkspace, then open a new data-plane session and restart processes |
| Delete | Released | Only a Volume bound as above | A new Workspace |
Files the Agent must keep belong on the Volume. See Guarantees and limits.
Failure handling
| What you see | Meaning | What to do |
|---|---|---|
| A write returns no answer or times out | The result is unknown | Send it again with the same command ID. kibotos.Settle does this. A failure with command_settled is final, so a new attempt takes a new ID. See Write operations and errors |
Create or start fails with resource_exhausted | No node has room | Queue the work and retry. The Workspace stays and can be started later or deleted |
The Workspace is UNKNOWN | A node is temporarily unreachable | Wait, or resend the original command ID. Do not create a replacement yet: the original may still be running |
The Workspace is FAILED | The execution failed | Force stop, then start. See Recovering from FAILED |
The Workspace is AVAILABLE, but the guest does not respond | The guest is stuck | See Responsiveness of the guest |
| A process stream breaks | The connection to the node dropped | dataplane.Session resumes it. A Gap event reports output that could not be recovered |
| An operation fails because a capability is missing | The server is older than the feature | Call Client.Require before the operation and fail only that feature. See Querying capabilities first |
Network access
A new Workspace has no network access, and that is the right start for most Agents.
- Open public internet access when the task needs it, and narrow it with destination rules. See Network policy.
- To send traffic through your own proxy or use a fixed outbound address, use an Egress. It requires
v0.3.0or later. - To show a service in the Workspace to a user, create a public URL, and revoke it when you are done. Anyone with the address can use it.
Next steps
- Choosing an environment: get the software your Agent needs into a Workspace.
- Errors: what each failure reason means.
- Coding Agent with a persistent project: keep a project across sessions.
- Running untrusted code: limit what the code can reach and how long it runs.
- Batch creation and reclamation: create many Workspaces and clean them up.
- Operating a desktop: the screenshot and input loop.
Labels and annotations
Labels and annotations are your own key-value data on Workspaces, Volumes, Egresses, and Resolvers. This page shows how to set and change them, and how to find resources by label.
Coding Agent with a persistent project
A coding Agent needs its project to survive when a session ends. This page keeps the project on a Volume of its own and gives each session a new Workspace bound to that Volume. The complete program is examples/go/coding-agent.