Skip to main content
This guide walks through two practical agent use cases, CloudOps Engineer and Platform Engineer, showing how to configure them, when to use them, and how they fit into real operational workflows. These examples are designed as quickstarts so teams can create production-grade agents with minimal setup. Agents in Kubiya operate using Skills, optional MCP integrations, and configuration inherited from attached Environments. They run deterministic plans and can automate DevOps, SRE, platform, and workflow tasks in a repeatable and safe way.

When to use Agents for Engineering Workflows

Use these agents when you need to automate engineering tasks that are:
  • Repetitive (provisioning, deployments, audits, checks).
  • Standardized (pipeline operations, resource creation, validations).
  • High-context (logs, metrics, environments, IaC).
  • Triggered by users, workflows, chat commands, or webhooks.
Agents allow platform teams to encode operational expertise once and make it available everywhere.

Prerequisites

Before creating these agents ensure:
  • At least one Environment is Ready
  • That Environment has a Worker Queue with at least one connected worker
  • Required secrets exist (cloud credentials, registry tokens, access keys)
  • Required Skills are enabled at the Environment level (shell, Docker, Python, etc.)

CloudOps Engineer Agent

A CloudOps Engineer agent manages cloud infrastructure operations. It handles tasks such as provisioning, resource audits, monitoring, and deployment execution across providers such as AWS, GCP, or Azure.

What this agent does

A CloudOps Engineer typically performs:
  • Cloud resource inspections and audits
  • VM, Kubernetes, or serverless deployment actions
  • Reading logs and metrics to surface anomalies
  • Managing cloud accounts/tokens stored in Environments
  • Responding to alerts or executing runbooks autonomously
Ideal for teams that want cloud operations automated through a reusable operational persona.

When to use it

Choose this agent when you need:
  • Multi-cloud operational support
  • Automated cloud infrastructure checks
  • On-demand remediation (restart nodes, scale resources)
  • Daily/weekly cost or resource drift audits
  • Integration with alerting workflows (Slack, webhooks)

Required configuration

This agent requires:

Environment-level prerequisites

  • Cloud credentials (AWS IAM key, GCP service account, Azure SP)
  • Skills:
    • Shell (Full Access or Restricted)
    • Docker (if running local tooling)
    • Python (Unrestricted or Restricted)
  • Kubiya Platform APIs enabled

Optional MCP integrations

  • Cloud provider-specific MCP servers
  • GitHub/GitLab for IaC repos
  • Terraform Cloud/Atlantis MCP

Step-by-step: Create a CloudOps Engineer agent

1. Basic Info

  • Name: CloudOps Engineer
  • Description: Manages cloud infrastructure. Performs audits, deployments, and operational diagnostics.
  • Model: Claude Sonnet or Claude Opus for high-precision operational tasks
  • Capabilities: cloudops, infrastructure, devops

2. Deployment

  • Environments: Add a production, staging, or shared cloud environment
  • Runtime: Default recommended

3. Execution Environment

Attach:
  • Environment variables such as DEFAULT_REGION=us-east-1
  • Secrets like AWS_ACCESS_KEY, AWS_SECRET_KEY, GCP_CREDENTIALS
  • Integrations: GitHub if working with IaC repos

4. Tools (Skills & MCP)

Skills to enable:
  • Shell – Full Access
  • Python – Unrestricted
  • Docker – Full Control
Optional MCPs:
  • Cloud provider MCP (aws-cli, gcloud, az)
  • Terraform MCP

5. Policies (after creation)

Example restrictions:
  • Restrict shell to investigative commands only
  • Allow deployments only in specific namespaces or regions
kubiya agent create \
  --name "CloudOps Engineer" \
  --desc "Agent that manages cloud infrastructure across AWS, GCP, and Azure. Performs environment checks, deployment validation, and drift detection." \
  --llm claude-4-sonnet \
  --env LOG_LEVEL=info \
  --env CLOUD_PROVIDER=multi \
  --integration github \
  --knowledge-labels operations \
  --knowledge-labels cloud

