# AI Agents Source: https://docs.cloudthinker.io/guide/agents Meet the five specialized CloudThinker agents and choose the right one for cost, security, database, and Kubernetes work CloudThinker ships five specialized agents that analyze, report on, and act across your cloud environment. Each agent owns a domain, keeps persistent memory of your infrastructure, and coordinates with the others on cross-domain work. ## The agent roster | Agent | Role | Best for | | ---------------------------------- | ------------------- | --------------------------------------------------------------------------------------- | | [**Alex**](/guide/agents/alex) | Cloud Engineer | Cost analysis, infrastructure optimization, multi-cloud architecture, reserved capacity | | [**Oliver**](/guide/agents/oliver) | Security Engineer | Compliance audits, vulnerability assessment, IAM reviews, threat detection | | [**Tony**](/guide/agents/tony) | Database Engineer | Query optimization, performance tuning, index recommendations, capacity planning | | [**Kai**](/guide/agents/kai) | Kubernetes Engineer | Cluster health, pod right-sizing, autoscaling, RBAC audits, troubleshooting | | [**Anna**](/guide/agents/anna) | General Manager | Multi-agent coordination, cross-domain projects, executive reporting | Want a different tone, restricted access, or a fully custom agent? See [Customize agents](/guide/agents/customize). ## Choose the right agent | You need | Mention | | ------------------------------------- | --------- | | Cloud costs are too high | `@alex` | | A security audit or compliance report | `@oliver` | | A slow database diagnosed | `@tony` | | Kubernetes cluster issues resolved | `@kai` | | A problem that spans multiple domains | `@anna` | | A starting point when you're not sure | `@anna` | Anna dispatches work to the other agents, so she is the safe default for incident investigations and cross-domain projects. ## Talk to agents Talk to agents in plain language. The full pattern is: ```text theme={null} @agent #tool your request ``` * **`@agent`** — who does the work: `@alex` (cloud), `@oliver` (security), `@tony` (database), `@kai` (Kubernetes), `@anna` (coordination). * **`#tool`** *(optional)* — the output you want: `#dashboard`, `#report`, `#recommend`, `#alert`, `#chart`, `#kb`. * **Your request** — what you need, in your own words. Add any context inline. See the [CloudThinker Language reference](/guide/language) for the full syntax. ```text theme={null} @alex #dashboard build an EC2 cost dashboard for the last 30 days @oliver #report audit security groups open to the internet on ports 22, 3306, and 5432 @anna #report run a quarterly infrastructure review across cost, security, and Kubernetes ``` ## How agents work 1. **Read your prompt** — the agent parses your mention, the optional tool tag, and your instruction. 2. **Query your connections** — the agent reads the [connections](/guide/connections/overview) you've configured: AWS, Azure, GCP, Kubernetes clusters, databases, and more. 3. **Correlate data across sources** — Alex cross-references CloudWatch utilization with Cost Explorer data; Tony reads execution plans alongside query frequency. 4. **Deliver the output you asked for** — a dashboard, report, prioritized recommendations, or an alert. 5. **Act within its autonomy mode** — in Manual mode the agent waits for your [approval](/guide/approval) before executing changes. Every action is logged with an audit trail. ## Autonomy Each agent runs in one of two modes, configurable per agent: | Mode | What happens | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **Manual** | You approve each agent write action before it runs, according to your Tool Permissions. A tool set to **Always allow** still runs without pausing. | | **Auto** | An AI classifier auto-approves agent write actions for this workspace. | See [Auto Mode](/guide/auto-mode) for how Auto executions are scoped, guarded, and audited. ## Memory and context Agents get more accurate over time because they retain what they learn about your environment: | Memory type | What it retains | | ----------- | ----------------------------------------------------------------------------------- | | Episodic | Past analyses and decisions, such as resources you've exempted from recommendations | | Working | Context within the current conversation thread | | Semantic | Patterns learned about your infrastructure over time | | File | Documents, runbooks, and [knowledge base](/guide/knowledge) entries | ## When agents activate Agents become available as you add the relevant connections: | Agent | Available when | | ---------- | ---------------------------------------------------------- | | **Anna** | Always — no connections required | | **Alex** | An AWS, Azure, or GCP connection is added | | **Oliver** | An AWS, Azure, or GCP connection is added | | **Tony** | A PostgreSQL, MySQL, or other database connection is added | | **Kai** | A Kubernetes cluster connection is added | ## Next steps Tune personality, attach connections, and build fully custom agents The complete `@agent #tool instruction` syntax reference Connect cloud providers, databases, and Kubernetes clusters Understand how autonomous execution is scoped and audited # Alex Source: https://docs.cloudthinker.io/guide/agents/alex Analyze cloud costs, right-size resources, and optimize multi-cloud infrastructure across AWS, Azure, and GCP. Alex is CloudThinker's cloud infrastructure expert, specializing in cost optimization, performance tuning, and multi-cloud architecture across AWS, Azure, and GCP. *** ## The problem Alex solves Cloud infrastructure costs are opaque. AWS alone offers 200+ services, each with its own pricing model — compute, storage, data transfer, reserved capacity, spot, savings plans. Most teams only discover their cloud bill is too high when the invoice arrives. By then, months of waste have already compounded. Manual cost management requires: * Exporting cost data and building spreadsheets to find patterns * Running `aws describe-instances` across every region to find idle resources * Manually comparing reserved instance pricing against actual usage patterns * Switching between AWS Cost Explorer, CloudWatch, and resource consoles to correlate cost with utilization This takes days of engineering time each month — time that produces spreadsheets and slides, not actually fixed infrastructure. *** ## What other tools miss | Tool | What It Does | What's Missing | | ------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------- | | **AWS Cost Explorer** | Visualizes historical spend by service/account | No recommendations, no cross-cloud, no action capability | | **CloudHealth / Apptio** | FinOps dashboards and governance reporting | Reporting-only, no AI analysis, expensive, requires dedicated FinOps team | | **AWS Trusted Advisor** | Basic checks for idle resources and reserved capacity | Limited to \~50 checks, no conversational query, AWS-only | | **Infracost** | Cost estimation for IaC changes | Pre-deployment only, no live infrastructure analysis | | **Spot.io** | Automated spot/reserved capacity optimization | Compute-focused, no multi-cloud cost narrative | Alex does what none of these do: it understands your specific usage pattern, explains *why* costs are what they are, and can implement the fix with your [approval](/guide/approval). *** ## How Alex works 1. **Connects to your cloud providers** via read-access credentials — AWS Cost Explorer, CloudWatch, EC2/RDS APIs, Azure Cost Management, GCP Billing 2. **Analyzes in context** — doesn't just pull metrics, but correlates utilization patterns with cost data and your infrastructure topology 3. **Forms recommendations** with specific dollar savings, effort level, risk rating, and implementation steps 4. **Acts on [approval](/guide/approval)** — can execute right-sizing, create reserved instance purchase recommendations, tag resources, or generate IaC diffs for review 5. **Learns your environment** — stores preferences in memory (e.g., which resources are exempt, preferred instance families, cost thresholds) *** ## Capabilities | Domain | Capabilities | | ------------------------------------------------ | -------------------------------------------------------------------------------- | | **[CostOps](/guide/cost-optimization/overview)** | Connection-scoped spend, forecasts, service costs, and verified savings findings | | **Performance** | Auto-scaling, load balancing, network optimization, bottleneck identification | | **Multi-Cloud** | Cross-provider comparison, migration planning, unified management | | **Infrastructure** | Resource management, IaC (Terraform, CloudFormation), architecture design | *** ## Prompt patterns ### Cost analysis ```text theme={null} # Spending overview @alex analyze AWS spending trends over the last quarter # Right-sizing @alex identify EC2 instances with <20% CPU utilization over 30 days # Reserved capacity @alex compare reserved instances vs savings plans for our usage pattern # Waste detection @alex find unattached volumes, unused elastic IPs, and orphaned snapshots ``` ### Performance optimization ```text theme={null} # Auto-scaling review @alex review Auto Scaling groups and recommend threshold adjustments # Network analysis @alex analyze network traffic patterns and load balancer configuration # Bottleneck detection @alex identify resource bottlenecks in the web tier ``` ### Multi-cloud operations ```text theme={null} # Cost comparison @alex compare AWS vs Azure costs for our current workloads # Migration planning @alex create migration plan from on-premise to AWS with cost analysis # Unified analysis @alex analyze spending across AWS, Azure, and GCP with consolidation recommendations ``` ### Infrastructure audit ```text theme={null} # Comprehensive audit @alex audit infrastructure for cost, performance, and security issues # Governance check @alex analyze resources against our cloud governance policies # Architecture review @alex review our microservices architecture for cost efficiency ``` *** ## Tool usage | Tool | Alex Use Case | | ------------ | -------------------------------------------------------------------- | | `#dashboard` | Cost trends, resource utilization, spending by service | | `#report` | Quarterly cost analysis, migration assessments, architecture reviews | | `#recommend` | Right-sizing, reserved capacity purchases, optimization actions | | `#alert` | Budget thresholds, cost spikes, utilization anomalies | | `#chart` | Spending trends, usage patterns, cost forecasts | ### Examples with tools ```text theme={null} @alex #dashboard monthly cost trends by service and region @alex #report cost optimization opportunities with projected savings @alex #recommend instances for right-sizing with implementation steps @alex #alert when daily spend exceeds $5,000 ``` *** ## Effective prompts **Tip: Be specific** ```text theme={null} # Good @alex analyze EC2 instances in us-east-1 with <15% CPU over past 30 days # Avoid @alex check our servers ``` **Tip: Add context** ```text theme={null} # Good @alex recommend cost savings excluding production-critical services prioritizing quick wins # Avoid @alex save money ``` *** ## Connection requirements Alex requires cloud provider connections with cost and performance data access: | Provider | Required Access | | --------- | ----------------------------------------------- | | **AWS** | Cost Explorer, CloudWatch, EC2, RDS, S3, Lambda | | **Azure** | Cost Management, Monitor, Compute, Storage | | **GCP** | Billing, Monitoring, Compute Engine, Cloud SQL | *** ## Common workflows ### Monthly cost review ```text theme={null} # Step 1: Overview @alex #dashboard monthly cost summary by service # Step 2: Identify issues @alex which services had the largest cost increase? # Step 3: Deep dive @alex analyze RDS spending by instance type and utilization # Step 4: Action @alex #recommend cost optimizations with ROI timeline ``` ### Infrastructure optimization ```text theme={null} # Step 1: Discovery @alex audit all resources for optimization opportunities # Step 2: Analysis @alex #report detailed analysis of underutilized resources # Step 3: Implementation @alex #recommend right-sizing actions with rollback plan ``` *** ## Next steps Explore the full cost optimization engine powered by Alex Set up continuous cost guardrails so Alex monitors 24/7 autonomously Master the `@alex #tool` prompt patterns for effective cost analysis Coordinate Alex with other agents for cross-domain operations # Anna Source: https://docs.cloudthinker.io/guide/agents/anna Coordinate multi-agent operations, manage complex cloud projects, and produce executive reports with Anna. Anna is CloudThinker's coordination expert, specializing in multi-agent orchestration, complex project management, executive reporting, and strategic operations that span multiple domains. *** ## The problem Anna solves Complex cloud operations span multiple domains — a cloud migration involves infrastructure (AWS), security requirements (IAM, compliance), database strategy (migration, replication), and container orchestration (Kubernetes). But specialized agents and tools are siloed: Cost Explorer doesn't talk to Security Hub, which doesn't talk to your database monitoring, which doesn't talk to your Kubernetes tooling. When a production incident or large project requires cross-domain coordination, the work falls on senior engineers who manually: * Context-switch between dashboards and tools to gather data from each domain * Synthesize findings into a coherent picture * Write status reports, executive summaries, and board presentations * Track dependencies and timelines across teams with different toolchains This coordination overhead is why major initiatives (cloud migrations, security remediations, quarterly reviews) take weeks instead of days. *** ## What other tools miss | Tool | What It Does | What's Missing | | ------------------------------ | -------------------------------------- | ------------------------------------------------------------------------------ | | **Jira / Linear** | Project tracking and ticket management | Tracks tasks, but doesn't investigate, analyze, or synthesize findings | | **ServiceNow** | ITSM workflows and incident management | Process-heavy, slow, no AI analysis across domains | | **Confluence / Notion** | Documentation and knowledge management | Passive documentation, requires manual data input | | **Spreadsheets + slide decks** | Manual coordination and reporting | Entirely manual, not connected to live infrastructure data | | **Single-agent AI tools** | One AI per domain | Can't coordinate across cost + security + databases + K8s in a single workflow | Anna is the only agent that can orchestrate a multi-domain operation, synthesize findings from [Alex](/guide/agents/alex), [Oliver](/guide/agents/oliver), [Tony](/guide/agents/tony), and [Kai](/guide/agents/kai) simultaneously, and produce an executive-ready deliverable — all from a single prompt. *** ## How Anna works 1. **Receives a complex request** — a project, investigation, or reporting requirement that spans multiple domains 2. **Decomposes into parallel sub-tasks** — determines which agents need to contribute and what each should investigate 3. **Coordinates agent execution** — dispatches tasks to [Alex](/guide/agents/alex), [Oliver](/guide/agents/oliver), [Tony](/guide/agents/tony), and [Kai](/guide/agents/kai) concurrently, with dependencies managed automatically 4. **Synthesizes findings** — collects results from all agents and constructs a coherent narrative that connects cross-domain insights 5. **Produces the deliverable** — executive summary, action plan, board presentation, or remediation roadmap — ready to share without manual editing *** ## Capabilities | Domain | Capabilities | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | **Agent Coordination** | Orchestrating [Alex](/guide/agents/alex), [Oliver](/guide/agents/oliver), [Tony](/guide/agents/tony), [Kai](/guide/agents/kai) for complex operations | | **Project Management** | Multi-phase projects, dependencies, timelines, risk management | | **Executive Reporting** | Strategic summaries, KPI dashboards, board-level presentations | | **Complex Operations** | Cloud migrations, security transformations, infrastructure overhauls | *** ## When to use Anna Use Anna when operations require: * **Multiple agents** working on related aspects of a problem * **Cross-domain expertise** (e.g., security + infrastructure + databases) * **Executive-level visibility** or reporting * **Project coordination** with dependencies and timelines For single-domain tasks, use the specialized agent directly. *** ## Prompt patterns ### Multi-agent coordination ```text theme={null} # Parallel investigation @anna coordinate investigation of production outage: - @alex: infrastructure and resource issues - @tony: database performance and connections - @kai: pod health and networking # Project orchestration @anna manage AWS to Azure migration: - @alex: infrastructure planning and cost analysis - @oliver: security requirements and compliance - @tony: database migration strategy - @kai: container workload transition # Cross-functional analysis @anna coordinate quarterly infrastructure review: - @alex: cost and performance - @oliver: security posture - @tony: database health - @kai: Kubernetes efficiency ``` ### Complex operations ```text theme={null} # Cloud migration @anna orchestrate multi-cloud migration project with timeline and risk assessment # Security transformation @anna coordinate enterprise security remediation with @oliver leading # Infrastructure modernization @anna manage Kubernetes adoption across all environments # Cost optimization initiative @anna coordinate company-wide cost reduction targeting 30% savings ``` ### Executive reporting ```text theme={null} # Strategic summary @anna #report quarterly infrastructure status for executive team # Board presentation @anna prepare board-level cloud transformation summary # KPI dashboard @anna #dashboard executive infrastructure KPIs # ROI analysis @anna analyze ROI of cloud optimization initiatives ``` ### Strategic planning ```text theme={null} # Technology roadmap @anna create 12-month infrastructure modernization roadmap # Capacity planning @anna forecast infrastructure needs for 3x growth # Risk assessment @anna assess risks of current infrastructure with mitigation plan # Investment analysis @anna evaluate cloud investment options with cost-benefit analysis ``` *** ## Tool usage | Tool | Anna Use Case | | ------------ | ---------------------------------------------------------------- | | `#dashboard` | Executive KPIs, project status, multi-domain metrics | | `#report` | Strategic summaries, quarterly reviews, board presentations | | `#recommend` | Strategic initiatives, investment priorities, project sequencing | | `#alert` | Project milestones, risk thresholds, critical findings | | `#chart` | Trend analysis, comparative metrics, progress tracking | Temporary subagents can read from the exact connections available to the agent that delegates the task when the provider exposes a bounded read profile. Other credentialed provider commands fail closed and require an explicit delegated write capability, which follows the same Auto Mode approval as a direct agent action. ### Examples with tools ```text theme={null} @anna #dashboard executive infrastructure overview @anna #report quarterly review with findings from all agents @anna #recommend priority initiatives for next quarter @anna #schedule monthly executive infrastructure summary ``` *** ## Effective prompts **Tip: Define agent roles** ```text theme={null} # Good @anna coordinate security audit: @oliver leads assessment @alex reviews infrastructure impact @kai checks container security # Avoid @anna do a security check ``` **Tip: Specify deliverables** ```text theme={null} # Good @anna #report quarterly review: - Executive summary - Cost trends and savings - Security posture - Recommendations # Avoid @anna summarize things ``` *** ## Connection requirements Anna inherits access from all agents she coordinates: | Agent | Inherited Access | | ---------- | -------------------------------------------------- | | **Alex** | Cloud providers, cost data, infrastructure metrics | | **Oliver** | Security services, compliance data, audit logs | | **Tony** | Database connections, performance metrics | | **Kai** | Kubernetes clusters, container metrics | *** ## Common workflows ### Incident coordination ```text theme={null} # Step 1: Parallel investigation @anna coordinate investigation: @alex check infrastructure and load balancers @tony analyze database performance @kai review pod health and networking # Step 2: Synthesize findings @anna summarize findings and identify root cause # Step 3: Remediation plan @anna #recommend remediation actions with owner assignment # Step 4: Post-incident @anna #report incident analysis with prevention measures ``` ### Quarterly review ```text theme={null} # Step 1: Gather data @anna compile infrastructure metrics from @alex @oliver @tony @kai # Step 2: Analyze @anna identify trends, risks, and opportunities # Step 3: Report @anna #report quarterly infrastructure review for executives # Step 4: Plan @anna #recommend priorities for next quarter ``` ### Cloud migration ```text theme={null} # Step 1: Assessment @anna coordinate migration assessment: @alex: current state and target architecture @oliver: security and compliance requirements @tony: data migration strategy @kai: container migration plan # Step 2: Planning @anna create phased migration plan with dependencies # Step 3: Execution tracking @anna #dashboard migration progress and risk status # Step 4: Validation @anna coordinate post-migration validation across all domains ``` *** ## Next steps Use Anna to coordinate cross-domain incident investigations Generate executive reports and dashboards with Anna Schedule Anna to run quarterly reviews automatically Multi-agent coordination syntax and patterns # Customize Agents Source: https://docs.cloudthinker.io/guide/agents/customize Edit how default agents talk, choose what they can reach, and create your own agents The five default agents work out of the box. Customization lets you change **how they talk** (tone, rules, language) and **what they can reach** (connections). When the defaults aren't enough, you can build your own agent. Open [Agents](https://app.cloudthinker.io/agents) to start. The left panel groups agents into **Core Team** (the five defaults) and **Custom** (your own). Click any agent to open its settings dialog — two tabs (**Identity**, **Connections**). Personality (Instructions, Language, Learning mode) lives at the bottom of the **Identity** tab. Customizing agents requires **workspace admin** permissions. Members can chat with agents but can't edit them. *** ## What you can change | Field | Default agents (Alex, Oliver, Tony, Kai, Anna) | Custom agents | | ----------------------- | -------------------------------------------------------------- | ---------------------------------------- | | @mention | Locked | Set once on creation, can't change later | | Name, Role, Goal | Locked | Editable | | Instructions | Locked | Editable | | Language, Learning mode | Editable | Editable | | Connections | Attach / detach (Anna is read-only — inherits from the others) | Attach / detach | | Active state | Auto — off when no connections (Anna is always on) | Manual | Default agents come pre-optimized for specialized tasks (cloud, security, database, Kubernetes, and Anna for coordination). Their identity and instructions stay locked so the tuning isn't lost — you can still adjust **Language**, **Learning mode**, and **Connections** to fit your workflow. To change how an agent reasons about your environment, create a custom agent instead. *** ## Plan tiers Editing default agents works on **every plan**. Only the number of custom agents changes. | Plan | Custom agents | | ---------- | ------------- | | Free | 1 | | Standard | 1 | | Advanced | 3 | | Pro | 5 | | Team | 5 | | Scale | 10 | | Scale+ | 10 | | Enterprise | Unlimited | Hit the limit? Delete an unused agent or [upgrade your plan](/guide/billing/pricing). *** ## Create a custom agent Need an agent for something the defaults don't cover — a billing analyst, an on-call summarizer, a documentation specialist? Build your own. Click the **+** next to **Custom** on the [Agents](https://app.cloudthinker.io/agents) page, then pick how to create it. You can also reach agent settings from **Chat Settings** (the gear icon beside the **+** button in the chat prompt box) under **Agent Configuration → Agents**. Best when you know **what the agent should do** but don't want to fill every field yourself. Describe what you want in one sentence — Anna takes it from there. She typically confirms: * **Name and @mention** — suggests options based on your description. * **Role and Goal** — drafts both for you to approve or tweak. * **Model Tier** — recommends Light / Pro / Ultra based on task complexity. * **Instructions** — generates a first draft you can refine. * **Connections** — asks which to attach (cloud, database, K8s, MCP). * **Learning mode** — Auto or Offer. Example prompt: *"I need an agent that watches AWS spend and pings me when daily cost jumps more than 20%."* You can edit any field afterward from the agent's settings dialog. Best when you want full control over every field upfront. The dialog walks you through three steps. The header shows your custom-agent quota for the current plan (e.g. "1 of 10 custom agents used" on Scale). * **Avatar** — click the tile to change it (defaults to your initials on a gradient). * **Name** — e.g. "Cost Guardian". * **@mention** — chat handle (e.g. `@cost-guardian`). Lowercase letters, numbers, dots, underscores, and hyphens, starting with a letter, up to 63 characters. Must be unique and can't reuse `@alex`, `@oliver`, `@tony`, `@kai`, `@anna`. **Set once — can't change later.** * **Role** — short title (e.g. "FinOps Specialist"). * **Goal** — one sentence on what this agent does. Click **Next**. Create Custom Agent wizard, step 1 Identity — avatar tile, Name, @mention, Role, and Goal fields * **Model Tier** — pick **Light** (fast, lowest credit cost), **Pro** (balanced), or **Ultra** (max capability, highest credit cost). See [Pricing](/guide/billing/pricing) for current credit multipliers. * **Instructions** — one textarea describing how the agent should behave: what to focus on, how to respond, what to avoid. Write as plain sentences — guidelines, constraints, tone, and response format all live here. * **Language** — reply language. * **Learning mode** — **Auto** saves new skills automatically; **Offer** asks before saving. Click **Next**. Create Custom Agent wizard, step 2 Configuration — Model Tier, Instructions, Language, and Learning mode Optional. Use the **Builtin** and **MCP** tabs to pick which connections this agent can reach. You can attach more later from Agent Settings. Click **Skip and Create** to finish. Create Custom Agent wizard, step 3 Connect — Builtin and MCP tabs with attach connections list The agent appears under **Custom** and is reachable via its @mention handle in chat. *** ## Edit a default agent Change tone, rules, language, and more. The agent's identity (name, @mention, role, goal) stays the same — only how it speaks and behaves changes. Go to [Agents](https://app.cloudthinker.io/agents) and click an agent in **Core Team**. The dialog opens on the **Identity** tab. On the **Identity** tab, Name, Role, Goal, and Instructions are locked with a "Set by CloudThinker, can't be changed" hint; @mention shows "Set once, can't be changed later". Scroll down on the same tab to edit: * **Language** — reply language. * **Learning mode** — **Auto** saves new skills automatically; **Offer** asks before saving. To give an agent your own house rules, hard limits, tone, or response format, create a custom agent — a default agent's Instructions field can't be changed. Click **Save** in the bottom-right. Your changes apply on the next message. Agent Settings dialog showing Identity and Connections tabs, locked Name/@mention/Role/Goal fields, and editable Instructions/Language/Learning mode below on the Identity tab *** ## Attach connections Connections are how an agent reaches your cloud, databases, Kubernetes, or MCP servers. Alex, Oliver, Tony, and Kai start with no connections — you decide what each can touch. From the agent dialog, click **Connections**. The header shows the count (e.g. "3 connections"). Use the sub-tabs to switch between **Builtin** (cloud, database, Kubernetes) and **MCP**. Click **Add** to attach, **Remove** to detach. Save to apply. A default agent with **no connections is automatically off**. Attach at least one to turn it back on. **Anna's connections are managed for you.** Anna coordinates the other agents and inherits their reach, so her Connections tab is read-only. Attach connections to Alex, Oliver, Tony, or Kai instead. *** ## Examples | What you want | What to do | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Tony replies in Vietnamese | Set **Language** to Vietnamese on Tony's **Identity** tab. | | An agent that only recommends, never changes | Create a custom agent with Instructions: *"Recommend only — never propose changes that need write access."* | | Cost reported in EUR with weekly digests | Create a custom agent with Instructions: *"Report cost in EUR. Summarize spend weekly."* Attach a cloud connection. | Instructions are editable on custom agents only. A default agent's Instructions are locked, so tone and rule changes go in a custom agent. *** ## Things to know * Edits apply on the **next** message — in-flight chats finish under the old settings. * Pick a custom agent's @mention carefully — it's set once and you'll be living with it. *** ## Next steps Wire up cloud, database, Kubernetes, and MCP connections Profiles for Alex, Oliver, Tony, Kai, and Anna Add domain knowledge to any agent `@agent #tool` mention syntax # Kai Source: https://docs.cloudthinker.io/guide/agents/kai Manage Kubernetes clusters, optimize container workloads, and troubleshoot EKS, GKE, and AKS with Kai. Kai is CloudThinker's container orchestration expert, specializing in Kubernetes cluster management, workload optimization, autoscaling, and operational troubleshooting across EKS, GKE, AKS, and self-managed clusters. *** ## The problem Kai solves Kubernetes is powerful but deeply complex. Most teams provision resource requests and limits once (or copy them from a template), then never revisit them. Pods get OOMKilled because limits are too low; nodes are underutilized because requests are too high. Cluster autoscaler adds nodes instead of right-sizing workloads. RBAC configurations drift from least-privilege as service accounts accumulate permissions. Operating Kubernetes well requires daily attention from someone with deep expertise: * Monitoring pod resource utilization across hundreds of pods across multiple namespaces * Diagnosing crash loops by reading logs, events, and checking resource constraints * Tuning HPA thresholds, VPA recommendations, and Cluster Autoscaler behavior * Auditing RBAC configurations and network policies for security gaps Most teams have one or two Kubernetes engineers — and they're already overloaded managing infrastructure changes. Proactive optimization rarely happens. *** ## What other tools miss | Tool | What It Does | What's Missing | | ---------------------------------- | ---------------------------------------- | ----------------------------------------------------------------- | | **kubectl** | Direct cluster API access | Raw tool, requires deep expertise, no analysis or recommendations | | **Lens / k9s** | Kubernetes dashboards and CLI | Visualization only, no AI analysis, no recommendations | | **Kubecost** | Kubernetes cost allocation and reporting | Cost visibility only, no troubleshooting or optimization guidance | | **Datadog / Prometheus + Grafana** | Kubernetes metrics and alerting | Monitoring only, still requires expert interpretation to act | | **KEDA / VPA** | Autoscaling automation | Single-purpose tools, no holistic cluster analysis | Kai combines what normally takes kubectl expertise, monitoring dashboards, cost tools, and security scanners — in a single conversational interface that explains issues and recommends specific fixes. *** ## How Kai works 1. **Connects to Kubernetes API** — reads pods, nodes, deployments, services, events, and RBAC configurations across all namespaces 2. **Pulls metrics** — correlates Kubernetes API state with metrics-server data (CPU/memory actual vs. requested) 3. **Identifies inefficiency patterns** — OOMKill history, pending pods, underutilized nodes, misconfigured autoscaling policies 4. **Generates specific recommendations** — exact resource request/limit values based on actual P95 utilization, HPA threshold adjustments, RBAC policy changes 5. **Troubleshoots with context** — when a pod fails, Kai reads logs, events, and resource state simultaneously to identify root cause instead of having you correlate them manually *** ## Capabilities | Domain | Capabilities | | ------------------------- | ----------------------------------------------------------------- | | **Cluster Management** | Health monitoring, node management, resource allocation, upgrades | | **Workload Optimization** | Pod right-sizing, resource requests/limits, scheduling efficiency | | **Autoscaling** | HPA/VPA/Cluster Autoscaler optimization, scaling policies | | **Security** | RBAC auditing, network policies, pod security, secrets management | | **Troubleshooting** | Crash loops, OOMKills, scheduling failures, networking issues | *** ## Supported platforms | Platform | Support Level | | ---------------- | ------------------------------------ | | **Amazon EKS** | Full support with AWS integration | | **Google GKE** | Full support with GCP integration | | **Azure AKS** | Full support with Azure integration | | **Self-Managed** | Kubernetes 1.24+ with metrics-server | *** ## Prompt patterns ### Cluster health ```text theme={null} # Health check @kai check EKS cluster health and pod distribution # Resource utilization @kai analyze cluster resource utilization and identify bottlenecks # Node analysis @kai identify nodes with <30% CPU utilization for consolidation # Multi-cluster view @kai provide health summary across all Kubernetes clusters ``` ### Workload optimization ```text theme={null} # Pod right-sizing @kai analyze pod resource requests/limits and recommend right-sizing # Scheduling efficiency @kai identify pods with resource requests far exceeding actual usage # Cost optimization @kai identify underutilized nodes and recommend consolidation strategy # Namespace analysis @kai analyze resource allocation across namespaces ``` ### Autoscaling ```text theme={null} # HPA review @kai review Horizontal Pod Autoscaler policies and recommend improvements # Scaling analysis @kai analyze scaling patterns and recommend threshold adjustments # VPA assessment @kai evaluate whether Vertical Pod Autoscaler would benefit our workloads # Cluster autoscaling @kai review Cluster Autoscaler configuration for cost efficiency ``` ### Troubleshooting ```text theme={null} # Crash investigation @kai investigate pod crash loops in payment namespace # OOM analysis @kai identify pods experiencing OOMKilled events and recommend fixes # Scheduling issues @kai analyze pending pods and identify scheduling constraints # Network problems @kai investigate network connectivity issues between services ``` ### Security ```text theme={null} # RBAC audit @kai audit RBAC configuration against least-privilege principles # Network policies @kai analyze network policies and recommend security improvements # Pod security @kai identify pods running with excessive privileges # Secrets audit @kai audit secrets management and recommend rotation strategy ``` *** ## Tool usage | Tool | Kai Use Case | | ------------ | -------------------------------------------------------------- | | `#dashboard` | Cluster health, node status, resource utilization, pod metrics | | `#report` | Optimization analysis, security audits, capacity planning | | `#recommend` | Right-sizing, scaling policies, consolidation actions | | `#alert` | OOMKills, node pressure, pod failures, resource thresholds | | `#chart` | Resource trends, scaling patterns, utilization over time | ### Examples with tools ```text theme={null} @kai #dashboard EKS cluster health with node and pod metrics @kai #report cluster optimization opportunities with implementation plan @kai #recommend HPA policies for variable workloads @kai #alert on pod OOMKilled events or node pressure conditions ``` *** ## Effective prompts **Tip: Include cluster context** ```text theme={null} # Good @kai analyze production EKS cluster in us-west-2 for pod resource optimization # Avoid @kai check our containers ``` **Tip: Define success metrics** ```text theme={null} # Good @kai improve cluster utilization while maintaining <30s pod startup and 99.9% availability # Avoid @kai make cluster better ``` *** ## Connection requirements Kai requires Kubernetes cluster access with monitoring capabilities: | Component | Required Access | | ------------------ | ------------------------------------------------- | | **Kubernetes API** | Read access to pods, nodes, deployments, services | | **Metrics Server** | Resource metrics for pods and nodes | | **Events** | Cluster events for troubleshooting | | **Logs** | Container logs for debugging | *** ## Common workflows ### Cluster optimization ```text theme={null} # Step 1: Assess @kai analyze cluster resource utilization # Step 2: Identify waste @kai identify pods with >50% overprovisioned resources # Step 3: Plan @kai #recommend right-sizing with zero-downtime approach # Step 4: Monitor @kai #dashboard track resource utilization after changes ``` ### Incident response ```text theme={null} # Step 1: Identify @kai identify unhealthy pods and failing deployments # Step 2: Investigate @kai analyze logs and events for root cause # Step 3: Remediate @kai #recommend immediate actions to restore service # Step 4: Prevent @kai #recommend changes to prevent recurrence ``` ### Capacity planning ```text theme={null} # Step 1: Baseline @kai analyze current resource consumption patterns # Step 2: Project @kai forecast resource needs for 2x growth # Step 3: Plan @kai #recommend node pool configuration for projected growth # Step 4: Automate @kai #recommend autoscaling policies for demand variations ``` *** ## Next steps Connect Kai to your EKS, GKE, AKS, or self-managed clusters Visualize Kubernetes service dependencies for [RCA](/guide/incident/root-cause-analysis) How Kai investigates Kubernetes incidents automatically Coordinate Kai with [Alex](/guide/agents/alex) for cluster cost + performance optimization # Oliver Source: https://docs.cloudthinker.io/guide/agents/oliver Audit security posture, detect vulnerabilities, and generate compliance evidence across cloud environments. Oliver is CloudThinker's security expert, specializing in compliance auditing, vulnerability assessment, threat detection, and identity management across cloud environments. *** ## The problem Oliver solves Cloud security posture is invisible until it isn't. Security groups get opened to `0.0.0.0/0` during debugging and never closed. IAM roles accumulate permissions across months of tickets. S3 buckets get misconfigured. Compliance frameworks like SOC 2 and HIPAA require evidence collection that takes security teams weeks to assemble manually. The result: most teams discover misconfigurations from breach notifications, failed audits, or penetration test reports — not proactive monitoring. And when a compliance audit arrives, engineers spend 2–4 weeks collecting screenshots and writing evidence docs instead of fixing actual security gaps. *** ## What other tools miss | Tool | What It Does | What's Missing | | --------------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | **AWS Security Hub** | Aggregates findings from GuardDuty, Inspector, Config | No remediation guidance, no compliance narrative, no cross-cloud | | **Wiz / Orca** | Cloud security posture management (CSPM) with risk visualization | Reporting-focused, requires dedicated security analyst to interpret, no AI-driven remediation | | **Prowler / ScoutSuite** | Open-source security scanners | Manual runs, raw output, no prioritization or remediation guidance | | **AWS Config** | Tracks resource configuration drift against rules | Rules-based, no AI analysis, no compliance framework mapping | | **Lacework / Prisma Cloud** | Comprehensive CSPM + CWPP | Expensive, complex, still requires security expertise to act on findings | Oliver goes further: it explains *why* a finding matters in your specific context, maps it to your compliance frameworks, and generates the exact remediation steps for your environment. *** ## How Oliver works 1. **Scans continuously** — reads IAM policies, security group rules, CloudTrail logs, GuardDuty findings, and resource configurations 2. **Prioritizes by context** — not just severity scores, but actual blast radius: is this finding on a production database or a dev sandbox? 3. **Maps to frameworks** — automatically maps findings to SOC 2 controls, HIPAA requirements, PCI-DSS clauses, or whatever you're being audited against 4. **Generates evidence** — produces compliance documentation with the exact format auditors need, including timestamps, configurations, and remediation proofs 5. **Tracks over time** — remembers past findings so you can show compliance trend improvement, not just point-in-time snapshots *** ## Capabilities | Domain | Capabilities | | ---------------------------- | ----------------------------------------------------------------------------- | | **Compliance** | SOC 2, ISO 27001, GDPR, HIPAA, PCI-DSS auditing and evidence collection | | **Vulnerability Assessment** | Security scanning, misconfiguration detection, risk prioritization | | **Threat Detection** | Incident investigation, forensics, anomaly detection, security monitoring | | **Identity & Access** | IAM policy review, privilege analysis, permission optimization, access audits | *** ## Prompt patterns ### Security audits ```text theme={null} # Security group review @oliver audit security groups for overly permissive rules # Scoped audit @oliver audit production security groups for public access on ports 22, 3389, 3306 # Multi-cloud audit @oliver perform unified security audit across AWS, Azure, and GCP # Configuration review @oliver identify misconfigurations that could expose customer data ``` ### Compliance assessment ```text theme={null} # Framework-specific @oliver perform SOC 2 Type II compliance assessment # Multi-framework @oliver evaluate infrastructure against SOC 2, ISO 27001, and GDPR # Evidence generation @oliver #report HIPAA compliance audit with evidence documentation # Gap analysis @oliver identify compliance gaps in IAM, logging, and access control ``` ### Vulnerability management ```text theme={null} # Vulnerability scanning @oliver scan infrastructure for security vulnerabilities with remediation timeline # Priority assessment @oliver identify critical and high-risk vulnerabilities requiring immediate action # Public exposure @oliver find all public-facing resources and assess exposure risk ``` ### Access control ```text theme={null} # IAM audit @oliver audit IAM roles and policies for privilege escalation risks # Permission review @oliver identify over-privileged users and recommend least-privilege changes # Access review @oliver perform quarterly access review: unused accounts, stale permissions # Certificate management @oliver scan for expired or expiring SSL certificates ``` *** ## Tool usage | Tool | Oliver Use Case | | ------------ | ----------------------------------------------------------------- | | `#dashboard` | Compliance status, security posture, finding trends | | `#report` | Audit documentation, compliance evidence, incident analysis | | `#recommend` | Remediation actions, security hardening, policy changes | | `#alert` | Security group changes, policy violations, certificate expiration | | `#chart` | Vulnerability trends, compliance scores, risk distribution | ### Examples with tools ```text theme={null} @oliver #dashboard compliance status across all frameworks @oliver #report SOC 2 assessment with gap analysis and remediation timeline @oliver #recommend security hardening prioritized by risk and effort @oliver #alert on security group changes allowing 0.0.0.0/0 access ``` *** ## Effective prompts **Tip: Define scope** ```text theme={null} # Good @oliver audit production security groups for public access on database ports (3306, 5432, 1433) # Avoid @oliver find security issues ``` **Tip: Specify framework** ```text theme={null} # Good @oliver assess infrastructure for SOC 2 Type II compliance with evidence documentation # Avoid @oliver help with compliance ``` *** ## Connection requirements Oliver requires cloud and security service access: | Provider | Required Access | | --------- | ------------------------------------------------ | | **AWS** | IAM, Security Hub, GuardDuty, CloudTrail, Config | | **Azure** | Security Center, Azure AD, Policy, Monitor | | **GCP** | Security Command Center, IAM, Cloud Audit Logs | *** ## Common workflows ### Security audit workflow ```text theme={null} # Step 1: Scan @oliver scan infrastructure for security vulnerabilities # Step 2: Prioritize @oliver categorize findings by severity and exploitability # Step 3: Remediate @oliver #recommend remediation actions with implementation order # Step 4: Verify @oliver rescan to verify remediation effectiveness ``` ### Compliance assessment workflow ```text theme={null} # Step 1: Assess @oliver perform SOC 2 Type II compliance assessment # Step 2: Document @oliver #report findings with evidence for each control # Step 3: Remediate @oliver create remediation plan for gaps # Step 4: Monitor @oliver #schedule weekly compliance status check ``` ### Incident investigation ```text theme={null} # Step 1: Scope @oliver identify affected resources from security incident # Step 2: Analyze @oliver analyze CloudTrail logs for suspicious activity # Step 3: Document @oliver #report forensic analysis with timeline and root cause # Step 4: Prevent @oliver #recommend controls to prevent recurrence ``` *** ## Next steps Configure [SecOps](/guide/infrastructure/cloudkeepers) Keepers for continuous 24/7 security guardrails Run a Well-Architected assessment with the Security pillar How Oliver assists with security incident investigations Coordinate Oliver with other agents for enterprise-wide security reviews # Tony Source: https://docs.cloudthinker.io/guide/agents/tony Optimize database queries, tune performance, and analyze data across SQL and NoSQL platforms with Tony. Tony is CloudThinker's database expert, specializing in query optimization, performance tuning, backup strategies, and data analytics across SQL and NoSQL platforms. *** ## The problem Tony solves Database performance degrades silently. A missing index on a growing table is invisible until P95 latency spikes and engineers wake up at 2 AM. Connection pool exhaustion looks like an application bug until someone checks the database. Slow queries consume 80% of database CPU while running hundreds of times per day — and nobody knows because there's no system connecting query analytics to infrastructure cost. Diagnosing and fixing these problems normally requires: * Querying `pg_stat_statements` or enabling MySQL slow query log * Reading and interpreting execution plans (EXPLAIN ANALYZE output) * Cross-referencing query patterns against current indexes * Understanding PostgreSQL/MySQL configuration parameters and their tradeoffs This is deep specialist work. Most teams don't have a dedicated DBA, so database performance issues either go unfixed or require expensive consultants. *** ## What other tools miss | Tool | What It Does | What's Missing | | ---------------------------- | ---------------------------------------------------- | ----------------------------------------------------------------------------------- | | **AWS Performance Insights** | Visualizes database load and query waits | AWS RDS only, requires SQL expertise to interpret, no recommendations | | **pganalyze** | PostgreSQL query analytics and index recommendations | PostgreSQL-only, no conversational interface, still needs DBA interpretation | | **Percona Monitoring (PMM)** | Open-source database monitoring | Complex setup, technical dashboards, no AI analysis | | **Datadog APM** | Application + database trace correlation | Monitoring only, no fix recommendations, expensive at scale | | **New Relic / AppDynamics** | Full-stack observability including databases | Visibility tool, not a decision-maker; findings still require expert interpretation | Tony goes beyond monitoring: it reads execution plans, understands your schema context, and tells you exactly which index to create, which query to rewrite, and what configuration change to make — in plain language. *** ## How Tony works 1. **Connects to your databases** via read access — `pg_stat_statements`, MySQL Performance Schema, RDS Performance Insights, Aurora, MongoDB profiler 2. **Identifies slow queries** by analyzing execution times, call frequency, and resource consumption — finding the highest-impact targets automatically 3. **Reads execution plans** — interprets EXPLAIN ANALYZE output to understand table scans, index misses, and join inefficiencies 4. **Recommends with precision** — generates specific `CREATE INDEX` statements, query rewrites, and configuration changes with before/after impact estimates 5. **Understands tradeoffs** — considers write overhead of new indexes, memory implications of configuration changes, and downtime requirements for schema changes *** ## Capabilities | Domain | Capabilities | | ---------------------- | ------------------------------------------------------------------------- | | **Query Optimization** | SQL analysis, execution plans, index recommendations, query rewriting | | **Performance Tuning** | Connection pooling, configuration optimization, bottleneck identification | | **Data Analytics** | Usage patterns, trend analysis, capacity planning, metrics visualization | | **Operations** | Backup/recovery, replication, maintenance, disaster recovery planning | *** ## Supported platforms | Category | Platforms | | ----------------- | ---------------------------------------------- | | **Relational** | PostgreSQL, MySQL, MariaDB, SQL Server, Oracle | | **Cloud Managed** | AWS RDS, Aurora, Azure SQL, Cloud SQL | | **NoSQL** | MongoDB, Redis, DynamoDB, DocumentDB | | **Analytics** | Redshift, BigQuery, Snowflake | *** ## Prompt patterns ### Query analysis ```text theme={null} # Slow query investigation @tony analyze slow queries on production PostgreSQL # Specific performance target @tony identify queries with execution time >2 seconds on orders database # Execution plan analysis @tony analyze execution plans for the 20 slowest queries # Query patterns @tony find queries that could benefit from caching ``` ### Performance optimization ```text theme={null} # Index recommendations @tony analyze missing indexes that would improve performance by >10% # Connection optimization @tony review connection pooling configuration for high-load scenarios # Configuration tuning @tony optimize MySQL 8.0 configuration for high-throughput OLTP with 10k connections # Resource analysis @tony identify queries consuming >5% of total database CPU ``` ### Database health ```text theme={null} # Health check @tony check database health and performance metrics # Replication status @tony assess replication lag and recommend optimization # Storage analysis @tony analyze database growth patterns and recommend archiving strategy # Connection analysis @tony analyze connection usage patterns and identify connection leaks ``` ### Backup & recovery ```text theme={null} # Backup verification @tony verify backup status and recovery procedures for production databases # DR planning @tony create disaster recovery plan with RTO/RPO analysis # Recovery testing @tony recommend backup testing strategy for production databases ``` *** ## Tool usage | Tool | Tony Use Case | | ------------ | --------------------------------------------------------------------- | | `#dashboard` | Query latency (P50/P95/P99), connections, I/O, replication lag | | `#report` | Performance analysis, optimization recommendations, capacity planning | | `#recommend` | Index changes, configuration updates, query rewrites | | `#alert` | Slow queries, connection pool exhaustion, replication lag | | `#chart` | Query trends, resource utilization, growth patterns | ### Examples with tools ```text theme={null} @tony #dashboard database performance metrics for production cluster @tony #report query performance analysis with optimization plan @tony #recommend index optimizations prioritized by impact @tony #alert when P95 query latency exceeds 500ms ``` *** ## Effective prompts **Tip: Include metrics** ```text theme={null} # Good @tony analyze queries with execution time >2 seconds running >100 times daily # Avoid @tony make database faster ``` **Tip: Specify platform** ```text theme={null} # Good @tony optimize MySQL 8.0 for read-heavy workloads with 10k concurrent connections # Avoid @tony check the database ``` *** ## Connection requirements Tony requires database connections with performance metrics access: | Platform | Required Access | | -------------- | ---------------------------------------------------- | | **PostgreSQL** | `pg_stat_statements`, query logs, performance schema | | **MySQL** | Performance Schema, slow query log, status variables | | **RDS/Aurora** | Enhanced Monitoring, Performance Insights | | **MongoDB** | Profiler, `serverStatus`, operation logs | *** ## Common workflows ### Performance crisis response ```text theme={null} # Step 1: Identify @tony identify top 10 slowest queries in last hour # Step 2: Analyze @tony analyze execution plans for problematic queries # Step 3: Optimize @tony #recommend index changes and query rewrites # Step 4: Monitor @tony #dashboard real-time query performance ``` ### Proactive optimization ```text theme={null} # Step 1: Baseline @tony #dashboard current performance metrics # Step 2: Analyze @tony identify optimization opportunities across all databases # Step 3: Prioritize @tony #recommend optimizations ranked by impact and effort # Step 4: Automate @tony #schedule weekly performance review ``` ### Capacity planning ```text theme={null} # Step 1: Analyze growth @tony analyze database growth patterns over last 6 months # Step 2: Forecast @tony predict storage and compute needs for next year # Step 3: Plan @tony #recommend scaling strategy with cost analysis ``` *** ## Next steps Connect Tony to your PostgreSQL databases Connect Tony to your MySQL databases How Tony investigates database-related incidents automatically Coordinate Tony with [Alex](/guide/agents/alex) for infrastructure + database cost optimization # Approval Source: https://docs.cloudthinker.io/guide/approval Configure Manual-mode tool permissions so connection tools run, request inline approval, or remain unavailable Tool Permissions control each connection tool. In Manual mode, a tool set to **Needs approval** pauses that one call for a person to decide, including a read tool. ## Prerequisites * The connections edit permission to change Tool Permissions * The workspace-settings edit permission to switch between Manual and Auto ## Why approval * **You choose tool by tool.** Each connection tool can be **Always allow**, **Needs approval**, or **Never allow**. * **Reads can be gated.** A read-only connection tool can use **Needs approval** in Manual mode. * **The decision is local.** A required-approval decision pauses one inline tool call, not every action in the conversation. * **The record stays visible.** The tool call and its outcome remain in the conversation. ## The three Approval tabs | Tab | What it controls | | ----------------------- | ------------------------------- | | **Approvers** | Who can approve a paused action | | **Tool Permissions** | Each connection tool | | **Command Permissions** | Each CLI command | Approval opens on **Approvers**. ## Configure tool permissions Open **Chat Settings** from the gear icon in the chat prompt box, immediately to the right of the **+** button, then select **Approval** under **Workflow**. You can also start from [Connections](https://app.cloudthinker.io/connectors?tab=builtin-connections). Select the **Tool Permissions** tab. Select the connection whose tools you want to control. Choose a setting for each connection tool: * **Always allow** * **Needs approval** * **Never allow** Connection tool settings showing enabled and approval controls ## Tool permission behavior | Tool permission | In Manual mode | | ------------------ | ------------------------------------------------------------------- | | **Always allow** | The tool can run without an inline approval call | | **Needs approval** | The agent pauses for one inline approval call before that tool runs | | **Never allow** | The tool is unavailable to the agent | Set the control on the tool, not by tool type. A connection read tool can be set to **Needs approval** and pause in Manual mode. ## The approval call When a Manual **Needs approval** call occurs, the agent pauses on that tool call. Review the operation, its reason, and the available details before you choose **Proceed** or **Cancel**. Inline agent approval call with operation details and Proceed or Cancel actions Review the operation details before you choose **Proceed**. An inline approval applies only to the tool call that requested it. ## Manual, Auto, and Tool Permissions The two workspace modes describe how agents run: | Mode | What happens | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **Manual** | You approve each agent write action before it runs, according to your Tool Permissions. A tool set to **Always allow** still runs without pausing. | | **Auto** | An AI classifier auto-approves agent write actions for this workspace. | Select **Manual** or **Auto** from **Agent settings** in the chat prompt box, or from the Auto Mode control at the top of the **Approval** page. The choice is workspace-scoped and takes effect immediately, with no confirmation step. Tool Permissions remain per-tool controls; in Manual mode, they decide whether each connection tool runs, pauses, or stays unavailable. Auto Mode is the active gate when selected and does not apply these per-tool settings. Without the workspace-settings edit permission you see the current mode read-only, marked "Managed by workspace admins". While the workspace is in Manual, the mode rows are hidden from you entirely. In Auto mode the per-tool segmented control is replaced by a read-only badge: **Classifier** for a write, **Allowed** for a read. Switch back to Manual to edit them. When Auto Mode is selected, catalogued reads skip the classifier and catalogued writes receive an Auto Mode decision. See [Auto Mode](/guide/auto-mode) for the exact decision outcomes. ## Auto Mode decision outcomes | Decision | What happens | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **allow** | The catalogued write runs and its decision is recorded | | **require\_approval** | The agent pauses for one inline approval call on that tool call | | **escalate** | The agent stops the escalated action and raises a high-severity alert. Only the same authenticated user can approve one exact unchanged retry from a later explicit message in the same conversation before the escalation expires. | | **hard\_deny** | The tool never runs, and no chat approval can override the decision | After an escalation, new writes latch to the escalated path for the rest of that turn. A repeated escalation also latches new writes for that turn. If the classifier is unavailable or times out, the action falls back to **require\_approval** so a person still decides. The decision log marks it as degraded rather than a real classifier verdict. ## FAQ Yes. In Manual mode, set that connection tool to **Needs approval**. The agent pauses on that read call before it runs. Auto Mode is workspace-scoped. Select **Manual** or **Auto** from **Agent settings** in any chat for that workspace. It is treated as a write, so the classifier decides rather than letting it through. For an MCP connection tool, its **Needs approval** setting is what marks it a write. No. A hard deny never runs and chat cannot override it. ## Related Review the classifier outcomes for catalogued write calls Learn how agents work and collaborate Set up cloud and service connections # Artifacts Source: https://docs.cloudthinker.io/guide/artifacts/overview Create cloud analysis artifacts and download supported artifacts as PDFs Artifacts are the dashboards, reports, comparisons, scorecards, diagrams, and explicitly saved generated files CloudThinker agents create from your connected cloud data. Generated files appear in the conversation first. Click **Save to artifacts** to add one to the **Files** gallery. Describe the insight you need in plain language, and the agent builds a data-backed visual from your [connections](/guide/connections/overview). Charts are components of dashboards and reports, not standalone Artifact types. ## How it works 1. **Ask** — send a prompt using the [CloudThinker Language](/guide/language) syntax: `@agent #tool instruction`. 2. **Gather** — the agent queries live data across your connections: Cost Explorer, CloudWatch, databases, and more. 3. **Generate** — the agent assembles an Artifact with charts, tables, and a written summary. 4. **Save, download, or rerun** — save generated files to Files, download supported Artifacts as PDFs from their PDF URLs, or schedule the prompt to run again. A [scheduled task](/guide/automation/tasks) reruns its prompt in a new scheduled conversation. It may create a fresh Artifact; it does not refresh an existing Artifact in place. AWS cost dashboard with spending trends and cost drivers

