You, Your Tools, and Your Team of AI Agents – By Owen Zanzal

3 months ago 1

Zoom image will be displayed

Lately, I’ve been thinking a lot about the intersection of DevOps and AI. Not just how AI might impact DevOps as a discipline, but how DevOps engineers like me can actually use AI — personally — in a way that feels meaningful, useful, and aligned with how we already work.

For a while, I didn’t have a clear sense of where those two worlds really connected. Sure, I’d seen AI tooling — GitHub Copilot, PR reviewers, LLMs in the terminal. But most of it felt generic, disconnected from the nuances that matter when you’re deep in the guts of a system.

Then I came across two things that shifted my thinking:

A podcast from Daniel Miessler, where he talks about the idea of Human 3.0 — a future where we all have personalized AI agents (pAI) that work alongside us.
And an article from GitHub Next exploring how AI agents might integrate with the GitHub ecosystem — not just generating code, but participating in continuous workflows.

That’s when the idea clicked for me: personal AI — or what I’ve started calling pAI — isn’t just about saving time. It’s about encoding your own standards, preferences, and decision-making into agents that help you work better. It’s about showing up to a problem not just as you, but as you + your AI team.

I’ve been experimenting with LLMs in the CLI. I’ve tried out tools like AI-based PR reviewers. Some are helpful. But most of them miss the mark — not because the models are bad, but because they lack my context.

They don’t know how I think about infrastructure. They don’t understand the communication norms in my org. They don’t follow the coding practices I care about or the tradeoffs I’m usually weighing.

pAI, to me, is about building that context into the loop.

That means codifying:

What good DevOps looks like, from my perspective.
How I want useful information shared across the company.
Where I want to stay in the loop vs. delegate fully.
My own engineering judgment, encoded as guardrails.

A lot of that can’t be captured by off-the-shelf AI tooling. But it can be shaped into workflows.

Here’s what a pAI-powered week might look like for me:

When I get pinged in a PR:

My agent reviews the changes using my personal heuristics.
It sends me a Slack message with a breakdown of what changed, why it might matter, and asks a few clarifying questions.
If it looks good, I approve it through the bot. If not, maybe it already checked out the branch locally so I can dig in quickly.

When AWS emails me about a service deprecation:

My inbox agent picks it up, researches the change, and scans our accounts to see if we’re affected.
It drafts a proposal about what we need to change, potential impacts, and next steps.
I review it, answer a few clarifying questions, make edits, and it posts to the org channel for feedback.

When a Terraform plan is generated:

The agent reviews the diff using your IaC principles and internal standards.
It flags risky changes (e.g. data loss, replacement of critical infra).
Suggests safer alternatives (e.g. create_before_destroy, module refactoring).
Sends a Slack summary and asks: “Deploy as-is or make adjustments?”
Optionally, generates a more human-readable changelog for stakeholder visibility.

On a schedule or based on alert volume:

Pulls in Datadog alerts, logs, and dashboards.
Summarizes recent incidents, top alerts by frequency or severity.
Identifies alert noise vs. signal and suggests alert tuning or threshold changes.
Proposes observability gaps (e.g. services with no SLOs, dashboards with zero views).
Posts a weekly Slack digest or opens Jira tickets for high-priority cleanup.

These aren’t toys. They’re functional agents that embody how I work — my standards, communication style, and priorities. I stay in control, but I don’t have to do everything manually anymore.

This is where GitHub Actions comes in.

It turns out, GitHub Actions is a fantastic platform for this kind of work:

It’s event-driven, so I can trigger workflows when a PR opens, a file changes, or even on a schedule.
It’s natively embedded in my codebase, so the agent has access to real context.
It’s secure and auditable, with built-in permissions, secrets, and logs.
It works naturally with CLI tools, APIs, Slack bots, LLMs — you name it.
And most importantly: it’s familiar. As a DevOps engineer, I already think in terms of pipelines, triggers, and YAML. This fits.

GitHub Actions becomes the runtime for my AI team. Each workflow becomes a lightweight agent. Each agent becomes a multiplier of my judgment, not a replacement for it.

This is one of the biggest mindset shifts I see coming:

In the future, automation won’t just be owned by the organization. It will become the responsibility of each individual to own the automations that support their work.

That doesn’t mean we give up shared infrastructure or org-wide tools. But it does mean individuals will:

Build and maintain their own personal agents
Define what good automation looks like for their scope
Continuously evolve how they work, with AI in the loop

It’s no longer just about adopting tools. It’s about taking ownership of your AI-enabled workflow as part of your role.

This shift in ownership changes what we look for in teammates, too.

It’s not just:

Can you write clean Terraform?
Can you debug incidents quickly?

It’s:

What have you automated in your own role?
How do you delegate effectively to AI?
What’s in your personal pAI toolkit, and how has it improved your work?

Hiring someone increasingly means bringing in not just a person, but the system of agents and workflows they’ve developed to support them.

That’s a competitive edge — not just for individuals, but for teams.

Right now, I’m still in the early stages — mapping out workflows, writing scaffolding, testing how it all fits together. But I’m convinced that this isn’t a side project. This is the beginning of a new layer in how we work.

I’d love to hear from others exploring the same thing: