Multi-Agent Orchestration for SRE: A Model per Specialist

Give one agent every tool and every incident is a question of trust. This one hands each job to a worker that can only reach what that job needs.

One AURA configuration defines a coordinator and three specialist workers. Qdrant stores the runbooks, Prometheus measures workload health, and Kubernetes provides inspection and remediation, and each of the three is wired to one worker.

GPT-5.6 is the coordinator. It plans the response, passes each verified result to the next specialist, and writes the final report, and it does not use the worker tools directly. Inkling Small is the metric analyst, with inference provided by Baseten, reading Prometheus to measure the failure without the ability to change the cluster. GLM-5.2-Fast is the runbook specialist, retrieving the approved checkout recovery procedure and its stop conditions. DeepSeek V4 Flash is the Kubernetes remediator, inspecting the deployment and pods, making one scale call, and verifying recovery.

With checkout taken offline, AURA gets one short request: investigate and recover only if the evidence supports the approved procedure. The workflow comes from the configuration. AURA confirms zero replicas in Prometheus, retrieves the matching runbook, and verifies the same state in Kubernetes before anything changes.

The remediation is bounded. Kubernetes access controls keep the remediator limited to checkout, the run makes one scale call from zero to two replicas, and the final check finds two desired and two ready. The evidence stays visible at each step.

Chapters:

0:00 One request, four models, a verified recovery

0:08 Evidence and action surfaces in the configuration

0:16 Kubernetes tools and the GPT-5.6 coordinator

0:27 The three specialists and their models

0:57 One request against an offline checkout

1:08 Investigation, scale call, and verification

1:27 What the run shows

#AISRE #Kubernetes #AIAgents

‍

Transcript

One request, four models, a verified recovery

0:00 One request, four models, a verified recovery. AURA coordinates the team while each specialist works inside a defined boundary.

Evidence and action surfaces in the configuration

0:08 The configuration starts with the team's evidence and action surfaces. Qdrant stores the runbook. Prometheus measures workload health.

Kubernetes tools and the GPT-5.6 coordinator

0:16 Kubernetes provides inspection and remediation. GPT-5.6 is the coordinator. It plans the response, passes each verified result to the next specialist, and writes the final report. It does not use the worker tools directly.

The three specialists and their models

0:27 Inkling Small is the metric-analyst, with inference provided by Baseten. It reads Prometheus to measure the failure, but it cannot change the cluster.

GLM-5.2-Fast is the runbook-specialist. It uses the metric finding to retrieve the approved checkout recovery procedure and its stop conditions.

DeepSeek V4 Flash is the kubernetes-remediator. It can inspect the deployment and pods, make one scale call, and verify recovery. Kubernetes access controls keep it limited to checkout.

One request against an offline checkout

0:57 We take checkout offline, then give AURA one short request: investigate and recover only if the evidence supports the approved procedure.

Investigation, scale call, and verification

1:08 The workflow comes from the configuration. AURA confirms zero replicas in Prometheus, retrieves the matching runbook, and verifies the same state in Kubernetes.

DeepSeek makes one scale call, changing checkout from zero to two replicas. The final check finds two desired and two ready. The evidence stays visible at each step.

What the run shows

1:27 One request. Specialized models. Bounded tools. A recovery verified against the live system. That is AURA orchestrating a team of agents. Thanks for watching.

AURA use cases

Table of contents