Operations | Monitoring | ITSM | DevOps | Cloud

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.

You get an answer from the agent and no way to check how it got there. The route it took is recorded, and so is the reason it gave for taking it. AURA emits OpenTelemetry spans, and the Docker quickstart wires them straight into Phoenix. Four services come up together: AURA Web Server as the persistent agent harness, LibreChat as a browser interface for chatting with the agent, Phoenix to receive the spans, and MongoDB to store stateful data for LibreChat. The Compose file arrives pre-configured to point AURA at Phoenix and to enable content recording for the local demo.

Building an agent and not sure how to approach something? Bring it. AURA office hours are recurring working sessions with the people who build it. The team has been talking to people trying out AURA and hearing the same good questions come up more than once. Office hours are the answer to that: a standing slot on a schedule, rather than one conversation at a time. The format is deliberately loose. Nobody is arriving with thirty slides to spend an hour talking at you. The session goes wherever the questions go.

A big tool result does not have to be a big context cost. AURA moves it to disk and hands the model a pointer plus the tools to navigate what is there. A large MCP tool result can consume or overflow an agent's context window, and on a third-party server you do not control how much comes back. Scratchpad breaks the link between how big a tool result is and how much context it costs: the full output goes to disk, and only the slice the model asks for ever enters the window. Errors always pass through inline, so the model can react to them.

The model, the serving layer, and the agent asking questions all sit on local hardware. The first thing it debugs is the AI stack it is running on. No external inference provider in the path.

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.

An on-call question returns the threshold and the escalation owner from your own runbooks, and the answer comes back without a call to anyone outside. AURA runs against Bedrock as its model provider, using Claude Sonnet 5 served by AWS in the same region. Authentication is the normal AWS credential chain: a profile on a laptop, an IAM role in EKS.

The platform shows you which service is failing and which paths it touches, and stops there. Point AURA at the same telemetry and the cause comes back too. Dash0 shows the product catalog service in a failed state across the selected window, with errors on the path from the frontend service.

You ask for a routine health check and expect a clean baseline. What came back was a pod that had restarted 788 times, unrelated to the question. AURA is connected to a Kubernetes cluster and to Prometheus through read-only MCP servers, running as one coordinator with two specialized workers. The prompt is one sentence: check the health of the cluster, and confirm whether all the pods are running. What comes back is not a baseline. AURA names the state as CrashLoopBackOff and attaches the restart count to it.

Knowing why it broke is not the same as having it repaired. Point the agent at the repos behind the service and the change comes back as a pull request. A Govee integration crash-loops under Home Assistant because the container cannot write to a directory it does not own. That much was already established: the previous homelab video stopped at the root cause on purpose, so the next pass could improve the agent's configuration first.