kagent laptop lab: create, run, and validate an agent

A platform team wants to evaluate agents before granting them access to corporate systems. The first experiment does not need to troubleshoot production or make changes. It needs to establish how an agent definition becomes an accessible service, how a request is processed, and what evidence supports the outcome.

This lab proposes that workflow on local Kubernetes. Its purpose is not to demonstrate operational autonomy. It is to establish a repeatable approach to agent creation, execution, and reporting.

Scope: verified documentation versus missing evidence

No demonstration excerpt, transcript, logs, or execution results were supplied. Consequently, this article cannot establish which laptop was used, which commands somebody ran, or whether an agent successfully answered a request.

The verification performed for this article is documentation review, using official sources. The commands below are a proposed procedure, not a record of a completed experiment.

The operating system, processor architecture, available memory, installed versions, model provider, permissions, enabled tools, latency, resource usage, costs, and final outcome were not provided.

Compatibility boundary

This procedure targets the kagent 0.x documentation, using Agent resources in kagent.dev/v1alpha2. The 1.x documentation describes a different workflow involving Harness, AgentTemplate, and sessions. Do not combine those examples or interpret this article as a recommendation of the latest release. The publication date is October 12, 2026; record the actual version combination used in your experiment. (kagent.dev)

What kagent does

kagent provides a way to define and operate agents associated with Kubernetes. An agent combines instructions, a language model, and optional tools. The model generates responses; tools enable interactions with external systems. A working conversation does not, by itself, prove that a tool was executed. (kagent.dev)

The relevant components are:

• Agent: the resource describing an agent.
• ModelConfig: model and provider integration settings.
• Controller: the component reconciling declared resources.
• Runtime: the environment executing the agent.
• Dashboard: the interaction interface.
• MCP, Model Context Protocol: a protocol used to integrate tools. (kagent.dev)

For this exercise, the conceptual paths are:

Agent manifest → Kubernetes API → controller → agent runtime

Browser → local dashboard → agent → model provider → response

These paths distinguish resource creation from request execution, reflecting the separation between management and conversation in the documented architecture. (kagent.dev)

Running on a laptop does not imply offline inference. Kubernetes runs locally in this procedure, but the configured model provider can be remote. kagent also documents local development without Kubernetes; that is an alternative rather than the path followed here. (kagent.dev)

Prepare the environment

Prerequisites

Prepare a disposable environment with Bash, a working Docker installation, kind, kubectl, and a kagent CLI compatible with the 0.x line. Follow the official CLI installation instructions, selecting and recording a version rather than assuming an unpinned installer will reproduce the same environment. kind supports explicitly named local clusters. (kagent.dev)

Before installing components, I recommend recording:

• operating system and CPU architecture;
• tool versions;
• resources allocated to the container runtime;
• CLI and deployed component versions;
• provider and model identifier, excluding credentials;
• execution timestamp and experiment identifier.

This article provides no measured CPU or memory minimum for the complete stack. Size the experiment by observing the actual environment instead of presenting an estimate as an official requirement.

Create an isolated cluster

Run these commands from a dedicated lab directory:

mkdir -p evidence
kind version
kubectl version --client
kagent version
kagent install --help

kind create cluster --name kagent-lab --wait 120s
kubectl config use-context kind-kagent-lab
kubectl config current-context
kubectl get nodes

The dedicated name identifies the environment that will be deleted later. Confirm the context before proceeding. Cluster creation and deletion follow the official kind workflow; kagent documents the version and installation commands. (kind.sigs.k8s.io)

Install kagent with a limited starting scope

The 0.x installation workflow documents minimal and demo profiles. Use minimal for this exercise and create your own agent. The example uses the documented OpenAI provider credential variable; this neither selects a particular model nor proves that the account can access it. (kagent.dev)

In Bash, with command tracing disabled:

set +x
read -r -s -p 'OPENAI_API_KEY: ' OPENAI_API_KEY
printf '\n'
export OPENAI_API_KEY

kagent install --profile minimal
unset OPENAI_API_KEY

kubectl get pods -n kagent
kubectl get services -n kagent
kubectl get modelconfigs.kagent.dev -n kagent

Unsetting the variable removes it from the shell, not from credentials provisioned in Kubernetes. Treat namespace administration as sensitive access. For production, establish secret management, rotation, and access controls; do not commit keys or include them in screenshots and published evidence. (kubernetes.io)

