<< BACK TO BLOG

POV: You're creating AI agents to do your work as a Cloud Engineer

04.JUL.2026 · 9 MIN READ · #ai

C:\BLOG\POV-CREATING-AI-AGENTS-CLOUD-ENGINEER.TXT

When working with AI, you will read articles that explain the feelings, but also ones detailing how to do the job with real-life examples. This blog post is one of the latter. Obviously, this post will contain dummy naming conventions, as to not disclose any real projects.

My experience has been with Kiro, an agentic framework developed by AWS. Your experience may be different depending on what you use.

Let me explain. But before...

Glossary

Lots of new buzzwords appeared with the rise of agentic AI, and a glossary would have been a really nice thing to have.

  • Agent: An AI that can autonomously decide what actions to take to accomplish a goal by using tools, making decisions, and executing multi-step plans.
  • Agentic framework: The system (code, configuration, and conventions) that defines how agents are created, configured, and orchestrated. It provides the structure agents operate within. An example of this would be Kiro.
  • Subagent: An agent spawned by another agent to handle a specific subtask. The parent agent delegates work and uses the subagent's result to continue its own task. Basically, an agent telling another agent what to do.
  • Tool: A discrete capability an agent can invoke (read a file, call an API, query a database). This is how an agent interact with the outside world.
  • Prompt / System prompt: The instructions that define an agent's behavior, personality, constraints, and capabilities.
  • Context: The information available to an agent when making decisions: conversation history, files, tool results, and injected knowledge.
  • Skill: A reusable, self-contained piece of knowledge or procedure an agent can load on demand to handle a specific domain or task type.
  • Steering: Persistent configuration files that shape an agent's behavior across all interactions (coding conventions, workflow rules, project standards…).
  • MCP (Model Context Protocol): An open standard that defines how AI agents connect to external tools and data sources. A server exposes capabilities (tools, resources), and the agent connects as a client to use them.
  • Kiro credits: the system Kiro uses to calculate the cost of a reply. Read more on Kiro's website, because it's kind of… complex. Also, this may not apply to you if you use other agentic frameworks.

Setting up the first agent

Because I'm a nerd, I based my agents names in Team Fortress 2 characters. This decision was liked among my colleagues, as it helped define how the agents actually operated.

My first agent was the Engineer, and it's the agent I use the most for my role: it's a cloud engineer, capable of creating Terraform IaCs, with deep knowledge of how AWS works.

Kiro defines agents using a standard JSON format, which was the following:

{
  "name": "engineer",
  "prompt": "file://${INSTALL_DIRECTORY}/.kiro/prompts/engineer.md",
  "description": "A Cloud Engineer agent to create and deploy infrastructure",
  "welcomeMessage": "Heavy load comin' through! (*Engineer, Team Fortress 2*)",
  "resources": [
    "skill://${INSTALL_DIRECTORY}/.kiro/skills/engineer/SKILL.md",
  ],
  "includeMcpJson": true
}

This was the first revision of my agent. It reads the system prompt and a skill I created with the minimal usual prompts:

You are Engineer, a cloud engineer with deep understanding of
Amazon Web Services and capable of creating Infrastructure as Code
using Terraform. Create the infra with the HLD the user provides,
considering we have 3 environments: development, beta and production.
Be thorough in your job, ask questions when having doubts. Use MCPs to
connect to providers such as gitlab, knowledge base such as
confluence and read tickets from jira.

This prompt turned out to be… kinda bad. This does not provide the LLM with any standard way of operating. You tell it to read an HLD, which may contain information such as what AWS services to create, but… some questions arise immediately after the prompt is given.

  • What AWS accounts do you want to use? Do you have their credentials?
  • Do you need to create a new VPC for each service or is there an existing one?
  • In what region do you want to deploy this? us-east-1 ?
  • What are the minimum specs for the underlying host? (CPU, RAM, storage, network throughput…)
  • Do you want to use security groups with restrictions?

... and so on and so forth. You need to spend a long while providing details to the LLM that will be almost the same for the next project you have to scaffold. The solution for this is simple: provide a better prompt to the agent.

Kiro agents can read markdown files from a resources folder you have created in your user directory. This led me to create several more files, with better prompts and more useful information. But then again, the agent was not well aware of the standard ways of working.

