AutoMagicOps

How to plan an infrastructure task without losing your mind: a breakdown using an AWS deployment as an example

Sergey Byvshev — Mon, 09 Nov 2026 07:05:53 GMT

The ticket fits on one line: "deploy a new web service to AWS and add jobs to deploy it." Inside that line are a network, containers, a database, secrets, a CDN, two workflows and dozens of small steps that an engineer usually keeps in their head. That works while nothing interrupts you. Then you join a call, come back, and can't remember whether you checked the security group. And when someone asks how long it will take, the honest answer is "a day or two."

I've been building IT infrastructure for about 15 years, and today I lead a DevOps team at a game studio. Tasks like "spin up a new service" or "change system X" land on my desk every week, and over the years I've settled into a fairly stable way of planning them. I tried to write that method down and then give it to an agent.

Part 1. How an engineer plans a task

The task

Let's take a concrete one:

Deploy a new web service to AWS. It has a React frontend and a Python backend, and requires PostgreSQL to run. The application repository is demo-app. This should result in jobs in GitHub for deploying the infrastructure and the application.

Nothing unusual. Tasks like this come in all the time, and anyone who works with infrastructure has a rough idea of what's behind them. Let's walk through what happens in an engineer's head when this ticket arrives, step by step and slower than it happens in real life.

Step 1. Collect context

Before planning anything, the engineer answers three questions:

What is the project? Who uses it, how critical it is, whether it has environments besides production.
How does the current infrastructure work? Which AWS accounts exist, where the Terraform state lives, how the networks are laid out, what CI/CD is already there.
What do we know about the products in the task? Here that's AWS, PostgreSQL and GitHub Actions: which AWS services fit, which Postgres version to use, how Actions will reach the cloud.

Some of the answers are already in their head. The rest they pull from git and the wiki: usually details of how the infrastructure is built and the company's internal rules for cloud, databases and CI/CD.

This step already shows the first problem, and we'll come back to it: a large part of the context isn't written down anywhere except in one person's head.

Step 2. Outline the stages

Once the context is collected, the task falls apart into large stages:

Write infrastructure code for the AWS resources.
Write the build and deploy workflows.
Create the resources in AWS.
Deploy the application.
Check that everything works.

The stages depend on each other: you can't deploy the app before the cluster exists, and you can't create the cluster before the code exists. The dependencies matter more than the list itself, because they decide what can run in parallel and what can't.

Step 3. Break the stages into basic actions

Each stage is a set of simple actions you can do in one go:

edit a file;
run a CLI command;
make an API call;
change a setting in a UI.

For example, "create the resources in AWS" becomes a chain: create a bucket for the state, give GitHub Actions access to the account, run terraform plan, read the diff, run terraform apply, look at the outputs.

Step 4. Lean on rules and experience

To put the actions in the right order, the engineer relies on two things:

Team rules. How we name resources, where we keep state, which tags are required, what we never do in production.
Their own experience. They've done something similar before and remember where it hurt last time.

Step 5. Build the plan: action, check, rollback

These pieces add up to a detailed plan. Usually it lives in the engineer's head, less often on paper. A good plan has three parts:

actions: what exactly we do;
checks before closing each stage: how to know the stage is really done, and not just "seems fine";
a rollback plan in case something goes wrong.

Action	Check	Rollback
`terraform plan` for the network and database	the diff only creates resources, not a single `destroy`	not needed, nothing has changed
`terraform apply`	the outputs are there, RDS is `available`, the ALB responds	`terraform destroy` the new resources (mind the deletion protection on the database)
run the deploy workflow	the job is green, the smoke test passes, the site opens	roll the ECS service back to the previous task definition revision

The Rollback column is the one people leave empty most often. Be honest: when did you last write a rollback plan before you needed it?

Step 6. Execute

Then the engineer walks the whole list: action, check, action, check. If a check fails, they roll back or fix the problem, and check again.

Tedious, right?

Where this process breaks

On paper it's a good process. In practice it breaks in three places.

1. The action list lives in your head, and items fall out of it. A call, an alert, a colleague asking you to look at their PR. An hour later you come back to the task and you're no longer sure whether you closed the database port to the internet. A plan in your head doesn't survive context switches, and you can't hand it to a colleague if you get sick in the middle of the task.

This happened to me when I was moving asset buckets from one cloud to another. I copied the data and set up access, but forgot to add CORS. It's a couple of lines of config, and it feels so obvious that it never makes it onto any list.

2. Checks get skipped. You want to save time: "the site opened, so it works." The fact that the database is reachable from the internet, or that backups aren't set up, comes up a month later. Checks are the first thing to go under a deadline, because skipping them doesn't break anything right away.