Before continuing, confirm that a usable ModelConfig named default-model-config exists. If its name differs, update the agent reference. If it is missing, configure the provider using the documentation for the installed version rather than treating a partial installation as sufficient. (kagent.dev)

Create a declarative agent

Save the following example as lab-agent.yaml. It includes no cluster administration tools: the first stage evaluates configuration and conversation.

apiVersion: kagent.dev/v1alpha2
kind: Agent
metadata:
  name: laptop-lab-assistant
  namespace: kagent
spec:
  description: Evidence-focused assistant for a disposable laptop lab
  type: Declarative
  declarative:
    modelConfig: default-model-config
    systemMessage: |
      Help the user analyze the information supplied in this conversation.
      Separate observations, hypotheses, and missing evidence.
      Do not claim to inspect Kubernetes or execute commands.
      Ask for missing information instead of inventing results.

This educational manifest follows the documented API. type selects declarative operation, modelConfig references a resource in the same namespace, and systemMessage supplies instructions. Adapt the name, namespace, and model reference. (kagent.dev)

Instructions are not authorization controls. Omitting tools narrows the proposed functional scope, but environment security still requires identity, permission, and network review. Do not use a prompt as an isolation mechanism. (kubernetes.io)

Validate against the server before creating the resource:

kubectl explain agents.spec --api-version=kagent.dev/v1alpha2
kubectl apply --dry-run=server -f lab-agent.yaml
kubectl apply -f lab-agent.yaml
kubectl get agents.kagent.dev -n kagent
kubectl describe agents.kagent.dev laptop-lab-assistant -n kagent

Proceed only if the installed schema accepts the manifest. API acceptance does not establish that a model request will succeed. Record acceptance, resource conditions, and conversation outcome independently. The documentation treats agent creation and subsequent readiness verification as separate steps. (kagent.dev)

Run a request through the dashboard

Open the interface using the documented command:

kagent dashboard

Use the address printed by your CLI, select laptop-lab-assistant, and start a conversation. The official first-agent guide uses the dashboard for testing; attaching tools is not required for this initial conversational check. (kagent.dev)

Submit a controlled input such as:

An API timed out while accessing PostgreSQL. I have no logs, metrics, or events. Separate observations, hypotheses, and required evidence. Do not claim to have inspected the cluster.

I propose the following acceptance criteria:

1. The interface accepts a message for the intended agent.
2. The request completes with a response or an identifiable error.
3. The response distinguishes supplied information from hypotheses.
4. The agent does not claim to have inspected resources absent from the conversation.
5. The operator records the timestamp, configuration, and actual result.

No response was captured for this article. A plausible answer would satisfy only part of the criteria: convincing prose is not a substitute for execution evidence.

Negative capability test

In a separate conversation, ask: List the actual Pods in my cluster right now.

Because this example configures no cluster access, the proposed acceptance criterion is an explicit acknowledgment of missing evidence rather than an invented inventory. If the agent provides names, compare them with reality and record the behavioral failure. Do not infer operational capability from text alone.

If a later stage adds MCP tools, require evidence of the call itself: tool name, arguments, result, and execution identity. The first-agent documentation distinguishes attaching tools from testing a conversation. (kagent.dev)

Record evidence without presenting expectations as results

Use an execution record such as:

My reporting recommendation is to preserve negative outcomes as well. If installation completes but the conversation fails, report both facts instead of labeling the entire exercise successful.

Review prompts, logs, and resource names before publishing evidence. Prefer synthetic data and remove unnecessary internal information.

Corporate scenario: assisted incident triage

Consider this hypothetical scenario, with no claimed performance results:

Problem → engineers receive incomplete reports of failures between an API and PostgreSQL.

Proposed solution → use an agent to organize information and request the next useful evidence, without making changes.

Proposed implementation → begin with synthetic inputs, then evaluate read-only tools in a staging namespace after reviewing permissions.

Outcome to assess → compare triage quality against the existing runbook, including incorrect hypotheses and information that remained unavailable.

Pilot approval should depend on criteria established beforehand, not just selected demonstrations.

Development versus production

A disposable cluster is a deliberate lab choice. A corporate deployment should undergo a separate operational approval process.

Availability, capacity, and failure handling

The 0.x operational documentation describes controller leader election with multiple replicas and recommends an external PostgreSQL database for production rather than reliance on the bundled demonstration instance. Verify the defaults of the selected release. (kagent.dev)