AWS cost dashboard with spending trends and cost drivers

## What you can do | Capability | Description | Learn more | | -------------------------------- | ------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | | Build cost dashboards | Alex charts spending trends, service breakdowns, and available forecasts | [Spend and forecast](/guide/cost-optimization/analytics) | | Correlate infrastructure signals | Anna combines health, performance, and cost data across clouds in one view | [Infrastructure analytics](/guide/infrastructure/analytics) | | Report security posture | Oliver summarizes compliance status, open findings, and remediation progress | [Oliver](/guide/agents/oliver) | | Visualize dependencies | Explore resource relationships and blast radius on a live map | [Topology](/guide/infrastructure/topology) | | Schedule recurring reports | Rerun a prompt in a new scheduled conversation; a run may create a fresh Artifact | [Tasks](/guide/automation/tasks) | | Start from inbound webhooks | An inbound webhook starts a conversation or DRE flow; it does not deliver Artifact events to external systems | [Webhooks](/guide/webhooks/overview) | ## Artifact types | Artifact | Description | | -------------------- | --------------------------------------------------------------------------------------------------------------- | | Dashboard | A multi-widget view of related metrics | | Report | A narrative analysis with data, findings, and recommendations | | Comparison | A view that contrasts items, time periods, or environments | | Scorecard | An assessment against defined criteria | | Diagram | A visual of relationships or flows | | Saved generated file | A file shown in the conversation until you select **Save to artifacts**, which adds it to the **Files** gallery | Charts are components of dashboards and reports. The `#chart` tag is not a standalone Artifact type. ## Example prompts Start with a one-line request — agents pick sensible defaults for scope and time range: ```text theme={null} @alex #dashboard AWS spending by service for the last 30 days @oliver #report quarterly security assessment across all accounts @kai #dashboard cluster resource utilization ``` ### Cost analysis dashboard Add structure to the instruction when you need specific breakdowns: ```text theme={null} @alex #dashboard Generate a comprehensive AWS cost dashboard for [start_date] to [end_date]. Include: - Monthly spending trends by service with month-over-month growth rates - Top 10 cost drivers and their utilization patterns - Reserved Instance vs On-Demand cost comparison - Cost anomalies and optimization opportunities with estimated savings Segment by: [cost allocation tags such as environment, team, or application] ``` ### Cross-domain dashboard Ask Anna to correlate data that lives in different systems: ```text theme={null} @anna #dashboard Create an operational dashboard correlating database performance with infrastructure costs for [time_period]. Analyze: - Aurora and DocumentDB query performance metrics - Resource utilization and spending patterns - Correlation between database load and compute and storage costs Context: [recent changes, migrations, or specific concerns] ``` Database and infrastructure correlation dashboard showing performance and cost metrics

