I didn't start this project because I wanted to build another AI agent.
I built it because I broke something.
While working on an MCP project, I made an infrastructure change in Terraform. The change itself looked fine at the time, but after pushing it, I realised I had affected something else that I hadn't considered.
Terraform had actually done its job. It showed me what was changing.
The problem was that I was looking at the change, not everything connected to that change.
That got me thinking.
What I really wanted before merging the PR was something that could tell me:
What could this change break?
Why could it break?
What else depends on the resource I'm changing?
How far could the impact spread?
That became the starting point for what I built.
Looking beyond the Terraform plan
Anyone who works with Terraform is familiar with the plan.
You change the infrastructure, run the plan, review what will be created, updated, replaced or deleted, and then decide whether you're comfortable applying it.
That's useful, but when infrastructure becomes interconnected, reviewing individual changes isn't always enough.
Say I'm changing an IAM policy used by a Lambda function.
Terraform can show me exactly what is changing in that policy.
But what I really care about is what happens afterwards.
Does the Lambda still have access to the resources it needs?
Does another service depend on that Lambda?
Is that function sitting behind an API?
Could removing one permission eventually affect an application workflow?
That's the context I was missing when I broke my original change.
My first thought was to use an LLM
Since I was already thinking about agents, the obvious first idea was to give the Terraform plan to an LLM and ask:
"What is the impact of this change?"
But the more I thought about it, the less I liked that approach.
I didn't want an LLM guessing how infrastructure was connected.
There are things we can determine from the infrastructure itself. Resource changes can be parsed. Dependencies can be mapped. Certain risky changes can be detected using rules.
So I started separating the problem.
Use deterministic logic for the things we can know.
Use AI for the things where reasoning and explanation are useful.
That became one of the main design decisions behind the workflow.
What happens when a PR is raised
The workflow starts with the Terraform plan.
It parses the plan and identifies which resources are being created, modified, replaced or deleted.
From there, it looks at relationships between AWS resources and builds a dependency graph around the resources being changed.
For example, a change might initially look like this:
IAM Policy changed
But once dependencies are considered, the picture could become:
IAM Policy → Lambda → DynamoDB → Application workflow
Now the PR is telling me something much more useful.
It's not just saying that an IAM policy changed.
It's showing me where that change could potentially travel.
Understanding the blast radius
This became one of the most important parts of the project for me.
If I'm changing one AWS resource, I want to know which other resources could potentially be affected.
That's the blast radius.
A security group change might affect an ECS service, which might affect an internal API, which might then affect something consuming that API.
A permission change might affect a Lambda function, which could affect its access to DynamoDB, which could affect an application workflow.
The workflow traverses those relationships so that the PR review isn't limited to the resource directly being changed.
This changes the question from:
"Does this Terraform change look okay?"
to:
"If this changes, what else should I be checking?"
That second question is much closer to what I actually want during an infrastructure review.
Not everything needs AI
Another thing I wanted to avoid was putting AI everywhere just because this is an agentic workflow.
Some infrastructure risks are better handled with straightforward rules.
If a resource is being deleted, that's something we can detect.
If Terraform is replacing a resource, we know that.
If IAM permissions are being removed, we can detect that too.
These checks don't need an LLM.
So the workflow has deterministic risk rules that identify changes worth paying closer attention to.
The AI reasoning comes later.
Where AI actually helps
Once I've collected the Terraform changes, dependencies, risk signals and potential blast radius, that's where I find AI much more useful.
The workflow can use Amazon Bedrock, OpenAI or Anthropic models as the reasoning layer.
Instead of giving the model a raw Terraform configuration and asking it to figure everything out, I can give it structured context about the change.
For example:
IAM permission removed
Affected resource: Lambda
Dependency: DynamoDB
Downstream dependency: application workflow
Now the reasoning layer can help explain why the change matters and what a reviewer might want to verify before approving it.
That explanation is much more useful in a PR than another long Terraform output.
The intention isn't for AI to decide whether an infrastructure change is safe.
It's there to help the engineer reviewing the change understand the potential consequences faster.
Keeping sensitive information out of the reasoning layer
There was another issue I didn't want to ignore.
Terraform plans can contain information that I don't necessarily want to send to an external model.
So before anything reaches the AI reasoning layer, the workflow includes a redaction step to remove or mask sensitive information.
The model should receive enough infrastructure context to reason about the impact without receiving everything from the original Terraform plan.
This was important to me because adding AI to an infrastructure workflow shouldn't mean sending infrastructure information somewhere without thinking about what it contains.
Bringing the result back to the PR
The place where I want all of this information is the same place where I'm already reviewing the infrastructure change.
The pull request.
The output I'm working towards is something along these lines:
Change
IAM permission removed.
Potential blast radius
IAM Policy → Lambda → DynamoDB → Application workflow
Potential impact
The Lambda may lose access to the DynamoDB table. If the application depends on this function, requests through that workflow could fail.
What to check
Confirm the permission is no longer required and validate the affected workflow before merging.
For me, that's much easier to review than trying to mentally connect everything while reading a Terraform plan.
Why I call it an agentic workflow
I didn't want to call something an "agent" just because an LLM is involved.
The interesting part for me is the sequence of work being performed.
The workflow needs to understand the Terraform change, detect risks, discover relationships, traverse dependencies, work out the potential blast radius, prepare the relevant context and then reason about what that could mean.
Different parts of that process require different approaches.
Some are deterministic.
Some involve graph traversal.
Some use rules.
Some benefit from AI reasoning.
It's the combination of those steps that makes the agentic approach interesting to me.
Building it with Kiro
I also used Kiro while building the project.
This was actually another part of the experiment for me.
I wasn't particularly interested in asking AI to just generate an application from a prompt. I wanted to take a problem I'd actually encountered, think through how I wanted to solve it, and then use AI assisted development to help me build and iterate on the solution.
The architecture also changed as I worked through the problem.
The initial temptation was to make the LLM responsible for most of the analysis.
I ended up going in almost the opposite direction.
The more deterministic information I can establish before reaching the reasoning layer, the more useful the reasoning becomes.
That's probably one of the more useful things I've taken away from building this.
Where I want to take it next
This is still evolving.
AWS infrastructure relationships can get complicated very quickly, and there's a big difference between knowing that two resources are technically related and knowing whether a particular change will actually cause an operational impact.
That's an area I want to explore further.
I'd also like to bring more architectural and runtime context into the analysis so the blast radius isn't based only on Terraform relationships.
There are plenty of improvements still to make.
But even at this stage, building it has changed the question I ask when looking at an infrastructure PR.
Terraform already does a good job of telling me:
"What am I about to change?"
What I want this workflow to help answer is:
"What could happen because I changed it?"
For me, that's the more interesting problem.
And the whole project started because I broke something first.
Project: https://github.com/ai-agents-repo/impactai
Top comments (0)