DevOps lead unveils nib: an agent that breaks AWS deployments into stages, checks and rollbacks

“Deploy a new web service on AWS and set up deployment jobs.” One line in the issue tracker. Behind it sit networking, containers, a database, secrets, a CDN, two workflows and dozens of small actions that the engineer keeps in their head. As long as nobody interrupts you, it works. But after a call, you can no longer remember whether you closed the database port, and the only honest answer to “how long will it take?” is “a day or two.”

The author of the walkthrough leads a DevOps team at a game studio and has 15 years of experience. He formalized his planning method and handed it over to an agent called nib (Neuro Infrastructure Builder).

How an experienced engineer plans

First comes context: what the project is, how the existing infrastructure is organized and what is known about the products involved in the task. The task is then divided into major stages: infrastructure code, build and deployment workflows, resource creation, deployment and verification. More important than the list itself are the dependencies between stages, which determine what can run in parallel.

Each stage is broken down into basic actions: edit a file, run a command, make an API call. Every action needs a check and a rollback. For example, after terraform plan, the diff must contain no destroy operations, and after apply, RDS must have the status available. The “Rollback” column is usually left blank. The author asks: when did you last write a rollback plan before you needed it?

The process breaks down in three places. Items slip your mind when you switch contexts: the author once moved asset buckets between clouds and forgot about CORS. Checks get cut as deadlines approach because skipping them does not break anything immediately. And there is no estimate of the work involved: until the task has been broken down, “a day or two” is a feeling, not an estimate.

What nib does

The tool has three modes. Decompose asks clarifying questions and identifies stages and their dependencies. Plan launches an agent for each stage; they work in parallel to detail the actions and checks, while a separate agent builds the rollback plan. Execute carries out an action through connected tools or gives the operator detailed instructions.

A knowledge base supplies the context an engineer would otherwise hold: a company description, VCS, CI/CD, network topology and naming conventions. After completing the plan, nib writes a report and updates the knowledge base, so the next task starts with what the agent learned from the previous one.

Setup is local: git clone, make setup, Docker and an API key from any OpenAI-compatible provider. Tools connect through MCP over HTTP: GitHub, the AWS API and SearXNG for documentation searches. The AWS server exposes just two tools—a CLI invocation tool and a command helper—while GitHub exposes a couple of dozen. To keep the context from ballooning, nib selects only the necessary tool categories during decomposition.

Where things can go wrong

The example uses permissive security settings. READ_OPERATIONS_ONLY: false allows changes, while REQUIRE_MUTATION_CONSENT: false removes confirmation on the MCP server side. The Execute button in nib itself remains the confirmation step. AUTH_TYPE: no-auth is acceptable only because the port is not exposed externally and the service is visible solely within the Docker network.

Secrets live in two places. The aws-mcp container needs the AWS keys, so they go in .env. The GitHub token is passed in a header from nib to the MCP server and stored in nib’s secrets with a host allowlist. GitHub requires a classic token with the repo and workflow scopes; without the latter, the agent cannot commit files to .github/workflows.

The practical takeaway

The main value lies in the discipline itself: an action, a check and a rollback at every step. Even without nib, this table is worth writing before work begins, and an estimate based on the number of actions is more honest than “a day or two.” If you try the tool, use a separate AWS sandbox account and give the agent only the permissions it needs. This installment covers only the knowledge base; the author promises to discuss rules and skills in the next article.