Database and infrastructure correlation dashboard

### Charts in dashboards and reports Ask for a chart as part of a dashboard or report: ```text theme={null} @tony #dashboard Create a dashboard for Aurora cluster [cluster-identifier] over the past [time_period]. - Include a query execution time chart with p50, p95, and p99 query latency - Separate lines for read queries vs write queries - Highlight queries exceeding [threshold] ms ``` Aurora query performance time-series chart with p50, p95, p99 latency metrics

Aurora query performance time-series chart

## Reusable templates Save parameterized prompts as templates for recurring investigations, then fill in the `{variables}` on each run: ```text theme={null} Template: database_performance_review @tony #dashboard Create a performance dashboard for Aurora cluster {cluster_id} covering {time_period}. Include: - Slow query analysis (queries exceeding {latency_threshold} ms) - Resource utilization trends (CPU, memory, IOPS) - Replica lag monitoring - Connection pool health Compare against baseline: {comparison_period} Alert on: queries exceeding p95 latency of {latency_threshold} ms Template: cost_anomaly_investigation @alex #report Investigate the cost anomaly for {service_name} on {date}. - Compare costs to the 7-day and 30-day averages - Break down by cost component (compute, storage, I/O, data transfer) - Identify the specific resources driving the increase and quantify the impact - Recommend immediate actions to mitigate ongoing cost increases ``` For example, run `database_performance_review` with `cluster_id=production-aurora-cluster`, `time_period="past 7 days"`, `comparison_period="previous 30 days"`, and `latency_threshold=200`. Performance review dashboard template for Aurora cluster analysis

