Inside Batuta AI: Autonomous Server Debugging with ReAct Loop

Posted on Oct 11 • Originally published at getorquesta.com

Originally published at getorquesta.com/blog/batuta-ai-autonomous-server-debugging

Every engineer knows the drill: an alert fires, you SSH into a VM, tail logs, run a few commands, stare at stack traces, and eventually find the culprit. Then you fix it, restart the service, and verify. It’s tedious, especially when you’re juggling multiple incidents or it’s 3 AM.

We built Batuta AI to handle this entire loop without human intervention. It’s not a fancy autocomplete or a chatbot—it’s an autonomous agent that connects to your cloud VMs over SSH, reasons about the problem, executes commands, observes results, and iterates until the issue is resolved. Under the hood, it uses a ReAct loop (Think, Act, Observe, Repeat), which we’ve tuned specifically for infrastructure debugging.

ReAct (Reasoning + Acting) is a prompt engineering pattern where the model first "thinks" about what to do next, then executes an action, observes the output, and uses that observation to decide the next step. Batuta’s implementation is a tight cycle:

Unlike a simple script that runs a fixed sequence of commands, Batuta can adapt. If a command fails or returns unexpected output, it pivots. If it needs to inspect a file, it reads it. If it needs to restart a service, it does so and then checks health endpoints. This flexibility is what makes autonomous debugging possible.

Batuta runs on your own machine (or any host you designate) and uses SSH to connect to target servers. You provide SSH credentials or keys via Orquesta’s secure vault—they never leave your infrastructure. The agent does not operate in a cloud sandbox; everything happens locally, with full control over which servers it can access.

A typical Batuta task begins with a natural language prompt, like:

Batuta, debug why the API service on server api-prod-01 is returning 500 errors on the /users endpoint. Enter fullscreen mode Exit fullscreen mode The agent then:

All commands are streamed back to Orquesta’s live terminal, so you can watch the reasoning unfold in real time. If you don’t like a step, you can interrupt and redirect.

Let’s walk through a real incident we reproduced internally. A Node.js service kept crashing with ECONNRESET after a deploy. Here’s the condensed ReAct trace:

Think: The service is failing on outbound HTTP calls. Check recent logs for the stack trace.

Act: journalctl -u api -n 200 --no-pager

Observe: Logs show Error: connect ECONNRESET 10.0.1.15:5432 — a database connection issue.

Think: The database might be unreachable or overloaded. Test connectivity from the server.

Observe: Connection refused. The database server isn’t listening on that port.

Think: Check if the database process is running on that host.

Act: ssh db-prod-01 'systemctl status postgresql'

Observe: postgresql.service is active but listening only on localhost. The recent deploy may have overwritten postgresql.conf.

Think: Inspect the configuration file for listen_addresses.

Act: ssh db-prod-01 'grep listen_addresses /etc/postgresql/14/main/postgresql.conf'

Observe: listen_addresses = 'localhost' — it should be * or the private IP.

Think: Fix the configuration and restart PostgreSQL.

Act: ssh db-prod-01 'sed -i "s/listen_addresses =.*/listen_addresses = \'*\'/" /etc/postgresql/14/main/postgresql.conf && systemctl restart postgresql'

Think: Verify the API service can now reach the database.

Think: Restart the API service and test the /users endpoint.

Act: systemctl restart api && curl -I http://localhost:3000/users

Batuta then creates a git commit with the configuration change (if the server is managed via configuration files) and posts a summary to the Orquesta dashboard, including the root cause and the exact commands executed.

Another classic: a server’s disk fills up, causing writes to fail. Batuta was prompted:

Disk usage is at 98% on worker-02. Find large files and clean up safely. Enter fullscreen mode Exit fullscreen mode Here’s the condensed flow:

Batuta handled the whole cleanup without human intervention, including the safety check on log shippers.

Batuta’s ReAct loop excels at multi-step debugging because it maintains a working memory of the investigation. It can chain together commands, conditionally branch, and even ask for clarification if the prompt is ambiguous. For example, if you say "fix the high CPU on prod", Batuta might first identify the process, then check if it’s a known issue, then apply a patch or roll back a recent deploy—all while keeping you informed.

We’ve also built in safeguards: Batuta will not execute destructive commands ( rm -rf, DROP TABLE, etc.) without explicit confirmation. You can configure a deny list of commands, and every action is logged with a full audit trail.

Batuta is one of four execution modes in Orquesta. When you submit a prompt through the web dashboard, CLI, or Telegram bot, you can choose:

All modes stream output into the Agent Grid, where you can monitor dozens of agents in parallel. Quality gates can be applied: before Batuta makes a change, an AI simulation shows the expected diff, and a team lead can approve or reject. Your CLAUDE.md coding standards are automatically synced to every agent run, ensuring consistent practices.

Since Batuta operates over SSH, security is paramount. SSH keys are encrypted with AES-256 and stored locally; they never leave your machine. Batuta uses the same SSH config as your local environment, so it respects your ~/.ssh/config and known hosts. Every action—prompt, command, output, diff, cost—is recorded in the audit trail, making it easy to review what the agent did and why.

Batuta AI turns the tedious cycle of SSH debugging into a well-reasoned, autonomous process. By combining the ReAct loop with direct SSH execution, it can handle multi-step incidents—from diagnosing a crashed service to cleaning up disk space—without human hand-holding. We built it to give engineers back their time and reduce mean time to resolution. It’s not magic; it’s a disciplined loop of thinking, acting, and observing, applied relentlessly until the job is done.