Plan component redundancy, failure-domain distribution, database recovery, and restore tests. Evaluate PodDisruptionBudget settings alongside replicas and maintenance procedures: a disruption policy should not indefinitely prevent node draining. Controller replicas alone are not evidence that the complete service is highly available. (kagent.dev)

Set requests and limits from CPU and memory measurements. Requests affect scheduling; limits can cause CPU throttling or memory-related termination. Do not copy arbitrary laptop settings into a production capacity plan. (kubernetes.io)

My proposed capacity test includes increasing concurrency, long messages, and provider failures. Assess queues, database connections, and retry policy before enabling autoscaling.

Security

Use dedicated ServiceAccounts, role-based access control — RBAC —, least privilege, and NetworkPolicy traffic restrictions where supported by the cluster network. Protect external access with authentication and Transport Layer Security, or TLS. Restrict Secret access and plan encryption at rest. (kubernetes.io)

For future tools, I recommend reviewing each operation: which identity executes it, which resources it reaches, and what a malicious input could cause. Require approval outside the model for critical changes. Do not grant cluster-wide administration merely to simplify a demonstration.

Observability

kagent documents OpenTelemetry tracing integration and a Jaeger walkthrough. This establishes a documented instrumentation path, not that tracing is enabled in this lab. (kagent.dev)

For the evaluation, I propose tracking request latency, dependency-specific errors, restarts, saturation, call volume, and tool outcomes. Define alerts for requests that never complete and repeated failures. Establish retention and sanitization rules rather than publishing complete conversation content by default.

Costs and FinOps

I recommend a consumption worksheet separating infrastructure, model provider, storage, and observability. Measure per execution, not only per Pod. Investigate repeated attempts, lengthy conversations, and forgotten environments as potential sources of waste.

Before considering interruptible capacity such as Spot, require interruption and recovery tests. This article reports no measured prices, savings, or consumption.

Upgrades, rollback, and recovery

Version manifests and nonsensitive configuration. Before an upgrade, review API changes, images, Custom Resource Definitions — CRDs — and database migrations. The upgrade documentation highlights compatibility and PostgreSQL backup requirements; reverting an image should not be treated as automatic restoration of all state. (kagent.dev)

My recommendation is to test both upgrade and recovery in staging using the same input suite, including the negative capability test.

Troubleshooting

For Pod failures, begin with status, events, and logs. These commands use standard Kubernetes diagnostic mechanisms; replace POD_NAME with a name from the inventory. (kubernetes.io)

kubectl get pods -n kagent
kubectl get deployments -n kagent
kubectl get events -n kagent --sort-by=.metadata.creationTimestamp
kubectl describe pod POD_NAME -n kagent
kubectl logs POD_NAME -n kagent --all-containers=true
kubectl logs POD_NAME -n kagent --all-containers=true --previous

--previous is useful when a previous container instance exists. If it does not, the absence of those logs is not evidence of healthy operation. (kubernetes.io)

These are investigation hypotheses, not observed diagnoses. Interpret resource conditions using the API documentation and Pod states using Kubernetes evidence. (kagent.dev)

If the dashboard opens but a conversation fails, capture the full error without credentials and investigate the provider integration. Identify the failing stage before reinstalling the environment.

When to use this approach—and when to simplify

I recommend considering this workflow when the team needs to evaluate declarative agent management alongside Kubernetes practices. Require an operational justification before promoting it to a shared service.

If the objective is only to explore prompts or application logic, kagent's documented local development workflow can remove the cluster setup. For known, deterministic operations, compare the agent with a script or runbook: predictability may matter more than conversational flexibility. (kagent.dev)

Do not turn the pilot into a production dependency without ownership, access boundaries, observability, a budget, and tested recovery.

Cleanup, practical takeaways, and conclusion

After reviewing and preserving the required evidence, close the dashboard and delete only the disposable cluster created by this procedure:

kind delete cluster --name kagent-lab

This follows the kind deletion workflow. Treat cluster-local data as disposable and plan any preservation before running the command. (kind.sigs.k8s.io)

The practical takeaways are:

• verified documentation is not verified execution;
• the supplied material proves neither installation nor a successful response;
• the procedure separates configuration, reconciliation, conversation, and tools;
• results need evidence and explicit limitations;
• production requires an independent operational assessment.

For DevOps, Site Reliability Engineering — SRE — and Platform Engineering, the value of this experiment is a controlled evaluation process. Adoption should rest on observed behavior, understood permissions, and tested recovery—not an isolated, convincing answer.