Performance review dashboard template

## Related Dive deeper into spend trends, forecasts, and cost attribution analysis Correlate performance, cost, and reliability signals across connected clouds Master the full @agent #tool syntax for building effective prompts Rerun prompts in new scheduled conversations # Auto Mode Source: https://docs.cloudthinker.io/guide/auto-mode Choose Manual or Auto for a workspace and understand the decision path for catalogued agent write calls Auto Mode is a workspace-scoped setting for catalogued agent write calls. It evaluates those writes before they run; catalogued reads skip the classifier. ## Why Auto Mode * **One workspace choice.** Select Manual or Auto once for the workspace, not separately for each chat. * **Write decisions stay visible.** Each catalogued write receives a recorded outcome before it runs. * **Reads keep their path.** Catalogued reads skip the Auto Mode classifier. * **Manual remains available.** Switch back to Manual when you want Tool Permissions to control each connection tool directly. ## Choose Manual or Auto Open any chat in the workspace you want to configure. Open **Agent settings** from the pill on the right of the chat prompt box. This is a different control from **Chat Settings**, which is the gear icon beside the **+** button. Under **Approval**, select **Manual** or **Auto**. **Success state:** the selected mode appears in **Agent settings** and applies to every conversation in the workspace. The change takes effect immediately, with no confirmation step. Earlier chat composer showing an Auto Mode control