We have some modules predefined in Gitlab with standard configurations for tagging and other stuff. The LLM did not know that because the prompts were, yet again, not enough. So… how do we fix this?

Tell the agent to improve itself (and help it)

When you're developing an agent, you can provide it with some MCPs. They can access websites like Gitlab or Confluence, making it easier to read information.

We can choose one of two options here: tell the agent to look up the information every time we want to do an operation (this is expensive in the long run), or tell it to read the knowledge base and create more resource files. What I did, though, was to make a hybrid mode: have all the information available offline, but if something did not feel right or can be out of date (e.g. versions), look it up.

This was an expensive operation, but it gets executed only once, when setting up your toolkit. The agent went through Gitlab, Confluence and Jira, consuming information at an unfathomable speed. Then, when it had the knowledge required, it began writing. A lot.

Once the agent finished updating its knowledge base, it was time to parse it myself: see what was useful, what could be removed, add my own stuff, and sort information in a way we both could understand.

The agent generated around 5k lines of markdown content. I removed about a thousand and edited around a thousand more. It was tedious, but the results were finally worth it.

Once done, the agent was given the same prompt I wrote before, and it began doing things. This time, it worked.

Improving my workflow with more agents

At the end of the day, I don't just do cloud engineering, I also do Platform and work with Security. I had to make more agents that helped me on my development lifecycle. This meant the birth of Scout, the Platform Engineer agent.

I used the same philosophy for training it, and after a couple of days of fine-tuning the prompts and resources, the agent was capable of creating pipelines with our standard ways of working, using the approved container images and monitoring the output as I would have done without assistance.

Scout was able to set up a project by just giving it a simple prompt:

Do your thing.

The agent knew what to search for and where to look up for the necessary information, and was able to help other colleagues in my team as well with their own projects. It identified almost all projects and was able to configure everything properly without any further prompts. Obviously, there may be projects that need more attention, and Scout was able to stop and ask for guidance in such situations.

After that, a concern came to mind: am I doing this in a secure way? Can the infra we're developing be compromised? And with that, Sniper was born.

This time I asked the cybersecurity team for advice on its training sources, and fed it the documentation they provided. The results produced by this agent were also amazing. So much so that the security team wanted to adopt it.

Orchestration is a thing now

After seeing I had several agents, I thought: how can I make my life more complicated? Oh, I know, let's make another agent that manages my agents!

And thus, Heavy was born. This agent delegated tasks to other agents, aptly called now subagents. You can invoke them by themselves, but I prefer to use the Heavy agent now. What if I need to develop an IaC, add its pipeline and make sure it's safe all at once? Wait… that's exactly my job!

My job nowadays

Now I have eight agents in total. In addition to the ones you already saw on this post, I have now:

  • Medic: this one is more of a helping hand with troubleshooting my computer. It also guides me on creating new agents.
  • Pyro: deals with stress testing the infra.
  • Soldier: methodic software developer, can create a full service in no time. This is the one I actually use the least.
  • Spy: connects my agents with Jira and Confluence, writes documentation and manages tasks.

They are all handled by Heavy, of course, and they have suffered about three major refactors (as everything does in life).

My real advice

I can say so much and provide so many examples, but in the end, my two cents are the following:

  • Agents are an extension of you: they will behave and execute the task as well as you can. This does not mean that you don't have to review what it does: always check before committing code generated by an LLM.
  • Listen and read what other people have to share: other people's experiences can be very useful to you. You can learn a lot from other people's mistakes and experiments
  • Experiment yourself: you have an idea and want to see if it works? Try it out. What's the worst that could happen? You will surely learn something.
  • This is a learning path: using AI will help you learn more, because the context has to come from somewhere, even if you tell it to read from other sources. You must review everything and try new stuff.
  • Guardrails and killswitches: this is the most important piece of advice: never let your AI run fully autonomously, as it can glitch, hallucinate or even lose control. Make sure your prompts always include something like "when in doubt, stop all you're doing and ask for guidance", as well as "if you iterate over a problem N times without solving the problem, stop and ask for help". This will really save your wallet.

Cheers, and may your AI agents assist you better than I can with any blog post!