Creating agent 'CloudOps Engineer'...
TRACE: CreateAgent called with agent name: CloudOps Engineer
✅ Created agent: CloudOps Engineer (UUID: d33da60d-1a16-440a-b4be-adc18ab33a2c)

Created Resources
• Agent: CloudOps Engineer (d33da60d-1a16-440a-b4be-adc18ab33a2c)

Next Steps
• View details:  kubiya agent get d33da60d-1a16-440a-b4be-adc18ab33a2c
• Edit agent:  kubiya agent edit d33da60d-1a16-440a-b4be-adc18ab33a2c --interactive

How to use the CloudOps Engineer

Once created, you can:

Chat-based

Ask: “Check unused EC2 instances older than 30 days.” “Run a drift check against staging Terraform.” “Analyze CloudWatch errors for service X.”

Workflow-based

Use this agent in automation:
  • Daily cost audits
  • Auto-remediation tasks
  • Alert enrichment
  • Deployment orchestration

Webhook-based

Trigger from cloud alerts or monitoring tools. You can verify your agent by running the provided command with your agent ID:
kubiya agent get d33da60d-1a16-440a-b4be-adc18ab33a2c

 👤 Agent: CloudOps Engineer

Basic Information
  UUID: d33da60d-1a16-440a-b4be-adc18ab33a2c
  Name: CloudOps Engineer
  Description: Agent that manages cloud infrastructure across AWS, GCP, and Azure. Performs environment checks, deployment validation, and drift detection.
  Type: 🛠️ Tools
  LLM Model: 🦚 claude-4-sonnet

Environment Variables
  KEY                              VALUE
  CLOUD_PROVIDER  multi
  LOG_LEVEL       info

Integrations
  • 🐙 github

Access Control
  Owners: 0727f96f-19a1-46c4-b50e-e5ebbf9cc62f

Timestamps
  Created: 2025-11-17T11:52:34.003Z
  Updated: 2025-11-17T11:52:34.003Z

Helpful Commands
  • Edit:  kubiya agent edit d33da60d-1a16-440a-b4be-adc18ab33a2c --interactive
  • Delete:  kubiya agent delete d33da60d-1a16-440a-b4be-adc18ab33a2c

Platform Engineer Agent

A Platform Engineer agent manages platform infrastructure, CI/CD tooling, internal developer platforms, and pipeline orchestration. It is ideal for automating internal platform tasks.

What this agent does

A Platform Engineer agent typically performs:
  • Pipeline debugging and execution
  • Infrastructure-as-code workflows (Terraform, Helm, Argo, Flux)
  • Container builds and validations
  • Deployments across clusters/environments
  • Reading logs and analyzing build failures
  • Managing platform lifecycle automation

When to use it

Use this agent when you need:
  • Developer workflow automation
  • Consistent CI/CD operations
  • Standardized environment/platform management
  • Automated validation of IaC or manifests
  • Assistance with Kubernetes, Helm, Docker, Terraform tooling

Required configuration

Environment-level prerequisites

  • CI/CD credentials
  • Kubernetes API tokens
  • Registry credentials
  • Skills:
    • Shell – Full Access
    • Docker – Full Control
    • Full Diagramming Suite (optional for workflow visualization)

Optional MCP integrations:

  • GitHub/GitLab
  • ArgoCD MCP
  • Kubernetes MCP
  • Jenkins MCP

Step-by-step: Create a Platform Engineer agent

1. Basic Info

  • Name: Platform Engineer
  • Description: Automates platform tasks, pipelines, and deployments.
  • Model: Claude Sonnet for performance or Claude Opus for deeper reasoning
  • Capabilities: devops, platform, cicd

2. Deployment

  • Environments: staging, prod, infra
  • Supports multi-environment use

3. Execution Environment