Select **Manual** or **Auto** from **Agent settings**; the separate control in this older capture is not the current switch.

## Catalogued reads and Tool Permissions A catalogued read is a tool CloudThinker knows as read-only. In Auto mode, catalogued reads skip the classifier. In Manual mode, a connection tool configured as **Needs approval** can pause even when it is a read. **Tool Permissions** are enforced in Manual mode. Open [Approval](/guide/approval), select **Tool Permissions**, then set each connection tool to **Always allow**, **Needs approval**, or **Never allow**. When Auto is selected, Auto Mode is the active gate for catalogued connection calls; the per-tool setting is not evaluated, and each row shows a read-only **Classifier** or **Allowed** badge instead of the segmented control. A tool CloudThinker cannot classify is treated as a write, so the classifier decides rather than letting it through. For an MCP connection tool, its **Needs approval** setting is what marks it a write. Approval settings with the Tool Permissions tab

Tool Permissions control each connection tool separately.

## Decision outcomes | Decision | What happens | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **allow** | The catalogued write runs and its decision is recorded | | **require\_approval** | The agent pauses for one inline approval call on that tool call | | **escalate** | The agent stops the escalated action and raises a high-severity alert. Only the same authenticated user can approve one exact unchanged retry from a later explicit message in the same conversation before the escalation expires. | | **hard\_deny** | The tool never runs, and no chat approval can override the decision | An escalation latches new writes to the escalated path for the rest of that turn. A repeated escalation also latches new writes for that turn. If the classifier is unavailable or times out, the write falls back to **require\_approval** so a person still decides. The decision log marks it as degraded rather than a real classifier verdict. ## What you see in chat An allowed catalogued write stays visible in the chat with its Auto Mode result. Chat showing an Auto Mode allowed result for an agent action

