Skip to main content
Designing an agent organization is organizational design. The same questions apply: who owns what, who reports to whom, and how do they hand off work.

​
5.1 The core roster

Most production deployments settle on a small team of agents, each with a clear scope. Stable roles matter more than they sound: an agent that keeps the same scope and memory over time builds up context, trust, and accountability the way a human teammate does. A representative roster, with where each role lives in CloudThinker. There, the built-in CloudThinker assistant plays the orchestrator (the SuperAgent role: the one agent that splits work, routes it, and escalates to people). It spawns temporary subagents for each domain, and you add custom agents for specialists you want to keep. Beyond the core roster, organizations add custom agents: specialists configured for their own surfaces and objectives, such as cost optimization for a specific business unit, performance for a flagship application, or productivity workflows for the platform team. Custom agents extend the orchestrator-led team. They add to the model; they never replace it.
Start with the built-in assistant and add a custom agent only when a recurring task has an owner, a clear scope, and a success measure. A custom agent with a vague scope produces vague findings. Create one in More → Workspace settings → Agents, write its scope in Instructions, and attach only the Connections it needs. Secrets go in Credentials, not in chat. See the custom agent quickstart.

​
5.2 How work flows through the team

Consider a representative production incident at 02:40: checkout latency breaches its SLO.
  1. Detect. The sensing layer correlates a latency alert, a spike in database connection errors, and a deploy that landed 22 minutes earlier into a single incident, suppressing forty-one downstream alerts.
  2. Analyze. The orchestrator engages the database and Kubernetes specialists in parallel. The database agent finds connection-pool exhaustion driven by a new N+1 query pattern; the Kubernetes agent confirms pods are healthy and rules out infrastructure. The orchestrator integrates both findings into a root-cause hypothesis with evidence attached: the new deploy introduced the query pattern.
  3. Resolve. Policy allows automatic rollback of deploys under 60 minutes old during SLO breach. The orchestrator executes the rollback (an L3 pre-approved action), posts the full reasoning chain to the team’s incident channel, where the on-call engineer reads it in the morning, and pages no one.
  4. Validate. Latency returns to baseline within four minutes; error rates clear. The system confirms SLO recovery, opens a problem ticket for the engineering team with the offending query identified, drafts the post-incident report, and stores the pattern in memory.
Elapsed time: under ten minutes, zero humans woken. The next morning, an engineer reviews the report, fixes the query, and approves the re-deploy. That split (machines handle the 02:40 mechanics, humans handle the engineering judgment at 09:00) is the model working as intended. In CloudThinker, you’d express the rollback policy in two parts. An Allow Rule covers the rollback operation on the production connection, with Runs from set to Resolve, so the write can run without a person once CloudThinker turns on Rule enforcement for your workspace. A runbook states when to use it: deploy under 60 minutes old, SLO breached. Until enforcement is on, your Approval mode decides every write on its own, so an Auto mode is what lets the rollback run unattended.

​
5.3 Agent-to-human interfaces

Agents live where engineers live. The dominant interface pattern is conversational-plus-evidence: agents post findings, plans, and approval requests into Slack or Teams with full reasoning chains, links to evidence, and one-click approve/reject actions. Dashboards remain for trends and audits; the operational conversation happens in chat. Two interface rules matter disproportionately:
  1. Show the work. Every conclusion ships with the data examined, the hypotheses considered, and the reason alternatives were rejected. Transparent reasoning is the biggest driver of engineer trust, and the fix for the black-box failure that sank AIOps.
  2. Make approval cheap and refusal informative. Approvals should be one click with full context; rejections should capture why, because every rejection is training signal for policy tuning.

​
5.4 Proof: four deployments

Four anonymized deployments, with the autonomy each started at, its scope, and what was measured. Three have results. The fourth is in progress.

​
1. Consumer-finance lender

  • Problem. An AWS estate spread across many accounts. Cost and incident work was manual, and finding the cause of a failing lending app took hours of cross-account search.
  • Autonomy granted. L1 investigation across every account for a four-week baseline, checked against the operators’ own root-cause analysis. Then L2 on cost and hygiene actions, with fixes prepared for one-click approval.
  • Stayed human-gated. The core lending path stayed advisory throughout.
  • Result. Within three months: the results in the table above, plus around-the-clock watch on critical apps.

​
2. Digital-payments platform

  • Problem. Three production Kubernetes clusters needed a version upgrade with no downtime window, while RDS replica spend climbed.
  • Autonomy granted. L2 to L3 on Kubernetes lifecycle, right-sizing, self-healing, and replica scaling, as pre-approved action classes.
  • Stayed human-gated. The upgrade’s irreversible steps.
  • Result. The upgrade ran on all three clusters with zero customer-visible downtime. Replica and run-rate savings landed within three months.

​
3. AI / SaaS platform

  • Problem. Investors wanted SOC 2 and HIPAA readiness across three regions under GDPR, against a strict availability target.
  • Autonomy granted. L2 on compliance guardrails, and L2 to L3 on operational remediation, with every compliance-relevant step logged as it happened.
  • Result. A three-region deployment in four weeks. Readiness here means controls automated and evidence collected as work happens, not a completed audit.

​
4. Telco cloud provider (in progress)

  • Problem. Hundreds of operators running health checks, drift fixes, and audit evidence by hand. MTTR stayed flat as tools and headcount grew.
  • Autonomy planned. L1 investigation across the fleet, then L2 on routine cluster health and drift, then L3 on the safest repeated actions (cluster restarts, capacity changes, certificate rotation).
  • Stays human-gated. The regulated control path, with an immutable trail on every action.
  • Result. Measurement is under way. Figures will be published when the window closes.
None of these is a core-banking deployment. Contact us for regulated-bank references.
How the hyperscalers ship agents as teammates
  • AWS DevOps Agent starts investigations from alerts and routes findings and mitigation steps to Slack and ServiceNow.
  • Azure SRE Agent lets teams add their own subagents and connects to other tools through MCP servers.
The lesson: meet engineers in the tools they already use, and show the reasoning with every finding. In CloudThinker, that means Slack, Microsoft Teams, and Google Chat for chat, ServiceNow for ITSM, and PagerDuty as an alert source.

​
Next steps

Custom agent quickstart

Create your first custom agent with a clear scope and only the connections it needs.

Chapter 6: Trust, Guardrails, and Governance

Set the guardrails and data controls that let agents earn more autonomy safely.