Fragmented operating context
Accounts, regions, metrics, logs, billing systems, cloud controls, and infrastructure repositories each held a different part of the operational truth.
Client work / Agentic cloud operations
Building a secure agentic cloud operations platform.
Drizzle built the platform foundation beneath an agentic AI SRE product, connecting authenticated interaction, stateful reasoning, private cloud tools, scoped identity, proactive briefings, and production delivery controls.
OPERATING MODEL / BOUNDED AUTONOMY Cloud operations agent
Team chat Coding agent Schedules
- AUTHENTICATE Agent Gateway Channel, tenant, conversation
- REASON LangGraph runtime State, model, memory, traces
- EXECUTE TOOLS Private MCP Gateway Typed tools, scoped identity
- OBSERVE Customer cloud state Cost, metrics, logs, alarms
Investigate autonomously Prepare transparently Change with approval
TIME TO READINESS Around 2 months Leadership-reported production readiness milestone
TRUST FOOTPRINT 100+ Growth companies in the leadership-reported footprint
SENIOR TEAM 6 Engineers enabled by one shared platform foundation
MCP TOOL PLANE 11 Typed tools registered in the inspected gateway
The constraint
The difficult part was governed action across fragmented cloud estates.
Dashboards exposed data and generic assistants explained text. The missing capability was an operating system that could establish context, collect evidence, reason through it, and keep authority explicit.
Reasoning without authority boundaries
A generic assistant could summarize data, but it could not safely establish tenant identity, select cloud scope, acquire credentials, or prove what it was allowed to do.
A demo was not a product
Useful autonomy also required memory, typed tools, proactive work, health controls, immutable delivery, rollback, and evidence that the platform could be operated.
THE PLATFORM DECISION
Put identity, memory, tools, credentials, telemetry, and approval into
the platform so every agent workflow inherits the same trust boundary.
Bounded autonomy
Investigation could move quickly. Authority stayed governed.
The operating model separated what the implementation verified from the broader product workflow and the intended mutation boundary. That distinction kept autonomy credible.
- 01 Implemented
Investigate
The inspected platform could gather evidence and answer operational questions without receiving mutation authority.
- Query cost and usage
- Inspect metrics, logs, and alarms
- Search cloud documentation
- Compare deterministic baselines
- 02 Product model
Prepare
The broader product workflow described how an investigation becomes a reviewable engineering change.
- Explain expected blast radius
- Locate infrastructure as code
- Draft the smallest viable change
- Define the verification query
- 03 Approval gated
Change
Consequential actions remained behind explicit approval, a privileged execution identity, and an auditable delivery path.
- Require human or policy approval
- Use scoped execution authority
- Promote through normal delivery
- Verify live state after release
Platform engagement
One platform function multiplied a senior product team.
Drizzle connected product intent, agent runtime, cloud tooling, security, Kubernetes, infrastructure as code, testing, and production diagnostics as one delivery path.
-
Separate reasoning from authority
Drizzle defined the tenant, identity, tool, credential, and approval boundaries before increasing agent autonomy.
-
Create the agent and tool planes
We implemented an authenticated Agent Gateway, a stateful LangGraph runtime, and a private MCP Gateway with stable cloud tool contracts.
-
Support interactive and proactive work
Natural language investigation and scheduled briefings shared the same tenant context, cloud identity, telemetry, and evidence model.
-
Make release safety part of the product
Kubernetes, Terraform, security checks, immutable promotion, smoke tests, health probes, scaling controls, and rollback completed the production path.
DELIVERY TEAM Six senior engineers
Stable contracts for identity, memory, models, tools, cloud access, notifications, and delivery allowed the team to build product capabilities without recreating the platform underneath them.
Product engineering Agent runtime Cloud tooling Platform and SRE Security controls Release engineering
The system
Two gateways kept interaction and cloud authority separate.
The public Agent Gateway authenticated the collaboration surface. The private MCP Gateway owned cloud tools and credential use. LangGraph connected them without making the model the security boundary.
01 / INTERACTION AND TRIGGERS
Team chat Coding agent and IDE Schedules and cloud events
Signed requests, OAuth, tenant resolution, streaming, and conversation context.
Explicit state, model policy, tool loop, persistent memory, traces, and evaluations.
Tenant middleware, typed registry, provider adapters, and credential broker.
05 / CUSTOMER CLOUD CONTROL PLANES
AWS Source-inspected runtime and tooling GCP Provider-neutral schema and reported scope Azure Provider-neutral schema and reported scope
What Drizzle delivered
The agent loop sat on a complete operating substrate.
The engagement delivered reusable platform capabilities, not a prompt demo or one tightly coupled assistant.
Authenticated Agent Gateway
Signed channel requests, OAuth installations, tenant resolution, conversation routing, streaming, and approval surfaces formed one narrow external boundary.
Observable LangGraph runtime
Explicit graph state, parallel tool execution, durable checkpoints, model policy, and graceful tracing degradation made agent behavior inspectable and testable.
Private MCP tool plane
A separately deployable gateway exposed a finite registry of typed, tenant aware cloud capabilities over private service networking.
Short-lived cloud identity
Tenant selection happened before credential creation. AWS role assumption, external identifiers, Pod Identity, and read-only secret mounts constrained authority.
Proactive operations path
Scheduled cost and reliability analysis published typed events through durable queues so the platform could surface evidence before an engineer asked.
Production delivery system
Development, staging, and production promoted the same immutable artifact through security checks, environment smoke tests, and a controlled rollback path.
Evidence ledger
Reported outcomes and inspected implementation stay distinct.
Each number is paired with its evidence class. This preserves what leadership reported while keeping repository observations precise.
Time from the start of the platform build to the reported production readiness milestone.
Growth companies in the reported product trust and adoption footprint.
Typed tools registered in the inspected private gateway across tenant context, cost, documentation, logs, alarms, and metrics.
Python test functions counted across services, shared libraries, agent code, infrastructure helpers, and adapted tooling.
Agent interface, MCP tools, scheduled briefing, and asynchronous notification workloads on one secure platform substrate.
Isolated development, staging, and production paths with immutable artifact promotion and environment specific validation.
Verification scope. The test count is a source count, not a claim that every test ran during preparation of this case study. GCP and Azure runtime parity was not present in the inspected snapshot.
Production operations
Four workload types shared one secure platform substrate.
Interactive traffic, private tool execution, scheduled analysis, and asynchronous delivery had different scaling profiles but inherited the same identity, telemetry, release, and health controls.
01 AGENT
Interaction service
Authenticated chat, OAuth, streaming, tenant context, and persistent conversations.
02 TOOLS
MCP Gateway
Private tool execution with typed inputs, bounded results, and tenant scoped credentials.
03 BRIEF
Briefing worker
Scheduled cost and reliability analysis with deterministic calculation metadata.
04 NOTIFY
Notification worker
Typed events, durable queues, retries, correlation identifiers, and channel delivery.
SHARED OPERATING CONTROLS
Pod IdentityShort-lived rolesSecrets ManagerHorizontal scalingDisruption budgetsTopology spreadHealth probesSmoke and rollback
Product impact
Cloud operations became evidence-backed conversations.
The platform turned fragmented operational inputs into explainable investigation while keeping the boundary between evidence, advice, and action visible.
Explain cloud spend
- Before
- Billing data without operating context
- After
- Daily briefings and follow-up questions grounded in scoped cost and usage evidence.
Investigate live reliability
- Before
- Manual movement across dashboards and accounts
- After
- Tenant aware queries across metrics, logs, alarms, documentation, and deterministic baselines.
Prepare an engineering fix
- Before
- Advice disconnected from the delivery system
- After
- A product model that names blast radius, infrastructure ownership, the proposed change, and its verification path.
Keep control over change
- Before
- Autonomy confused with unrestricted access
- After
- Read-oriented investigation with consequential mutation reserved for explicit authority and approval.
Engagement record
Architecture, controls, delivery, and evidence in one view.
The visual record traces the system from the product constraint to the final operating model, with reported outcomes and inspected implementation kept visibly separate.
Platform leverage
The result was a reusable operating foundation, not one isolated agent.
Drizzle built the substrate close to production, then left stable boundaries that the product team could extend across new tools, channels, workflows, and cloud providers.
- 01 Agent and platform code
The runtime, gateways, tooling, infrastructure, and release system remained inside the product engineering boundary.
- 02 Stable tool contracts
New agents and channels could consume the same capabilities without importing credentials or provider implementation details.
- 03 Operational evidence
Health, logs, traces, release summaries, smoke tests, queue behavior, and rollback outcomes exposed the real state of the platform.
- 04 A bounded autonomy model
The team received a reusable way to distinguish autonomous investigation, reviewable preparation, and governed mutation.
Your agentic platform
Give the agent useful tools without giving away control.
Bring the workload, the cloud boundary, and the operating model. We will identify the first governed agent loop worth proving.
Talk to an engineer