The chat records the Auto Mode result beside the tool action.

## FAQ It is workspace-scoped. Select **Manual** or **Auto** from **Agent settings** in any chat for that workspace. Yes, in Manual mode. Set that connection tool to **Needs approval** in **Tool Permissions**. Only the same authenticated user can approve one exact unchanged retry from a later explicit message in the same conversation before the escalation expires. No. A hard-denied action never runs and chat cannot override it. ## Related Configure per-tool permissions and inline approvals What agents can produce — dashboards, reports, slides How agents work and collaborate Set up cloud and service connections # Autonomous Operations Source: https://docs.cloudthinker.io/guide/automation/autonomous-agents Understand CloudThinker’s scheduled and continuous work, then choose Manual or Auto for your workspace CloudThinker agents can run work without a live prompt through Keepers, scheduled tasks, and Pulse. Manual or Auto is a workspace setting, while Tool Permissions control individual connection tools. ## Why autonomous operations * **Problems get caught early.** Keepers scan connected accounts continuously, so drift surfaces before a routine review. * **Routine work runs itself.** Scheduled tasks run recurring checks or a future one-time task without someone remembering. * **Noise becomes signal.** Pulse suppresses duplicate monitoring events and ranks the clusters that remain. * **You set the boundary.** Tool Permissions and the workspace mode control how an agent can use a connection tool. ## Manual and Auto CloudThinker has two workspace modes: | Mode | What happens | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **Manual** | You approve each agent write action before it runs, according to your Tool Permissions. A tool set to **Always allow** still runs without pausing. | | **Auto** | An AI classifier auto-approves agent write actions for this workspace. | In a chat, open **Agent settings** and select **Manual** or **Auto**. The selected mode applies to every conversation in that workspace. Tool Permissions are separate per-tool controls. In Manual mode, any connection tool set to **Needs approval** can pause, including a read tool. In Auto mode, catalogued reads skip the classifier and catalogued writes receive an Auto Mode decision. See [Approval](/guide/approval) and [Auto Mode](/guide/auto-mode) for the decision paths. Start a workspace in Manual. Move the workspace to Auto after you have reviewed the task and connection-tool patterns you expect agents to use. ## What runs autonomously Three surfaces run work without a live prompt. Configure each one on its own page. | Surface | What it does on its own | Learn more | | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | | **CloudKeepers** (shown as **Keepers** in the app) | Monitor connected accounts and clusters for cost, security, and performance drift, then raise findings and tracked recommendations | [Keepers](/guide/infrastructure/cloudkeepers) | | **Scheduled tasks** | Run a stored prompt on a recurring schedule or at one future time | [Tasks & Scheduling](/guide/automation/tasks) | | **Pulse** | Ingest events from sources like CloudTrail, GuardDuty, and Datadog, suppresses noise, and surfaces ranked clusters that can escalate to [incidents](/guide/incident/overview) | [How Pulse Works](/guide/pulse/overview) | Whichever surface starts the work, the workspace mode selects the gate. Manual mode uses Tool Permissions. Auto Mode uses its decision path to allow a call, request inline approval, escalate it, or deny it; [Auto Mode](/guide/auto-mode) describes those outcomes. ## Stay informed Every autonomous run is logged in the workspace. [Notifications](/guide/notifications) deliver findings, errors, and approval requests to Slack, Teams, or email. Review activity regularly and adjust the workspace mode or Tool Permissions when the work changes. ## Related Configure per-tool permissions for Manual-mode agent actions Review classifier decisions for catalogued write calls Run an agent prompt on a recurring or future one-time schedule Enable autonomous monitors for cost, security, and performance drift # Tasks & Scheduling Source: https://docs.cloudthinker.io/guide/automation/tasks Create recurring or future one-time agent tasks and manage each scheduled run in your workspace Tasks run a stored agent prompt on one timing: a recurring schedule or a future one-time run. Create the task in **Scheduled**, then use **Run now** whenever you need an existing task to run immediately. ## Prerequisites * Permission to schedule tasks in the workspace * Connections are optional; add a [connection](/guide/connections/overview) only when the task needs that service * `@agent` mentions are optional; use one only when you want to choose an agent in the prompt. See [CloudThinker Language](/guide/language) Create tasks from **Scheduled**. The composer calendar control shown in older screens is not part of the current creation flow. Earlier chat composer showing a scheduling control

Open **Scheduled** and select **New scheduled task** instead of using the composer control.

