Teams Use Cases

Documentation Index

Fetch the complete documentation index at: https://docs.kubiya.ai/llms.txt

Use this file to discover all available pages before exploring further.

Teams coordinate multiple agents to work together with shared context, tools, guardrails, and inherited configuration from Environments. They are ideal when a function, department, or project requires a set of agents that operate within shared constraints, credentials, and policies. Below are two complete, real-world use cases demonstrating how to create, configure, and use Teams effectively.

​

Use Case 1: Platform Engineering Team

A Platform Engineering team owns CI/CD, environments, deployment automation, and developer workflows. They need multiple agents to collaborate across Kubernetes, GitHub, Terraform, and pipeline operations.

​

Purpose

• Automate deployments across clusters
• Validate IaC (Terraform, Helm, Argo)
• Troubleshoot failed pipelines
• Provide development teams with self-service infrastructure operations
• Run tasks with consistent guardrails and credentials

​

Agents Included

• Platform Engineer Agent: orchestrates deployments, runs pipeline checks
• CloudOps Engineer Agent (optional):provides cloud-level checks and drift detection
• SRE Helper Agent (optional): diagnostics and log extraction

​

Typical Workload

• Deploy a service to staging/production
• Validate Terraform for infrastructure changes
• Roll back a failed deployment
• Debug CI/CD pipelines
• Run canary analysis using metrics platforms

​

How to Create This Team

​

1. Basic

• Team Name: Platform Engineering
• Description: “Deployment automation, Kubernetes operations, CI/CD tooling.”
• Visibility: Organization (visible to dev teams but writable only by members)

​

2. Deployment

• Runtime: Default (unless your org separates prod/stage runners)
• Environments: Add
  • staging
  • production
  • sandbox (optional)
• Environments supply Kubernetes credentials, cloud access, registry secrets, etc.

Execution Environment (per team):

• Environment Variables:
  • DEFAULT_NAMESPACE=platform
  • DEPLOY_STRATEGY=rolling
• Secrets (only if team-specific):
  • None, prefer using Environment-level cloud credentials
• Integration Credentials:
  • GitHub
  • GitLab (optional)
  • Kubernetes clusters

​

3. Members

Add agents:

• Platform Engineer Agent
• CloudOps Engineer Agent Optionally add human members:
• Infra engineers (Editor)
• DevOps/SRE (Operator)

​

4. Tools

• Skills:
  • Shell – Full Access
  • Docker – Full Control
  • File operations
  • Python
• MCP Servers:
  • “Enable Kubiya Platform APIs” (recommended)
  • Custom MCP servers for GitHub/GitLab/ArgoCD

​

5. Advanced

• Team Instructions: High-level instruction for multi-agent coordination (e.g., “Plan deployments before execution, validate cluster state, escalate errors with full logs.”)
• Team Context:
  • Deployment playbooks
  • Runbooks (rollback, canary, debugging)
• OPA Policies:
  • Allow deploy only to approved namespaces
  • Allow Terraform actions only in staging
  • Disallow destructive Kubernetes commands in production

​

How the Team Behaves at Runtime

When assigned a task, the team:

1. Uses shared credentials from the selected Environment
2. Coordinates between Platform Engineer + CloudOps agents
3. Applies Team-level Skills and OPA policies
4. Executes each step in isolated containers with full logs

​

Example Usage Scenarios

Developer request: “Deploy service checkout to staging with version v1.12.0.” Platform engineer task: “Run Terraform plan for the new database module.” SRE diagnostic: “Show me the last 100 lines of logs from checkout service in production.”

​

Use Case 2: Security Operations (SecOps) Team

A Security Operations team handles incident detection, vulnerability scanning, and remediation workflows. They require agents to work with shared, tightly controlled credentials and follow strict policies.

​

Purpose

• Detect anomalies in logs and metrics
• Validate IAM permissions
• Perform vulnerability and configuration scans
• Automate security checks during deployments
• Enforce strict operational guardrails

​

Agents Included

• Security Analyst Agent (your SRE Helper / extended capabilities)
• CloudOps Engineer Agent (for cloud identity + infrastructure checks)
• Log Analyzer Agent (optional custom agent)

​

Typical Workload

• Detect anomalous login patterns
• Scan cloud accounts for misconfigurations
• Validate security group/firewall settings
• Check for exposed secrets in repositories
• Run compliance checks (SOC2, CIS, ISO baselines)

​

How to Create This Team

​

1. Basic

• Team Name: Security Operations
• Description: “Incident response, identity validation, vulnerability scanning.”
• Visibility: Private (recommended for SecOps)

​

2. Deployment

• Runtime: Default
• Environments:
  • production-security (restricted)
  • audit (read-only permissions)

Execution Environment:

• Environment Variables:
  • SCAN_DEPTH=deep
  • IAM_AUDIT_MODE=strict
• Secrets:
  • Use Environment-level secrets for access keys
  • Add only team-specific tokens if unique to this team
• Integration Credentials:
  • AWS security account
  • GCP organization policy API
  • SIEM provider (e.g., Datadog, Splunk)

​

3. Members

Add agents:

• Security Analyst Agent
• CloudOps Engineer Agent
• Log Analyzer Agent

​

4. Tools

• Skills:
  • Shell – Restricted (only safe commands)
  • File – Read-only
  • Python – Safe mode
• MCP Servers:
  • Cloud security integrations
  • SIEM log retrieval
  • IAM analysis tooling

​

5. Advanced

• Team Instructions: “Agents must always validate permissions before actions. Never execute write operations without explicit confirmation. Prefer read-only tools first.”
• Team Context:
  • Incident response runbooks
  • Company security baseline docs
  • IAM architecture diagrams
• OPA Policies:
  • Block destructive cloud actions
  • Allow only read-only Kubernetes interactions
  • Enforce mandatory approval for write actions

​

Runtime Behavior

The team ensures all security workflows:

• Use the restricted Environments with limited credentials
• Log every step for auditability
• Remain compliant through OPA enforcement
• Execute tasks in isolated containers with read-only defaults

​

Example Usage Scenarios

Security alert triage: “Analyze IAM changes in the last 24 hours and flag unusual privilege escalations.” Vulnerability scan: “Run a configuration scan for all production VPCs.” Incident investigation: “Retrieve last 50 failed login attempts from SIEM and summarize suspicious IPs.”