Operations | Monitoring | ITSM | DevOps | Cloud

Running an agent in your cluster should not mean opening it to the internet. AURA reaches Slack over an outbound socket, so the cluster stays locked down. Jeff Vogt connects an AURA deployment running in Kubernetes to Slack using AURA's direct Slack integration. The setup is a Slack app with an app token and a bot token, plus a few lines added to the deployment's configuration. The Kubernetes MCP server is already deployed and connected to AURA before the video starts.

The bucket is right there and the function still cannot read it. AURA reads the failure, names the one missing action, and returns the policy to add. A permissions failure gives you the symptom and not the action name. The usual path is reading the error, guessing which actions the execution role is short, and widening the policy until the call goes through. Greg hands AURA a Lambda function that fails when it tries to reach an S3 bucket. AURA identifies the missing ListBucket permission on that particular bucket and returns the minimum policy needed to allow it.

AURA runs as a standalone service and knows nothing about Slack. A separate bridge streams events off its API, which is what makes the chat tool swappable. This is the implementation behind the automated PagerDuty investigation demo. Jeff Vogt walks the whole path an incident takes: a Grafana alert fires PagerDuty, PagerDuty opens a Slack channel and sends a webhook, and a service called AURA Bridge picks it up and calls AURA's API with an investigation prompt.

Two engineers can hold the same approve button and still not be allowed to make the same change. The key riding with the approval settles it. AURA's human in the loop config gates the create_pipeline tool on the Mezmo MCP server and sends each request to a webhook for review. A mock UI stands in for the approval system here, and Mike walks through the payload schema so you can point it at your own.

Nobody wants an API key sitting in an agent's config file on a shared server. Mike shows how AURA takes the credential off the request instead. AURA can hold your keys in its config file, but it does not have to. Mike Shearer, one of AURA's creators, walks through the alternative: AURA reads named headers off the incoming request and forwards them to the MCP servers it calls, so the credential never has to sit on disk.

Ingestion stops, and you start reading system tables by hand to find out why. This run checks disk, merges, and replication across every replica first.

3 a.m., the pager fires, and the runbook describes a service that shipped three versions ago. Ask the agent what the cluster actually has instead. Runbooks go stale because clusters change faster than documentation does. Every deploy, every new service, every renamed alert widens the gap between what is running and what is written down.

1,133 requests failed on one bad commit. The patch and the regression test are already written by the time anyone is asked to read the exact diff. This demo runs AURA as one step inside a Temporal workflow, alongside Codex. A GET request against a product catalog service goes from success to HTTP 500, and ClickHouse records the version, commit, trace ID, and exact error for every request. By the time AURA investigates, all 1,133 requests on that version have failed.

Checkout starts failing because the cart service keeps dying. The real cause is a recent pull request that let memory grow with every add to cart.

The same agent that reads a Kubernetes cluster reads a Windows machine. One MCP server, one config entry, and the questions are the ones you already ask.