## Create a scheduled task Open **Scheduled** from the workspace navigation, from the **Scheduled** quick action in the Home sidebar, or from **Chat Settings** (the gear icon beside the **+** button in the chat prompt box) under **Workflow → Scheduled**. Select **New scheduled task** to open the task form. Enter a title and prompt. Connections and agent mentions are optional; include them only when the task needs them. ```text theme={null} @kai #alert Check error logs from the last 24 hours and alert on high or critical issues ``` Choose a frequency: **Daily**, **Weekly**, **Monthly**, **No Repeat** (a single future run), or **Custom** (a cron expression). Every task has exactly one timing; there is no unscheduled on-demand task type. A recurring task can also take an optional **Expiration** date, after which it stops running. Select **Schedule task**. **Success state:** the task appears in **Scheduled** with its next run time. ## Timing examples | Timing | Prompt | | --------------- | ------------------------------------------------------------------------------------------------------------ | | Future one-time | `@anna #report Generate an executive infrastructure summary before the next planning meeting` | | Daily | `@alex #report Analyze EC2 spending trends and flag anomalies over $100` | | Every 6 hours | `@kai #alert Monitor Kubernetes pod health and alert on CrashLoopBackOff` | | Weekly | `@oliver #report Run a security audit across all connected AWS accounts` | | Monthly | `@anna #report Generate an executive infrastructure summary with cost, security, and performance highlights` | Start with a recurring task that replaces work your team already does. Scope the prompt to the accounts, regions, and thresholds you need. ## Custom cron expressions **Custom** takes a 5-field cron expression (`minute hour day month weekday`). The minute and hour fields accept a single value, `*`, or a step such as `*/15`; a list or range in those two fields is rejected with "This schedule format is not supported." Day, month, and weekday accept ranges and lists. `MON`–`SUN` names and `?` are converted for you. ```text theme={null} */15 * * * * Every 15 minutes 0 */6 * * * Every 6 hours 0 9 * * MON-FRI 09:00 on weekdays ``` ## Times and time zones You pick times in your local time zone, and CloudThinker stores them in UTC and displays each run back in your zone. A recurring task keeps its local clock time and does not shift for daylight saving, so a run can land an hour off across a DST change. ## Manage tasks Open **Scheduled** to manage the tasks in your workspace. | Action | What it does | | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | View | See the timing, next run, and status for each task | | Run now | Run an existing task immediately after it has been created; this does not create a separate unscheduled task type | | Pause | Temporarily disable a task without deleting its configuration. Past run history is kept | | Edit | Update the prompt, timing, or agent assignment | | Delete | Remove a task that is no longer needed | | View history | Review past runs, including status, start and end time, duration, and any error message. Each run links to its conversation, where the full output lives | ## Task status | Status | What it means | | --------------------- | ---------------------------------------------------------------------------------------------- | | **Pending** | The task is scheduled and waiting for its next run | | **Running** | The run is in progress | | **Succeeded** | The last run finished successfully | | **Failed** | The last run ended with an error | | **Required Approval** | The run paused because an action needs a person to approve it. See [Approval](/guide/approval) | Pair tasks with [notifications](/guide/notifications) so results reach the right people by email or Slack. Review run history periodically to tune prompts and timing. ## Next steps Browse pre-built operations you can schedule as tasks Go beyond schedules with continuous monitoring and operations Configure where task results and failure alerts are delivered Start agent work from an external system's event # Capabilities Source: https://docs.cloudthinker.io/guide/capabilities Look up every tool tag agents accept and the output each one produces — dashboards, reports, recommendations, and alerts. Tool tags tell an agent what kind of output to produce — a dashboard, a report, an alert, and more. Add the tag directly after the agent mention, then write your instruction. ## Syntax ```text theme={null} @agent #tool instruction ``` | Part | What it does | | ------------- | --------------------------------------------------------------------------------------- | | `@agent` | Routes the request to a specific agent: `@alex`, `@oliver`, `@tony`, `@kai`, or `@anna` | | `#tool` | Sets the output format, placed immediately after the mention | | `instruction` | Describes what you want, including scope and constraints | For the full syntax, including combining tags, see [CloudThinker Language](/guide/language). ## Tool tags | Tag | Output | | ------------ | ------------------------------------------------------------------------------------------------ | | `#dashboard` | Interactive dashboard with real-time metrics, filterable views, fullscreen mode, and PDF export | | `#report` | Analysis document with executive summary, detailed findings, and prioritized recommendations | | `#recommend` | Actionable recommendations prioritized by impact, with effort estimates and implementation steps | | `#alert` | Monitoring notification triggered on the condition you define | | `#chart` | Standalone data visualization | | `#kb` | Search results from your organization's knowledge base | ## Dashboards `#dashboard` produces an interactive artifact with live metrics that you can filter, view fullscreen, and export to PDF. See [Artifacts](/guide/artifacts/overview) for how dashboards are stored, shared, and managed. Dashboard Capability ## Examples Generate analysis documents with `#report`: ```text theme={null} @oliver #report SOC 2 compliance assessment @anna #report quarterly infrastructure review ``` Get prioritized actions with `#recommend`: ```text theme={null} @tony #recommend index optimizations for the orders table @alex #recommend cost savings opportunities prioritized by impact ``` Set up monitoring and visualizations with `#alert` and `#chart`: ```text theme={null} @kai #alert when node CPU exceeds 80% for 5 minutes @alex #chart spending by service over the last 6 months ``` Add detailed instructions to shape the output: ```text theme={null} @alex #dashboard AWS costs for the last 30 days - Filter by production accounts only - Show daily cost breakdown - Include cost optimization recommendations ``` ## Related The complete `@agent #tool instruction` syntax reference and prompt patterns Run pre-built operations that use these tool tags Schedule outputs to run automatically — daily reports, weekly audits See which outputs each agent specializes in # Code Review Analytics Source: https://docs.cloudthinker.io/guide/code-review/analytics Use Code Review Analytics to track review coverage, recurring findings, trends, and repository reports. Code Review Analytics shows review activity, recurring findings, and evidence-backed trends across your repositories. Access it from **Code Review → Insights** in the navigation. ## Analytics tabs The Analytics section has two tabs: | Tab | What it shows | | ------------------- | ------------------------------------------------------------------------------------------------------------- | | **Review Patterns** | Which finding domains affect confirmed Advanced-reviewed merge requests and which findings explain the result | | **Reports** | Which repository-level review reports are ready | Review Patterns opens by default. A saved link to a retired tab also opens Review Patterns. ## Review Patterns Review Patterns is the coaching view. It uses literal merge-request outcomes and links each pattern to its finding evidence. ### Eligibility Review Patterns includes only completed, non-draft, live Advanced Reviews with an exact persisted outcome. Fast Reviews, shadow decisions, incomplete reviews, pipeline findings, main-agent findings, unknown specialists, and bot authors do not affect a domain fraction. Historical rows without an exact outcome stay excluded. The read path does not infer completion or finding ownership from timestamps or from the presence of findings. ### Reading the rates The view covers four domains: Security, Performance, Correctness, and Patterns. Each domain shows the finding-free merge-request rate and its literal numerator and denominator. A domain rate is: ```text theme={null} finding-free merge requests / reviewed merge requests ``` One merge request contributes once to a selected period. If several eligible outcomes exist, the merge request uses the latest included completion for its author and period bucket, and the union of all included outcomes' linked findings affects the domain rates. Several findings in one domain still affect the merge request once. Resolved and unresolved findings count equally. A developer with fewer than three eligible merge requests stays visible with **Not enough data** and the reviewed count. Their merge requests still contribute to the pooled team rate. ### Main coaching priority The page headlines the domain with the highest pooled affected merge-request rate. An exact tie breaks on the Critical and High finding counts, and every domain still tied appears. Severity never weights a rate. ### Explore evidence Select a developer-domain cell to see the developer and pooled team across the selected weekly or monthly buckets. The expanded view lists the associated findings with severity, resolution state, merge-request identity, and a review link. A resolved finding remains historical coaching evidence. ## Periods and states The weekly and monthly controls are the only analytics controls, and they apply to Review Patterns. The view keeps your selections while data loads or a request fails. | View | Available periods | | ------- | ---------------------------------------- | | Weekly | This week, or the last 4, 8, or 12 weeks | | Monthly | Last 3, 6, or 12 months | The view handles thin periods explicitly: * No confirmed Advanced Reviews: the page explains that the period has no eligible data. * One or two eligible merge requests: the view shows counts without a percentage. * No eligible merge requests in a trend bucket: the chart shows a gap labelled **No data**. * A failed summary or detail request: the affected surface offers Retry without discarding the current period or selection. ## Related Connect repositories and choose where CloudThinker reviews code Encode team standards to reduce recurring findings Learn how CloudThinker reviews merge requests and reports findings # Auto-Resolve Conflicts Source: https://docs.cloudthinker.io/guide/code-review/conflict-resolution Detect merge conflicts on open merge requests and let CloudThinker resolve them through an automatic follow-up MR When a merge request conflicts with its target branch, CloudThinker flags it — and, with **Auto-Resolve Conflicts** on, resolves it on a separate branch and opens a follow-up MR for you to review and merge. *** ## Detect conflicts Detection is automatic and always on. When an open MR conflicts with its target branch, CloudThinker marks it with a **conflict badge** on the **Reviews** page. Once a follow-up MR exists, the same row links to it as **Resolution MR**. Reviews page showing conflicting merge requests with a conflict badge and Resolution MR links

Conflicting MRs are badged on the Reviews page and link to their Resolution MR

*** ## Turn on auto-resolve In **Code Review → Settings**, turn on **Auto-Resolve Conflicts**. The toggle applies to the whole workspace and controls only whether resolution runs — detection stays on either way. Code Review settings with the Auto-Resolve Conflicts toggle turned on

Turn on Auto-Resolve Conflicts in Code Review → Settings

Auto-Resolve supports **GitLab**, **GitHub**, **Bitbucket**, and **AWS CodeCommit**. Azure DevOps is not supported. *** ## How resolution works 1. CloudThinker posts a **🔄 Conflict Resolution In Progress** comment and starts an isolated run. 2. It builds a resolution branch from your MR's source, then **merges** the target branch into it — never a rebase, so your history is preserved. Structural conflicts (rename, delete, add/add, binary) keep the MR side. 3. It opens a follow-up MR targeting your source branch, titled `fix: resolve merge conflicts for `, and updates the comment with the link. 4. You review and merge the follow-up. CloudThinker never merges for you — once it's merged, your original MR is mergeable again. On GitLab, merge the follow-up MR **without squash**. Squashing drops the merge ancestry GitLab needs to see the original conflict as resolved. Follow-up merge request resolving conflicts for the original MR, with the do-not-squash reminder and a Ready to merge state

Merge the follow-up MR to make your original MR mergeable

*** ## Status comments CloudThinker keeps one status comment on your MR and edits it in place: | Comment | Meaning | | ----------------------- | ---------------------------------------------------------------------------------- | | 🔄 **In Progress** | A run is creating or updating the follow-up MR. | | ✅ **Complete** | The follow-up MR is ready — the comment links to it. | | ✅ **Already Resolved** | The conflict cleared on its own (for example, you rebased). No follow-up needed. | | ✅ **No Changes Needed** | Resolving produced no changes — your MR is usually already mergeable. | | ⚠️ **Failed** | The run was interrupted. CloudThinker retries on the next push to the base branch. | CloudThinker Conflict Resolution Complete comment on the merge request linking to the follow-up MR

The status comment links to the follow-up MR when resolution completes

*** ## Good to know * **Your branch is never touched.** Resolution happens on a CloudThinker-owned `cloudthinker/` branch; your branch and its history stay as-is, and protected branches like `main` are never pushed to. * **Your work is preserved.** The resolver verifies the resolved diff still contains your MR's change before it pushes, and you review the follow-up MR before merging. * **It keeps up with the base.** If the base moves again, the same follow-up MR updates in place; if it was already merged, a new one is opened. * **Not a mention command.** Auto-resolve is fully automatic. `@cloudthinker-ai autofix` is separate — it fixes review findings, not conflicts. *** ## Related Connect your repositories for automated code review Interact with CloudThinker directly from PR and MR comments # Convention Rules Source: https://docs.cloudthinker.io/guide/code-review/convention-rules Guide the AI reviewer with your team's coding conventions, both the convention files already in your repository and rules CloudThinker learns automatically from past reviews. Convention Rules keep CloudThinker's Code Review aligned with how your team actually writes code. It works in two ways: * **The reviewer follows your existing conventions.** It loads the convention files already in your repository on demand, so it reviews against the same standards your coding assistants already use. * **The reviewer learns from past reviews.** The issues your team keeps running into, and keeps fixing, become reusable rules that the reviewer applies to future PRs on its own. *** ## How it works * **Your existing convention files.** Point the reviewer at the coding-assistant convention files your team already maintains, such as `CLAUDE.md`, `.claude/rules/`, `AGENTS.md`, or `.cursorrules`. The reviewer loads them on demand during each review, so there's nothing to author. * **Rules learned from past reviews.** On a schedule you choose, CloudThinker looks at the review findings your team has already resolved on a repository, turns the recurring ones into named rules, and applies those rules in later reviews. You review the results from the **Conventions** page. The two work independently or together. *** ## Use your existing convention files In **Code Review → Settings**, find the repository and select the **Convention Rules** icon under **Actions**. Code Review settings with the Convention Rules repository action highlighted

Open Convention Rules from the repository's actions

Choose the coding assistant tool your team uses in the Convention Rules dialog: Convention Rules dialog showing supported coding assistant tools and custom path options

Select the coding assistant whose convention files the reviewer should follow