3. Nobody knows how big the task is. Ask "how long will it take?" and you hear "a day or two." That's not an estimate. Until the task is broken into actions, its size is invisible: to you, to your team lead, and to whoever filed the ticket.

All three have the same cause: the plan exists only in the head of the person doing the work, so you can't hand it over and you can't measure it.

What if an agent builds the plan?

So here's the natural question: what if an agent does the breakdown, the planning, the execution and the checks? The engineer still controls the stages, decides which steps to run, and accepts the final result.

That's why I built nib (Neuro Infrastructure Builder). It's a tool for infrastructure work: it splits a task into stages, writes concrete actions with checks for each stage, builds a rollback plan, and then either runs the steps itself or gives the operator detailed instructions.

Inside, nib follows the same logic as the engineer from Part 1. The work is split into modes, and each mode has its own role:

Mode	What it does	In the engineer's head
Decompose	asks clarifying questions, finds the stages and the dependencies between them	steps 1–2
Plan	one agent per stage writes actions and checks, all in parallel; a separate agent builds the rollback	steps 3–5
Execute	runs a specific action through the connected tools	step 6

The context, rules and experience the engineer relies on exist in nib too: a knowledge base, rules and skills. In this post we only use the knowledge base. The rest is a topic for the next part.

Part 2. From git clone to a working site

Now let's run the same task through nib. The whole run is on video:

What you need

Docker;
an API key for an LLM provider. nib works with any OpenAI-compatible API, and the installer has presets for OpenAI, OpenRouter, Google Gemini, Qwen, DeepSeek, Grok and Kimi;
an AWS account. I strongly recommend a separate sandbox account: the agent will need keys that can create resources;
a GitHub account and a fork of demo-app, if you want to repeat this exact task.

Installation

nib runs locally with Docker Compose or in Kubernetes with a Helm chart. The local option is enough to try it:

git clone https://github.com/javdet/nib.git
cd nib
make setup

make setup is an interactive script. It asks for the LLM provider, the model and the key (I use OpenRouter), then the name of your first project and, optionally, its environments, clouds and regions. You can skip those fields, but nib plans better with them, and you can add more projects later. Then the script generates tokens, writes .env and the config, and starts four containers: Postgres, the knowledge base server, the backend and the frontend.

