Building an AI SRE Assistant From Scratch: Architecture of an Autonomous Infrastructure Investigator

What if your on-call engineer never slept, had instant access to every repository and every AWS account, and could trace a production issue from DNS to database in under a minute?

That’s the question that led me to build TARS, an AI-powered SRE assistant that autonomously investigates infrastructure issues by combining LLM reasoning with deep integrations into GitLab and AWS. Named after the robot from Interstellar (because every good internal tool needs a movie reference), TARS is a full-stack application where engineers interact with an AI agent through a chat interface. The agent doesn’t just answer questions. It investigates. It clones repos, greps code, reads CloudWatch logs, traces DNS chains, inspects ECS services, and synthesizes findings into structured reports.

Building an AI-Powered Platform Operations Agent

Platform engineering teams handle a constant stream of repetitive requests: onboarding users, managing API keys, checking service health, rotating credentials. Most of these tasks follow well-defined procedures that a human executes step by step. What if an AI agent could handle them instead?

In this post, I’ll walk through the architecture of an AI-powered operations agent that automates common platform tasks by giving an LLM access to your internal tools through a structured tool-calling interface.

Building Interactive CLI Tools in Go with Bubbletea

If you’ve ever wanted to build a terminal application that feels more like a proper UI than a wall of text, the charmbracelet ecosystem is the way to go. I’ve been using it to build internal DevOps tools, and the developer experience is excellent. In this post, I’ll walk through building an interactive CLI tool using Bubbletea and Huh, the same libraries behind tools like gum and soft-serve.

Managing Multi-Account AWS Infrastructure with Terraform Workspaces

When you’re managing infrastructure across dozens of AWS accounts, you need patterns that scale. In this post I’ll share the approach I use to manage multi-account, multi-environment AWS infrastructure using Terraform workspaces, modular code, and a consistent tagging strategy.

The Problem

Imagine this setup: you have multiple organizational scopes (teams, business units, projects), each with their own AWS accounts for non-production and production. On top of that, your non-production account hosts multiple environments (dev, integration, certification). Multiply this by several countries or regions, and you’re looking at a lot of infrastructure to manage.