Select **Save**. The AI reviewer automatically finds and reads the matching convention files during each review. Just select your convention rules tool. The AI reviewer finds and reads the convention files in your repository for you, so there's no need to specify exact file paths. ### Supported tools | Tool | Convention file paths | | ------------------ | ------------------------------------------ | | Cursor | `.cursor/rules/`, `.cursorrules` | | Claude Code | `CLAUDE.md`, `AGENTS.md`, `.claude/rules/` | | GitHub Copilot | `.github/copilot-instructions.md` | | Windsurf | `.windsurf/rules/`, `.windsurfrules` | | Cline | `.clinerules/`, `.clinerules` | | Roo Code | `.roo/rules/`, `.roorules` | | Aider | `CONVENTIONS.md` | | Zed | `.rules` | | Trae | `.trae/rules/` | | Augment Code | `.augment/rules/` | | Amazon Q | `.amazonq/rules/` | | JetBrains AI | `.junie/AGENTS.md`, `AGENTS.md` | | OpenAI Codex | `AGENTS.md` | | Gemini Code Assist | `GEMINI.md` | | Continue | `.continuerules`, `.continue/rules/` | | Kiro | `.kiro/steering/` | | Custom | Specify your platform | ### Custom convention paths You can add **Custom Convention Paths** to point the reviewer at additional convention files or directories in your repository. This is useful when your team keeps convention files in non-standard locations or uses more than one tool. Click **+ Add path** in the Convention Rules dialog to specify relative paths to additional convention files or directories. *** ## Rules learned from past reviews CloudThinker learns your team's coding conventions from each repository's default branch and applies them in future reviews. As your team resolves review findings, the recurring ones become named rules. New rules show up on the **Conventions** page after the next scheduled run, so the reviewer keeps catching the issues your team cares about without anyone writing rules by hand. Until the first run finishes, the **Conventions** page is empty. Rules appear on their own after the next scheduled run for the repository, once it has enough resolved review findings to learn from. ### Set the update schedule Rule updates run per repository on a cadence you choose. In **Code Review → Settings**, use the **Convention Rules** column to pick how often CloudThinker refreshes a repository's rules: Code Review settings showing the Convention Rules schedule options

Choose how often CloudThinker updates learned rules for a repository

| Option | Behavior | | ----------- | ------------------------------------------------- | | **Off** | Don't update rules for this repository | | **Weekly** | Refresh rules once a week, on Saturday | | **Monthly** | Refresh rules once a month, on the first Saturday | Weekly runs happen every Saturday, in either the 00:00 UTC or the 12:00 UTC hour — after the work week, so updated rules are in place before Monday's reviews. CloudThinker assigns your repository one of those two times and keeps it, so runs land at the same time every week. Monthly runs use the same time on the first Saturday of the month. The **Convention Rules** column shows the next scheduled run. The first run does not wait for the weekend. When you turn the schedule on for a repository, the first run starts soon after, so the first week can contain two runs: that first one, then the repository's regular Saturday run. The second run only covers findings resolved since the first. If a run is missed — during maintenance, for example — CloudThinker picks it up on the next check that week. Select **Run now** to refresh a repository's rules immediately. The schedule becomes available once Code Review is enabled for the repository and the repository has finished cloning. If the control is unavailable, confirm that the repository is ready and that you have permission to change its Convention Rules schedule. ### Review learned rules Open **Conventions** under **Code Review** to review learned rules. Rules are generated automatically; from this page, you can read them, filter the list, and turn individual rules on or off. Conventions page showing learned rules, filters, categories, citation counts, and active switches

Review learned rules and control which ones are active

| Column | What it shows | | -------------- | --------------------------------------------------------------------- | | **Rule** | The rule's name and a short identifier (slug) | | **Category** | The type of convention, such as security, performance, or correctness | | **Repository** | The repository the rule came from | | **Cited** | How many past review findings referenced this rule | | **Created** | When CloudThinker created the rule | | **Active** | A switch to turn an individual rule on or off | Keep an eye on the **Cited** count. It shows which conventions your team runs into most, so you can tell at a glance what matters and decide which rules to keep, fix at the source, or turn off. Filters at the top of the table help you find rules: * **Search** by slug or title. * **Repository** to focus on one or more repositories. * **Status** to show only **Active** or **Disabled** rules. Turn off any rule you don't want the reviewer to apply, and turn it back on later at any time. ### Read a rule Click a row to open the complete rule. The detail view shows the rule's category, identifier, citation count, description, guidance, and examples. You can also change its active status from this view. Convention rule detail showing its identifier, citation count, guidance, and active status

Open a learned rule to read its full guidance

*** ## Permissions Viewing rules and changing their schedule or active status use separate workspace permissions. Without view access, the **Conventions** page asks you to contact your workspace admin. With view-only access, you can read rules, but the schedule and **Active** controls are disabled. Ask a workspace admin for access to change the schedule or turn rules on and off. *** ## FAQ No. The two work independently, so you can use either or both. Convention files are read right away; learned rules build up from your reviews over time. Rules show up after the first scheduled run for a repository. Make sure Code Review is enabled, the repository has finished cloning, and the Convention Rules schedule is set to Weekly or Monthly rather than Off. A new repository also needs enough resolved review findings before the first rules appear. The schedule turns on once Code Review is enabled, the repository has finished cloning, and you have permission to change its Convention Rules schedule. Yes. Turn the rule off in the **Active** column. It stops applying to reviews right away, and you can turn it back on at any time. *** ## Related Connect your repositories for automated code review Pull issue-tracker context into reviews automatically # Extensions Source: https://docs.cloudthinker.io/guide/code-review/extensions Enrich code reviews with context from issue trackers Extensions connect your issue trackers to CloudThinker's code review agent. When the agent detects issue references in your MR/PR description or branch name, it automatically fetches the linked ticket details and uses them as context during the review — validating that the code change fulfills the requirements. *** ## Available extensions ### Jira / Confluence Brings Jira ticket details and Confluence specs directly into code reviews so the agent understands the business requirement behind every change. **How it works:** When the review agent detects a Jira or Confluence link in your MR/PR description, it automatically fetches the ticket details — summary, acceptance criteria, and linked pages — and uses that context to validate whether the code change fulfills the requirement. **Triggers:** | Pattern | Example | | ---------------------------------------- | ------------------------------------------------------- | | Jira URL in description | `https://myorg.atlassian.net/browse/OPS-1234` | | Confluence page URL in description | `https://myorg.atlassian.net/wiki/spaces/.../pages/...` | | Ticket key in description or branch name | `OPS-1234` | **Requires:** [Atlassian connection](/guide/connections/atlassian) *** ### GitHub Issues Pulls GitHub issue context into code reviews so the agent can verify that pull requests address the linked issue requirements. **How it works:** When the review agent finds issue references in your PR description or branch name, it fetches the issue details — title, body, labels, and comments — and reviews the code changes against those requirements. **Triggers:** | Pattern | Example | | -------------------------------- | -------------------------------------------- | | Issue keywords in PR description | `Closes #123`, `Fixes #456`, `Resolves #789` | | Issue reference in description | `#123` | Only shown when your code review is configured with GitHub as the provider. *** ### GitLab Issues Pulls GitLab issue context into code reviews so the agent can verify that merge requests address the linked issue requirements. **How it works:** When the review agent finds issue references in your MR description or branch name, it fetches the issue details — title, description, labels, and comments — and reviews the code changes against those requirements. **Triggers:** | Pattern | Example | | -------------------------------- | -------------------------------------------- | | Issue keywords in MR description | `Closes #123`, `Fixes #456`, `Resolves #789` | | Issue reference in description | `#123` | Only shown when your code review is configured with GitLab as the provider. *** ## Setup Navigate to **Workspace Settings** > **Connections** and connect the relevant service ([Atlassian](/guide/connections/atlassian), GitHub, or GitLab) Go to **Code Review** > **Extensions** to verify the connection status shows "Connected" Add issue links or ticket keys to your MR/PR description. The review agent detects them automatically — no additional configuration needed. *** ## How the agent uses issue context When the code review agent detects an issue reference, it: 1. **Fetches** the ticket or issue details (title, description, acceptance criteria, labels, comments) 2. **Validates** whether the code changes fulfill the stated requirements 3. **Flags** missing or incomplete implementations based on acceptance criteria 4. **References** the ticket context in review findings so you can see the connection between requirements and code This is fully automatic — no commands or configuration beyond the initial connection setup. *** ## Tips * **Include links in your MR/PR description** — the agent scans the description and branch name for references. The more context you provide, the better the review. * **Acceptance criteria matter** — well-structured Jira tickets with clear acceptance criteria give the agent the strongest signal for validating code changes. * **Multiple references are supported** — link as many tickets or issues as relevant. The agent fetches all of them. *** ## Related Configure code review for your repositories Customize what CloudThinker checks in your code # Mention Commands Source: https://docs.cloudthinker.io/guide/code-review/mention-commands Interact with CloudThinker directly from MR/PR comments Mention `@cloudthinker-ai` in any merge request or pull request comment to trigger commands — autofix findings, ask questions about the review, or get help. Mention commands are currently available on **GitLab** and **GitHub** only. Bitbucket and Azure DevOps support is coming soon. *** ## Commands | Command | What it does | | ------------------------------------- | ----------------------------------------------------------------------------- | | `@cloudthinker-ai help` | Shows available commands as a comment | | `@cloudthinker-ai autofix` | Fixes unresolved findings and pushes the result to the original source branch | | `@cloudthinker-ai autofix stacked pr` | Fixes findings on a session branch, then opens a follow-up MR/PR | | `@cloudthinker-ai ` | Ask a free-form question about the code review | *** ## How autofix works Post `@cloudthinker-ai autofix` (or `@cloudthinker-ai autofix stacked pr`) as a comment on the MR/PR CloudThinker picks up all unresolved findings from the review An agent implements fixes for each finding, following your codebase conventions CloudThinker commits and pushes the changes automatically. Direct autofix uses the original source branch; stacked autofix uses its session branch and opens a follow-up MR/PR. ### Direct vs. stacked PR * **`@cloudthinker-ai autofix`** — Commits and pushes directly to the original MR/PR source branch. Findings are marked resolved after fixing. * **`@cloudthinker-ai autofix stacked pr`** — Creates and pushes a session branch, then opens a follow-up MR/PR targeting the original source branch. Findings stay open for your review. *** ## Free-form questions Ask anything about the code review by mentioning `@cloudthinker-ai` followed by your question: ```text theme={null} @cloudthinker-ai why was this function flagged as a security risk? @cloudthinker-ai can you explain the performance impact of this change? @cloudthinker-ai what's the best way to refactor this? ``` ### Thread-aware context * **Reply in a finding's thread** — The agent sees only that specific finding's details (severity, file, line, suggested fix), giving you a focused answer. * **Top-level comment** — The agent sees all unresolved findings from the review, giving you a broader perspective. *** ## Supported providers | Provider | Mention Trigger | Thread Support | Status | | ------------ | -------------------------------- | ---------------------- | ----------- | | GitLab | `@cloudthinker-ai` in MR note | Discussion threads | Available | | GitHub | `@cloudthinker-ai` in PR comment | Review comment replies | Available | | Bitbucket | — | — | Coming soon | | Azure DevOps | — | — | Coming soon | *** ## Tips * **One autofix at a time** — Only one autofix can run per MR/PR. Wait for the current one to finish before starting another. * **Reuse conversation context** — Free-form replies in the same thread reuse the conversation context, so follow-up questions build on previous answers. * **Autofix pushes automatically** — Autofix does not pause for human approval before pushing changes. *** ## Related Connect your repositories for automated code review Customize what CloudThinker checks in your code # AI Code Review Source: https://docs.cloudthinker.io/guide/code-review/overview Catch bugs, security vulnerabilities, and quality issues on every pull request with context-aware AI reviews CloudThinker reviews every pull request on your connected GitHub or GitLab repositories with full context of what the change is trying to do, not just individual lines. Findings appear as in-line comments with severity ratings and remediation guidance.