At the end it prints the UI address (http://localhost:8080 by default; if the port is busy, it picks a free one) and an API token. You paste this token on the login screen. It's also saved in .env as NIB_API_TOKEN, so it's hard to lose.

Knowledge base: what to fill in for a new project

The first place to open after you log in is Knowledgebase. This is the "context" from step 1: everything the engineer knows about the company and the project, and the agent doesn't.

The Company Information card has the basic fields: company name and description, version control system and git base URL, git user, CI/CD system, issue tracker, wiki and team messenger. For our task the key ones are GitHub as the VCS and GitHub Actions as CI/CD, because they decide which workflows the agent will write.

You don't need to upload documents for a new project yet: there's nothing to describe. On a live project, this is where you put what usually sits in the wiki and in people's heads: the network diagram, naming conventions, where state lives, what's special about each environment. You can upload a Markdown document or ask the agent to generate one from a list of repositories.

When a plan finishes, nib writes a report and updates the knowledge base from it, so the next task starts with what the agent learned in the previous one.

Connecting GitHub, AWS and search over MCP

On its own, the agent can only think. To create a repository, look at AWS resources or find documentation, it needs tools. In nib they connect over MCP (Model Context Protocol). It's an open protocol: an LLM application gets a list of tools from an external server and calls them. One MCP server covers one system: GitHub, AWS, search.

If you don't know where to start, ask nib itself, for example: "How do I connect you to AWS over MCP?" Its answer is in the video.

This task needs three servers:

GitHub: the repository, PRs and workflows;
AWS: reading and creating resources in the account;
SearXNG: web search, so the agent can check current documentation instead of relying only on what the model already knows.

nib supports only the HTTP transport for MCP (streamable HTTP), so we run all three servers as containers on the same network as nib. Add them to docker-compose.yml.

GitHub MCP is the official server from GitHub:

docker-compose.yml

Hey Agent, Fix My Build": Building a First-Line Support Desk on n8n. Part 3

Sergey Byvshev — Wed, 19 Aug 2026 01:23:55 GMT

We're one step away from shipping a new version of our game. The number of changes across services and infrastructure has multiplied, and everyone is racing the deadline. The alert channels are a solid wall of red, and in the support channel everybody urgently wants to know why the build broke — and, naturally, to have it fixed right now.

Diagnosis is already handled by the agent from Part 1 and Part 2 — but that's only half the job. The tedious part starts after: the engineer has to work out where exactly the change belongs, judge whether they can make it themselves or need a developer, find the right repository among dozens of similar ones, apply the fix, push it through a PR and a review. During a release crunch those "just fifteen more minutes" per request add up to hours, and the context switching finishes off whatever concentration is left.

Sound familiar? Here's what it looked like for us: the agent produces a diagnosis in two minutes — "the workflow isn't passing the environment input" — and then the engineer spends another half hour figuring out which of the reusable workflows to fix it in.

That's why we decided to go further and make it possible to simply say:

Hey agent, fix my build.

In this part I'll cover how we:

taught the system to distinguish two phases of a request — analysis and execution — and extended the classifier with execute categories;
added Postgres as state storage: every thread now has its own small state machine;
moved to Agentgateway for MCP server access, with JWT authentication and per-tool authorization;
chose how to run coding agents in Kubernetes;
built two executor workflows — for CI/CD and for incidents — plus a callback that returns the agent's result back into the thread.

All workflows and system prompts are published separately — link at the end of the article.

Agent request example

Building an AI First-Line for DevOps Support on n8n for $250/Month - Part 2

Sergey Byvshev — Fri, 14 Aug 2026 13:51:42 GMT

In Part 1, I walked through how chat requests in Slack land in n8n, get classified by category, and are routed into the right processing branch. Under the hood of the classifier sits an LLM with access to Slack over MCP — it reads the thread context and decides what the new request is about. Around it run a few helper sub-workflows:

attachmentsAnalyzer — parses screenshots and text logs;
httpProbeTool — performs endpoint availability checks correctly, without taking the agent chain down with it;
errorReporter — covers us when the workflow itself fails so the requester isn't left in the dark.

Using the CI/CD assistant as an example, I showed how those building blocks compose into a processing branch. Today — the three remaining branches. Each handles a different class of requests, but architecturally they follow the same template. Thanks to that, adding a new branch takes a couple of hours rather than reinventing the wheel from scratch.

In this part:

Incident investigator — the most temperamental category, with the lowest rate of fully autonomous resolution and the most interesting edge cases;
Task manager — handling infrastructure modification requests with automatic ticket creation in Jira;
Infrastructure knowledge assistant — answers to "where is X configured?" with a small trick involving auto-generated READMEs in IaC repos.

All workflows and system prompts are published separately — link at the end.

Incident Investigator

This is probably the most "temperamental" branch of them all. The incident category catches pretty much anything that means "something just broke": a hung Postgres, 502s on the ingress controller, sudden OOMs in some consumer, mysterious "all my requests are slow but my neighbor's are fine." The spectrum is huge, there's no universal recipe — so the rate of fully autonomous resolution here is the lowest across all branches.

But even when the automation doesn't close the problem end-to-end, the dossier it puts together saves the on-call engineer 10–15 minutes at the start: firing alerts are already pulled, metrics and logs are already eyeballed, hypotheses are already framed. When you get dragged into an on-call rotation on a Saturday morning, those 10 minutes are sometimes the difference between "I had time to wake up" and "I'm already answering in chat with coffee in one hand."

Input data

The sub-workflow expects the same input structure as the CI/CD assistant from Part 1. To save you from jumping between articles — a short description of the fields:

{
  "message": "Chat request text",
  "post_id": "Message ID — needed to reply into that exact thread",
  "channel_id": "Slack channel ID",
  "channel_name": "Channel name, passed into the prompt for context",
  "user_name": "Author of the request, mentioned in the final reply",
  "user_id": "User ID",
  "file_ids": ["Attachment IDs, if any"],
  "category": "incident",
  "confidence": 0.95,
  "summary": "Short summary from the classifier",
  "is_thread": true,
  "thread_root_id": "ID of the thread's root message",
  "on_call_user": "On-call engineer name — comes in handy for escalation"
}

First, attachmentsAnalyzer2 runs — the same sub-workflow familiar from Part 1 that parses screenshots and logs. Triggering it only requires passing file_ids. If there are no attachments, the empty-attachments branch goes through a Merge node, and the pipeline doesn't crash on missing data.

Collecting variables in SetVars

Next, the SetVars node assembles everything that'll be needed both in the agent's system prompt and when posting the reply back to Slack. This part is worth pausing on, because these variables effectively parameterize the system prompt without forcing you to edit it by hand:

K8S_CLUSTERS — list of available contexts (we have two: dev and prod, both in DigitalOcean Frankfurt);
K8S_NAMESPACE — the main namespace with production workload;
GITHUB_ORG — GitHub organization name, so the agent doesn't try to search code across the entire internet;
prometheus_uid and loki_uid — Grafana datasource UIDs; without them, the agent has no idea where to knock for metrics and logs;
reply_root_id — ID of the message the agent will reply into (either the thread's root post or the original request post itself).

These values then get substituted into the system prompt via {{ $('SetVars').first().json.* }}. When a new cluster comes up or the namespace changes, you just edit values in a single node — instead of crawling through the big block of prompt text.

Querying the agent

The user prompt is built with the same template as the CI/CD assistant:

Investigate incident from {{ $json.user_name }}
in channel {{ $json.channel_name }}{{ $json.is_thread ? ' (message in thread, thread_ts=' + $json.thread_root_id + ' — read the history through Slack conversations.replies first)' : '' }}

{{ $json.message }}{{ $json.attachments_context && $json.attachments_context.trim().length > 0 ? '\n\nAdditional information from attachments:\n' + $json.attachments_context : '' }}

Three blocks inside it: the original message, an explicit instruction to read the thread history (if the request came from a thread), and context from attachments if any were present.

I use GPT-5.5 from OpenAI as the model. On this task, Sonnet and Gemini show comparable quality — the choice is more out of habit. What actually moves the needle isn't the model but the completeness of the system prompt and the toolset.

Tools the agent has access to

For the agent to make sense of an incident, it has to see the infrastructure through an engineer's eyes. When our on-call goes through a breakdown, the usual path is: "what do the alerts say → what's in the service logs → what's in the metrics → what releases went out → what's in the IaC." A corresponding MCP tool is wired up for each step:

Kubernetes MCP — look at pods, events, read container logs. The system prompt explicitly says: don't call pods_log for the same pod more than twice. Without that constraint, the agent loves to loop trying to "double-check just one more time."
Grafana MCP — queries into Prometheus (query_prometheus) and Loki (query_loki_logs). Same tool also covers dashboard search, in case the agent wants to drop a link to a ready-made panel into the reply.
DigitalOcean MCP — needed when the incident touches the infra layer: App Platform, droplets, the DOKS cluster, load balancers.
GitHub MCP — look at the latest commits, Actions runs, open PRs. Especially useful for the "everything broke right after deploy" scenario — and these scenarios, like for everyone else, aren't rare.
Slack MCP — read-only. Mostly used for conversations.replies at the very start of the investigation. We don't trust the agent with sending the reply itself — that's done by a separate node after the output is received. If something goes wrong at the posting step, the thread just stays without a final reply, but the execution doesn't crash.
Qdrant Vector Store — knowledge base on our infrastructure: component descriptions, service relationships, naming conventions, useful labels. Used when the agent runs into the name of an unfamiliar service and wants to figure out where it lives and what it talks to.

And as a separate line item — prometheusAlertSearch. This is a custom sub-workflow that the agent reaches for almost always within the first 2–3 steps of an investigation. It's worth describing in more detail.

Alert tool: prometheusAlertSearch

The idea is simple: the lion's share of complaints from developers essentially mirror an alert that's already firing in Prometheus. "Postgres is kinda slow" usually arrives at the exact moment when PostgresHighLatency has already been firing for ten minutes. It's logical to first check whether the cause is sitting right on the surface — and only then go digging through logs.

The sub-workflow accepts keywords and a match mode:

{
  "keywords": ["postgres", "pgbouncer"],
  "match_mode": "any"
}

Inside, it queries Prometheus's /api/v1/alerts and, among the firing alerts, picks the ones where the keywords appear in the name, labels, or annotations. match_mode: "any" (default) is an OR across the keywords; "all" is AND.

It connects to the agent through the toolWorkflow node as a regular MCP-tool. The description for the agent is critically important — without it, the agent doesn't understand when and how to use this tool:

Search currently firing alerts in Prometheus by keywords. Use early in investigation to find correlated active alerts across the platform.

Input:

keywords (array of strings, required): lowercase substrings matched against alert names, all label keys/values, and all annotation values. Examples: ["postgres"], ["http","5xx"], ["kafka","redpanda"].
match_mode (string, optional): "any" (default, OR) or "all" (AND).

Returns: { ok, total_firing, matched_count, returned_count, truncated, alerts:[...] } Each alert has alertname, severity, labels, summary, description, activeAt, value. Output capped at 25 alerts — if truncated=true, refine keywords.

Without an explicit "call this in the first 2–3 steps," the agent likes to first wander into logs, then into cluster events, then somewhere else — and only at the end remember about alerts. A hard hint in the tool description visibly changes the behavior.

Response format

The system prompt defines a strict output format:

What happened

Short description of the incident

Timeline of events

Events from 10 minutes before the problem appeared

Likely causes

At most two hypotheses

What to try

Step-by-step actions for each hypothesis

The structure mirrors the familiar incident-review format — easy to lift into a postmortem if the incident turns out to be significant, without rewriting. Average processing time per request and token consumption: roughly under 2 minutes end-to-end and 40–50K tokens depending on how deep the agent has to go. Cost-wise — peanuts compared to engineer time, especially considering that some of these requests used to require a call rather than just a chat exchange.

Task Manager

The "infrastructure modification" category covers requests like "roll us out a new service," "give us access to Grafana," "add a bucket for analytics." Full automation here is off the table: nearly every such request needs approval, estimation, and just plain human attention. But what definitely can be automated is turning free-form text into a properly formatted ticket.

The previous typical scenario looked like this: a developer writes in chat, the on-call reads it, asks clarifying questions, and writes all of it into Jira in their own words. Now Jira gets the request straight away — and the on-call gets a notification with a ready-made link.

The input is the same structure with fields from the classifier. Then — the familiar sequence: attachment parsing through attachmentsAnalyzer2, variable collection in SetVars, handoff to the LLM agent.

Output format

The distinctive part here is the strictly defined response structure. The agent must return JSON:

{
  "summary": ": ",
  "description": "<1-3 sentences with details>",
  "label": ""
}

label is picked from a constrained dictionary: kubernetes, monitoring, network, access, database, ci-cd, and so on. This simplifies further task routing by engineer competence and gathering analytics on "who's working on what and how much of it."

For the agent to write decent summary and description, it has access to:

Qdrant Vector Store — to see how the area the request belongs to is generally structured at our place. This is needed so the agent doesn't invent a new name where an existing one already exists.
Slack MCP — if the request came in a thread, read the backstory. People often clarify details exactly in the thread, while the first message is a single line.
HTTP Request — in case the request contains a link to someone's PR, a Confluence doc, or an external spec.

Validation and task creation

After receiving the JSON, validation runs: we check for required fields and a permitted label value. If something's off — a fallback message goes out ("couldn't formulate the task automatically, please take a look"), and the on-call handles it manually. If everything's fine — the task is filed in Jira through n8n's built-in node. A short message comes back to Slack with the task title and a link to it. The on-call then sees a ready ticket with the right label and decides: take it on, reassign, or ask for clarifications.

An important point: automatic task creation doesn't cancel manual validation. Sometimes the classifier gets it wrong and reads an incident as a modification (especially when the author writes in the "we need X to work" style instead of "X is not working"). That's why the system prompt explicitly carries a rule: if it's unclear from the text whether new work is actually needed or whether this is about something existing — ask "could you clarify what exactly needs to be done?" as a separate message, and don't create the task. A cheap measure that noticeably cuts down on junk tickets.

Infrastructure Knowledge Assistant

The last workflow for today is the "calmest" one. The question category catches requests like "where is the connection limit configured in pgbouncer?", "where do alloy logs from droplets go?", "what region is the assets-prod bucket in?". Sometimes from new joiners on the team, sometimes from the same DevOps engineers who forgot where what lives. (It happens, I won't lie.)

The structure is almost identical to the incident investigator: the same input JSON structure, the same chain with attachment parsing, the same SetVars. Toolset: GitHub MCP, Slack MCP, Kubernetes MCP, Grafana MCP, DigitalOcean MCP, Qdrant Vector Store, and HTTP Request for pulling official component documentation when the required parameter isn't in the code and you have to look up vendor defaults.

I won't dwell on the same nodes — let me tell you about one trick without which the agent would hit a wall pretty quickly.

A skill that writes READMEs in IaC repositories

The initial hypothesis was: give the agent GitHub MCP and a knowledge base in Qdrant — and it'll figure it out. In practice, it turned out that the structure in IaC repositories is almost always non-obvious: somewhere Terragrunt is mixed with Helmfile, somewhere Ansible playbooks live with inventories two subdirectories deep, somewhere Terraform modules are laid out under names that only make sense to us. The agent burned a ton of tokens and time just to figure out where to look in the first place.

The solution came from the Claude Code Skills format: I wrote a separate skill that runs locally in the IDE and generates/updates the README in every infrastructure repo. The skill reads the directory structure, identifies entry points, and describes them in a unified format. The output looks like this:

# infra

Main IaC repository: terragrunt code for cloud resources,
Ansible inventories and playbooks for VMs, Helm releases and
manifests for k8s.

## Directory structure

- `terraform/` — terragrunt code, organized by cloud and region:
  - `do/fra1/` — DigitalOcean Frankfurt resources (DOKS clusters,
    buckets, load balancers, droplets for DBs).
  - `yc/ru-central1/` — Yandex Cloud resources.
- `ansible/` — playbooks and inventories for Droplet management:
  - `playbooks/` — entry points (`postgres.yml`, `redpanda.yml`, ...).
  - `inventories/{stage,prod}/` — per-environment inventories with
    `group_vars/` next to them.
- `helm/` — Helmfile releases of infrastructure components in k8s
  (ingress-nginx, cert-manager, kube-prometheus-stack, etc.).
- `manifests//` — manifests applied on top of Helm releases:
  alerts, ServiceMonitors, standalone CRDs.

## Naming conventions

- VM: `---[]-.example.com`
- clusters: `--01` (e.g. `prod-fra1-01`)
- buckets: `s3---` (e.g. `s3-project-assets-prod`)

From the agent's perspective, this changes everything: the first thing it does is read README.md through get_file_contents, understand the structure, and then go into the right subdirectory for a specific file. The number of GitHub MCP calls dropped roughly 3×, and answer quality went up noticeably — especially on questions of the "where is X configured" type.

I'll publish the skill itself in the repo — it's simple and easy to adapt to someone else's structure.

What we got in total

After all three branches rolled into production and lived through a couple of months of real traffic:

Incident investigator — closes about a quarter of requests fully; in the rest, the on-call gets a ready-made breakdown with hypotheses and saves 10–15 minutes at the start.
Task manager — practically every modification request makes it into Jira with a meaningful summary and the right label set; manual fixes are needed rarely, usually around the description wording.
Knowledge assistant — closes roughly half of the questions without an engineer; for the rest, the agent's answer is still useful as a starting point for the on-call.
Combined cost at our flow stays around $250/month on LLM spend. Considering the system works 24/7 and doesn't take vacations — laughably small money.

What hasn't worked out yet

To avoid creating the illusion that everything's smooth — a few rough edges we're still living with:

Objective quality metrics — for now, the only feedback channel is occasional comments along the lines of "no, the agent guessed wrong here." I want to wire up more structured feedback — for example, through emoji reactions in Slack with automatic stats collection.
Long incident threads — the agent reliably gets lost when a thread already has 30+ messages. Right now, I cap the context depth hard in the prompt, but it's a tradeoff: sometimes important context from the start gets dropped.
The "security" category — it doesn't exist in the classifier, but requests like "does this comply with GDPR?" come in periodically. For now, I shove them into question, but answer quality there is shaky.

Plans for the future

What's in the queue for the coming months:

Expand the agent toolset to "actions, not just reads" — carefully give access to restarting pods, applying pre-vetted manifests, restarting systemd services. Obviously, this is minefield territory, so it'll be done through explicit engineer confirmation in Slack — without confirmation, no changes get applied.
Add handling for maintenance announcements — for now, such messages just get tagged and ignored, but they could be pushed into a separate digest channel with an automatic "what's planned for this week" summary.
Wire up a dedicated branch for security questions — with its own knowledge base on our compliance docs and security policy.
Add analytics over processed requests — which categories are growing, where the autonomous resolution rate is what, how many tokens go to which category. Without numbers, it's hard to understand what should actually be improved first.

Wrap-up

In short: AI agents driven by n8n with MCP tools turned out to be a very workable way to offload a significant chunk of routine work from the on-call engineer. Not a silver bullet — but something close to a modest, hardworking intern who works around the clock and costs about as much as a couple of lunches.

The key is not to try automating everything at once. Better to ship one branch, live closely with it, understand its weak spots — and only then extend the approach to the other categories. From my first working CI/CD assistant to the full set of all branches took about three months — and I have no regrets about that pacing.

Link to the repo with workflows: https://github.com/javdet/automagicops-workflows Which category of requests automates best in your setup? And have you ever had the situation where an AI agent confidently nailed the wrong diagnosis and led the engineer down the wrong path? Share in the comments — especially curious to compare where everyone’s stepping on rakes.

Building an AI First-Line for DevOps Support on n8n for $250/Month — Part 1

Sergey Byvshev — Fri, 14 Aug 2026 13:22:46 GMT

How a small DevOps team offloaded chat triage, CI/CD diagnostics, and attachment parsing to an AI agent — and what's still rough about it.

If you, like me, run infrastructure for a small team, you've probably been in this spot: the engineering org keeps growing while the DevOps headcount stays the same. With the rise of vibe-coding, that imbalance became especially obvious — our dev team at the studio grew roughly 1.5× in a couple of months, because every product manager wanted their own mini-application. On top of that, we got an extra headache from increasingly frequent availability issues from certain regions.

As a result, the flow of messages in our Slack support channel grew to the point where a significant chunk of an engineer's day was spent triaging them. And the most frustrating part: not every request actually fell under DevOps responsibility, but each one still required at least a shallow diagnostic to figure that out.

That's how the idea to offload the first line to an AI agent came up. By that point, we'd already automated incident analysis triggered by alerts (covered in a previous article), and the approach had proven itself. Extending the same pattern to manual chat requests was the logical next step.

In this article — the first of two — I'll walk through how we:

classified the past year's request flow and picked categories worth automating;
built a classifier in n8n with Slack integration over MCP;
implemented a CI/CD incident assistant as the first production-ready branch;
added attachment parsing (error screenshots, log files);
set up proper error reporting for the workflows themselves.

Part two will cover the remaining branches: the infrastructure incident assistant, the knowledge assistant for routine questions, and the handler for infrastructure modification tasks.

All workflows and system prompts are published separately — link at the end of the article.

Preparation: classifying requests

Before automating anything, you need to understand what. I exported the request history from our Slack channels for the past year and bucketed it into categories. The result:

Infrastructure modification — changes to existing infrastructure, adding standard resources.
New installation — deploying new systems and integrations that didn't exist before.
Incident — something stopped working in the current infrastructure.
CI/CD — failing builds, broken tests, broken deploys.
Question — general questions about our infrastructure.
Announcement — informational messages: planned maintenance, for example.
Other — anything that didn't fit above.

The bulk of requests fell into categories 3–5 — those were the obvious starting point. Categories 1–2 require approvals and almost always need an engineer in the loop, so there's no point automating them. Announcements don't need agent handling at all — it's enough to recognize them correctly and not page the on-call.

But before building any handling branches, we needed to reliably identify which category a new request belongs to.

The classifier

At first glance, the setup looked straightforward: create a Slack app with a bot user, subscribe to app_mention events, point them at an n8n webhook, run the payload through an LLM, get the category.

The first nuance surfaced quickly: an incoming message can either start a new thread or be a reply inside an existing one. In the second case, without thread context the classifier will misfire — a one-liner like "same problem on my end" makes no sense in isolation.

Instead of calling the Slack API directly from n8n, I offloaded this to the agent — we already have slack-mcp, which can read messages from channels and threads. The agent itself decides whether to pull the thread history and does so when the context calls for it. The system prompt needs to describe how to do this, plus a few other things:

category descriptions with examples;
the expected output format:

{
  "category": "",
  "confidence": <0.0-1.0>,
  "summary": "",
  "acknowledge": "",
  "is_thread": ,
  "parent_thread_ts": ""
}

In the user prompt, I additionally pass channel_id, channel_name, message_ts, and user_name — this helps the classifier orient itself in the message.

For the model I use Sonnet or GPT-5 Codex — on classification, both show comparable quality.

At this stage I don't yet touch attachments — screenshots and log files come into play further down, inside the logic of specific branches.

Once the agent's response is received and its fields are validated, we need to determine the on-call engineer — they may be needed if automated handling can't close the request. On-call rotations live in Google Calendar, so I had to configure OAuth2 access to it following the n8n docs.

After the category and on-call are determined, the corresponding sub-workflow kicks off. In parallel, an acknowledge message goes to Slack so the author can see the request was received and is being worked on. That's an important detail — without it, the person keeps typing "hey, is anyone looking at this?" into the thread, which defeats the whole point.

CI/CD assistant

CI/CD is one of the most common categories, so that's where I started. A solid share of these issues can be resolved without an engineer: builds that fell over because of a temporarily unreachable repository, flaky tests, misconfigured pipelines, expired tokens.

The sub-workflow expects an input structure with the request data:

{
  "message": "Chat request text",
  "message_ts": "Slack message timestamp",
  "channel_id": "Slack channel ID",
  "channel_name": "Slack channel name",
  "user_name": "Sender's display name",
  "user_id": "Sender's Slack user ID",
  "file_ids": ["List of attachment IDs"],
  "category": "One of the categories",
  "confidence": "Confidence score",
  "summary": "Short request description",
  "is_thread": "Whether the message came from inside a thread",
  "thread_ts": "Parent message timestamp, if this is a thread reply",
  "on_call_user": "On-call engineer's name"
}

Parsing attachments

Most CI requests arrive in the format "build failed" + an error screenshot. That description clearly isn't enough to identify a specific build, so before the main agent runs, a helper sub-workflow — attachmentsAnalyzer — kicks off first.

It processes attached files:

Images (error screenshots) — sent to gpt-4o-mini to extract text and describe context.
Text files (logs) — if the size doesn't exceed the limit set in the Config node, the content is passed along as extra context.

The output is a compact text block:

{
  "attachments_context": "...human-readable block...",
  "attachments_count": 1
}

I deliberately split this out into its own workflow — it's reused in other handling branches. If attachmentsAnalyzer fails, the main workflow keeps going without the extra context instead of falling over entirely.

Gathering context and calling the agent

Before forming the LLM request, the SetVars node assembles everything needed:

the raw request data;
the output of attachmentsAnalyzer;
auxiliary context for the system prompt: GitHub organization names, Kubernetes contexts and namespaces, Grafana data source names.

The agent itself works with a set of MCP tools:

GitHub MCP — access to Actions build logs, PRs, source code.
Slack MCP — reading messages in a thread when the initial request doesn't carry enough context.
Grafana / Kubernetes MCP — looking up cluster logs and events on deploy-related issues.

The system prompt should cover:

which teams exist and which repository groups belong to them — speeds up identifying the right repo;
how to pull additional context from a Slack thread;
the DevOps team's scope of responsibility — if an error falls within it, the assistant additionally tags the on-call at the end of the investigation;
a general description of the available tools and when to use each;
a few worked examples;
the output format.

The user prompt is templated like this:

Investigate the issue from {{ $json.user_name }} in channel {{ $json.channel_name }}{{ $json.is_thread ? ' (message is in a thread, thread_ts=' + $json.thread_ts + ' — first read the history via Slack conversations.replies)' : '' }}
{{ $json.message }}{{ $json.attachments_context && $json.attachments_context.trim().length > 0 ? '\n\nAdditional information from attachments:\n' + $json.attachments_context : '' }}

Alongside the message itself, this passes who sent it and which channel it came from, whether it's a thread reply, and any attachments if present.

The HTTP-probe workaround

One of the common reasons builds fail is an unreachable external resource: a dependency repository, a proxy, a registry. The natural move would be to give the agent a built-in HTTP Request tool and let it check availability. In practice, that didn't work — the built-in n8n node doesn't handle timeouts and network errors gracefully, and on a failure it brings down the whole agent chain.

So I wrapped the check in a separate sub-workflow httpProbeTool that always returns a structured result: success, failure with a reason, or timeout. The agent uses it like any other tool.

Once the agent responds, there's a short format validation step, and the message gets posted into the Slack thread.

Handling workflow errors

When you build a system that handles real user requests, reliability is critical. If a workflow falls over for any reason — LLM quota exhausted, MCP server unreachable, invalid JSON — nobody in chat will know, and the request just hangs there.

This is especially relevant in the first weeks after launch, when you're constantly tweaking things.

The solution is simple: a dedicated workflow specified in the main workflows' settings as the Error Workflow.

What it does:

Pulls information about the failed execution from the n8n API (you'll need to generate an API key for this).
Through the Extract Thread Context node, determines channel_id and thread_ts of the original message.
Posts a short error message directly into the request's thread, so the author isn't left in the dark.

A more verbose error report also goes into the DevOps team's internal channel — this lets us react quickly to regressions.

What we got

After a couple of months running in production, the picture looks like this:

Average response time — up to 3 minutes from the moment a message appears in the channel.
~25% of requests are fully closed without an engineer.
~40% of requests are resolved faster than usual — the agent does a preliminary diagnostic, and the on-call gets ready-made context.
Cost at our volume (several dozen requests per week) — up to $250/month on LLM usage.

Example creation issue by request in Slack

Example CI request resolved without an engineer

Example investigating a build crash based on a screenshot

Compared to an engineer's hourly rate, this looks like a very cost-effective team addition — especially given the agent works around the clock and doesn't pull the on-call away from their main work.

What's still rough

To avoid leaving the impression that everything is smooth, here are the rough edges we still live with:

The agent sometimes gets lost in long threads with dozens of messages — we have to limit context depth in the system prompt explicitly.
The Incident category has the lowest autonomous resolution rate so far — too many non-standard situations. We're working on expanding the MCP toolset.
It's hard to objectively evaluate the quality of answers to "infrastructure questions" — we need a feedback mechanism from engineers (planning Slack reactions as the simplest signal).

Part two will cover the remaining branches: the infrastructure incident assistant, the knowledge assistant with RAG search over our docs, and the handler for modification tasks with automatic ticket creation.

How do you offload first-line support on your team? Are you using off-the-shelf products (like PagerDuty AIOps) or building your own? Which request categories automate best in your environment — share in the comments, I'm curious to compare the distribution.

Repository with workflows and system prompts: https://github.com/javdet/automagicops-workflows