Add:
  • K8S_CONTEXT=prod-cluster
  • Registry secrets
  • GitHub integration for pipeline repos

4. Tools (Skills & MCP)

Recommended Skills:
  • Docker – Full Control
  • Shell – Full Access
  • Full Diagramming Suite
  • Python (optional)
Optional MCPs:
  • Kubernetes
  • ArgoCD
  • GitHub Repos

5. Policies

Define guardrails:
  • Only deploy to specific namespaces
  • Allow Docker operations only on controlled repos
  • Restrict shell commands

kubiya agent create \
  --name "Platform Engineer" \
  --desc "Agent that manages infrastructure deployments, CI/CD operations, Kubernetes actions, and platform automation." \
  --llm claude-4-sonnet \
  --env DEFAULT_NAMESPACE=platform \
  --env DEPLOY_STRATEGY=rolling \
  --integration github \
  --integration jira \
  --knowledge-labels cicd \
  --knowledge-labels kubernetes

Creating agent 'Platform Engineer'...
TRACE: CreateAgent called with agent name: Platform Engineer
✅ Created agent: Platform Engineer (UUID: 53ed97e5-1693-4d09-a51c-112041b76620)

Created Resources
• Agent: Platform Engineer (53ed97e5-1693-4d09-a51c-112041b76620)

Next Steps
• View details:  kubiya agent get 53ed97e5-1693-4d09-a51c-112041b76620
• Edit agent:  kubiya agent edit 53ed97e5-1693-4d09-a51c-112041b76620 --interactive

How to use the Platform Engineer

Chat-based workflows

Ask the agent to: “Validate this Helm chart and show me errors.” “Deploy service X to staging.” “Explain why pipeline run #438 failed.”

Workflow-based automation

Attach it to:
  • PR-triggered IaC validations
  • Continuous deployment pipelines
  • Automatic container scanning and fixes

Developer workflow self-service

Developers can delegate tasks via chat: “Create a temporary Kubernetes namespace for testing.” Run the provided cli command to verify your new agent:
kubiya agent get 53ed97e5-1693-4d09-a51c-112041b76620

 👤 Agent: Platform Engineer

Basic Information
  UUID: 53ed97e5-1693-4d09-a51c-112041b76620
  Name: Platform Engineer
  Description: Agent that manages infrastructure deployments, CI/CD operations, Kubernetes actions, and platform automation.
  Type: 🛠️ Tools
  LLM Model: 🦚 claude-4-sonnet

Environment Variables
  KEY                                 VALUE
  DEFAULT_NAMESPACE  platform
  DEPLOY_STRATEGY    rolling

Integrations
  • 🐙 github
  • 📋 jira

Access Control
  Owners: 0727f96f-19a1-46c4-b50e-e5ebbf9cc62f

Timestamps
  Created: 2025-11-17T12:00:27.859Z
  Updated: 2025-11-17T12:00:27.859Z

Helpful Commands
  • Edit:  kubiya agent edit 53ed97e5-1693-4d09-a51c-112041b76620 --interactive
  • Delete:  kubiya agent delete 53ed97e5-1693-4d09-a51c-112041b76620

Troubleshooting Both Agents

If CloudOps or Platform Engineer agents appear stuck:
  • Ensure the Environment is in Ready state
  • Confirm the Worker Queue has at least one active worker
  • Check that required Skills are attached
  • Verify secrets and credentials exist at the correct level
  • Review OPA policies for command or environment restrictions

Best Practices

  • Keep Skills minimal; add more only when needed
  • Store cloud tokens and CI credentials at the Environment level
  • Use multiple Environments instead of duplicating agents
  • Add policies once the agent’s behavior is verified
  • Always start with safe read-only commands during testing

Next Steps

  • Add alerts or workflows that trigger these agents
  • Connect MCP integrations for deeper automation
  • Build dashboards showing agent health and activity
  • Add environment-specific OPA policies for guardrails