Skip to main content
The reference architecture production deployments are converging on: an orchestrator, a team of specialists, a closed operational loop, and a context layer.

​
4.1 Why multi-agent, not mono-agent

This chapter describes the vendor-neutral pattern. Sections 4.2 to 4.4 show where each part lives in CloudThinker, and Chapter 10.3 compares it with the hyperscalers’ own agents. Production systems use orchestrated teams of specialists instead of one all-purpose agent. The reasons are practical:
  1. Depth beats breadth. A Kubernetes specialist with curated K8s tools, prompts, and learned patterns outperforms a generalist on K8s problems, the same way human teams specialize.
  2. Bounded blast radius. Each specialist holds only the credentials its domain requires. A database agent cannot modify security groups; a cost agent cannot drop tables.
  3. Independent evolution. Specialists can be upgraded, evaluated, and rolled back independently. It’s the microservices lesson applied to agents.
  4. Auditable handoffs. Inter-agent delegation produces an explicit trail of who decided what, which monolithic reasoning hides.
The design consequence: the orchestration layer (routing tasks, managing context, handling errors) needs as much engineering as the agents themselves. Two published accounts set the limits:
  • For specialization. Anthropic’s multi-agent research system uses a lead agent that splits work across parallel workers. It reports large quality gains over a single agent, at much higher token cost. That cost is why the two-tier design in 4.3 matters.
  • Against overdoing it. Microsoft’s Azure SRE Agent team wrote that they started with 100+ tools and 50+ narrow agents, and ended with five core tools and a handful of generalists. Specialize by domain and credential boundary, not into dozens of micro-agents. Every agent and tool you add costs context, tokens, and coordination.

​
4.2 The reference architecture

A production agentic operations platform has five layers. Use them as a checklist when you evaluate any platform or design your own.

​
4.3 Two-tier sensing and resolving

Naive agent designs run one model call per alert and fall over at production scale. Mature platforms separate two tiers: a cheap, always-on sensing tier that watches every signal, and an expensive reasoning tier that runs a full multi-step investigation only when the sensing tier finds something worth it. This is what makes 24/7 coverage affordable. When you evaluate a platform, ask how it decides what reaches the expensive tier, because that decision drives your model bill. In CloudThinker, Pulse is the sensing tier. It drops duplicates and noise, groups related alerts into clusters, and sends only clusters with an actionable signal to triage, where CloudThinker opens or matches an incident and investigates. You tune what escalates in three places:
  • Snoozes in noise suppression drop events you already know about.
  • The On duty switch in Resolve → Investigation decides whether CloudThinker investigates on its own or waits for someone to click Investigate. See Resolve.
  • Which sources you connect in Pulse setup decides what reaches Pulse at all.

​
4.4 Data protection inside the pipeline

In regulated industries, telemetry is sensitive: logs and queries leak customer PII, credentials, and account data. The emerging best practice is a tokenization boundary: a PII-aware layer that replaces sensitive values with tokens before any data reaches a model. Combined with a private deployment, it lets banks and other regulated firms adopt agentic operations without raw telemetry leaving their perimeter. Chapter 6 covers data residency and control in depth.

​
In CloudThinker

  • Masking. Guardrails replace sensitive values with placeholders before an agent reads them. Email, phone, credit card, IBAN, MAC address, API keys, and cloud credentials are on by default. IP addresses, public keys, and cloud account IDs are off by default. You can add your own ID patterns in Admin Settings → Guardrails.
  • Deployment. CloudThinker Cloud, Cloud plus Workers on your own machines, and dedicated, self-hosted, or air-gapped deployments through an early-access program. See Deployment options.
  • Model calls on your account. BYOK runs model calls on your own model provider account.

​
Architecture checklist

Ask any vendor, or your own team:
  1. Does one orchestrator own cross-cutting reasoning and escalation to people?
  2. Does each specialist hold only the credentials its domain needs?
  3. Does every piece of work go through detect, analyze, resolve, validate, with the outcome checked after acting?
  4. Is there a cheap sensing tier in front of the expensive reasoning tier, and can you tune what escalates?
  5. Are personal identifiers and secrets masked before any model call?
  6. Is there a private or self-hosted deployment option for regulated workloads?
  7. Does the system keep memory between incidents, so it doesn’t start cold each time?

​
Next steps

Chapter 5: The Agent Team

See how the specialist layer maps to real operational domains.

Chapter 6: Trust, Guardrails, and Governance

Set the guardrails, approvals, and data controls this architecture needs.