This is the first post I’m writing about artificial intelligence. Neither in previous blogs, nor on my YouTube channel, nor on my social media have I talked much about AI. It’s not that I didn’t like it, but in general there was an excess of information and especially hype.

This continues to be the case, but a few months ago I started using Amazon Q Developer CLI and more recently Kiro, and the truth is that I feel like talking about these tools.

Although I’ve used many AI tools and models to improve my daily work, for me both Amazon Q Developer CLI and Kiro are game changers in the industry, and this is due to the AI Agents revolution.

I know that AI revolution is overused and many of us are tired of hearing it every 5 minutes, but without that hook it’s hard to get you to read the article. Still, I’m going to try to explain what this agent thing is about and why, in my opinion, it’s something that’s changing our daily lives.

This article will be divided into 2 parts. In this first part we’ll talk a bit more about what Agents are, and in the second we’ll focus on Q Developer CLI and Kiro.

In this post we’ll cover:

  • What AI agents are and how they differ from traditional models
  • The “Agentic Loop” paradigm and its revolutionary impact
  • Model Context Protocol (MCP): The key to integration
  • Strand Agents: Framework for powerful individual agents
  • Why this evolution fundamentally changes AI

From Models to Agents

Models vs Agents

Question-Answer

If you’ve used ChatGPT, Claude, Gemini, Copilot, Perplexity, DeepSeek during this time, the operating model had a simple pattern: you asked for something and it responded directly.

  1. User asked a question
  2. The Model processed the question and responded
  3. End of interaction

This model, while useful, had fundamental limitations:

  • Passivity: AI only responded when asked
  • Limited context: Each interaction was independent, we could give it context, but it wasn’t that complete
  • No persistence: In each new session we had to load our context
  • No action: They only provided information, didn’t execute anything on our systems

It’s true that in recent years these models have evolved and gained depth, making small loops that have improved their responses.

AI Agents

AI agents represent an incredible evolution:

  1. Proactivity: They can initiate actions without us explicitly asking (we can also limit them, so they don’t execute things we don’t want)
  2. Persistence: They maintain context and long-term memory
  3. Autonomy: They can make decisions and execute complex tasks
  4. Integration: They connect with external systems and tools
  5. Continuous learning: They improve with each interaction

In addition to this, we can use specialized agents, so they are much more optimal when executing certain tasks. It’s even very good for reducing models: instead of using gigantic models, we can use distilled models, smaller but much more optimized for the agent’s tasks.

For example, a resource optimization agent only needs to know about that context, it doesn’t require deep knowledge in other subjects, something that’s common in an LLM.

It’s also possible to use different models for each agent, which allows using the best model for each purpose.

This allows us to have multiple coordinated agents that execute small tasks and an orchestrator that brings everything together and executes extremely complex tasks.

What is an Agentic Loop?

Agentic Loop

The Agentic Loop is the fundamental concept of what we’re talking about and is the biggest difference from the traditional model.

It’s a continuous and autonomous cycle that allows AI to operate independently, make decisions and execute actions without constant human intervention.

That is, based on something we ask, agents interact to reach a correct answer, they’re even capable of remedying errors that occur in the middle of the loop.

Example of Agentic Loop Architecture

There isn’t just one type of Agentic Loop, in fact there are many, but let’s give a fairly common example:

Perception → Planning → Action → Evaluation → Learning → Perception…

1. Perception

  • Environment analysis: The agent examines the current context, including data we load, environment state and pending objectives
  • Change identification: Detects modifications in the environment that require attention
  • Multimodal processing: Integrates information from multiple sources (here we can call external tools and other agents)

2. Planning

  • Objective definition: Establishes specific goals based on detected context
  • Task decomposition: Divides a complex task into multiple simple tasks
  • Resource optimization: Plans efficient use of available tools
  • Dependency management: Identifies prerequisites and necessary sequences

3. Action

  • Task execution: Performs planned tasks
  • Tool interaction: Uses APIs, executes commands, modifies files, etc.
  • Communication: Interacts with other systems or agents (MCP or Strands)
  • Monitoring: Supervises progress during execution

4. Evaluation

  • Results analysis: Compares obtained results with expected objectives
  • Error detection: Identifies failures or deviations from the task plan
  • Efficiency measurement: Evaluates performance and resource usage
  • Quality validation: Verifies that results meet defined requirements

5. Learning

  • Knowledge updating: Incorporates new learnings into context
  • Strategy refinement: Improves approaches based on results
  • Pattern adaptation: Adjusts behaviors for similar future situations
  • Persistent memory: Stores experiences for future references

This model is infinite, that is, we ask for a task and it will repeat the loop as many times as necessary. It’s true that if it has any blockage, the loops are designed so that, if no progress is made, it breaks and returns the error to us.

The great advantage of this model is that it’s iterative, that is, it iterates actions until it finds the correct answer.

Practical Example of the Agentic Loop

Let’s see a real example from Amazon Q Developer CLI that uses this model.

I have a problem, I’ve launched a machine in AWS in account xxx and I need to access it via SSM, but I can’t get it to work, do everything necessary to solve it

Cycle 1:

  • Perception: Analyzes AWS configuration and identifies configuration problems.
  • Planning: Decides to check that it has access to AWS.
  • Action: Lists profiles configured locally.
  • Evaluation: Reviews that it has access to AWS.
  • Learning: Knows the AWS CLI profile to execute actions.

Cycle 2:

  • Perception: Analyzes if SSM is configured.
  • Planning: Decides to check if the SSM role is configured on the machine.
  • Action: Executes a describe-instance to review configuration.
  • Evaluation: The machine has the SSM Role configured.
  • Learning: The problem isn’t with the instance role, it must be communications.

Cycle 3:

  • Perception: There may be a communications problem with SSM endpoints.
  • Planning: Decides to review the subnet configuration where the instance is deployed.
  • Action: Executes a describe-route-tables of the subnet’s route table.
  • Evaluation: The instance is in a private subnet.
  • Learning: The problem is here, the instance has no way to reach SSM endpoints.

Cycle 4:

  • Perception: It’s necessary to deploy SSM endpoints.
  • Planning: Decides to create SSM endpoints in the subnet where the instance is.
  • Action: Executes a create-vpc-endpoint for each SSM endpoint, deploying in the indicated subnet.
  • Evaluation: The endpoints are necessary for SSM to work.
  • Learning: The problem should be resolved; we’ve allowed communication with endpoints.

Cycle 5:

  • Perception: Need to check that SSM is operational.
  • Planning: Decides to check SSM status.
  • Action: Executes a describe-instance-information to see SSM status.
  • Evaluation: The agent is operational and reporting.
  • Learning: The problem is now resolved, the instance is accessible via SSM.

This is a small and simplified example, there are really more steps and in some cases our intervention is necessary. The normal thing (if we hadn’t said to do everything necessary to solve it) is that when it detected the problem it would give us several alternatives to solve it.

Why it’s Something That Changes AI

  1. Real Autonomy: Agents can work independently for hours or days
  2. Continuous Improvement: Each cycle makes the agent more efficient
  3. Adaptability: Dynamically adjusts to environment changes
  4. Scalability: Can handle multiple tasks simultaneously
  5. Persistence: Maintains context and long-term progress

Key Differences with the Previous Model

Aspect Traditional Model Agentic Loop
Initiative Reactive Proactive
Duration Single interaction Continuous process
Memory No persistence Long-term memory
Capability Only responses Task execution
Learning Static Dynamic and continuous
Integration Limited Extensive with tools

Model Context Protocol (MCP)

MCP

So far we’ve talked about agents, but many times we need more specific things or even to connect with third-party tools; this is where MCP comes in.

What is MCP?

The Model Context Protocol (MCP) is the open standard developed by Anthropic that makes the Agentic revolution possible. It’s the protocol that allows AI agents to integrate natively with any tool, API, service or system. It’s an open standard that allows anyone to generate their own MCPs and enable integration with other systems.

I love this model, because instead of betting on a proprietary model, in this case they went directly to an Open Source model that allows integration of any agent regardless of the LLM it uses, who develops it or who its target consumer is.

This is something that hasn’t been usual in the industry, normally each company designs its own proprietary integration and forces others to use it.

MCP Architecture

Main Components

1. MCP Servers

  • Provide specific tools to agents
  • Can be AWS services, other Cloud, third-party APIs or local tools, etc.
  • Expose capabilities in a standardized way

2. MCP Clients

  • AI agents that consume the tools
  • Amazon Q Developer CLI and Kiro are examples of MCP clients

3. Protocol Layer

  • Standardized communication layer
  • Guarantees interoperability between different systems
  • Handles authentication, authorization and error management

MCP in Practice

What we can do with an MCP

Basically anything, to give you an idea, I use multiple MCPs in my daily work.

I use MCPs that allow me to access local files on my PC, on the other hand, I use MCPs that read AWS documentation, others that help me with the design of certain services and even some specific to Terraform, but the possibilities are infinite.

Additionally, developing an MCP is not excessively complex and allows us to generate MCPs ourselves; likewise, we can iterate and improve our own MCPs over time.

Practical Example: MCP Server Configuration

An example of how to configure a basic MCP server to access AWS documentation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": ["search_documentation", "read_documentation"]
    },
    "filesystem": {
      "command": "uvx",
      "args": ["mcp-server-filesystem", "--path", "/workspace"],
      "disabled": false,
      "autoApprove": ["read_file", "list_directory"]
    }
  }
}

This configuration file allows any MCP agent to access both AWS documentation and the local file system in a standardized way.

Additionally, it’s configuring these reading tools to be pre-approved.

MCP Advantages

  1. Interoperability: Any agent can use any MCP server
  2. Extensibility: Easy to add new capabilities without modifying the agent
  3. Reusability: MCP servers can be shared between different projects
  4. Standardization: Common protocol that facilitates development and maintenance

Strand Agents

Strands Agents

In addition to MCPs, there’s another very interesting framework which is Strand Agents. While MCP focuses on integrating individual tools, Strand Agents focuses more on creating the agents themselves, as well as their orchestration, integrating multiple agents, allowing persistence of states and contexts, etc.

What is Strand Agents?

Strand Agents is a simple but powerful SDK developed by Amazon that adopts a model-based approach to build and execute AI agents. From more common conversational assistants (typical in AI) to complex autonomous workflows, it allows orchestrating from local development to production deployment of the application.

Main Framework Features

  • Lightweight but very flexible: Allows from a very simple agent loop, but which is completely customizable
  • Agnostic: Has support for using Amazon Bedrock and also proprietary models from Anthropic, LiteLLM, Llama, Ollama, OpenAI, Writer and custom providers
  • Advanced Capabilities: Allows implementing multi-agent systems, autonomous agents and streaming support
  • Integrated MCP: Has native support for Model Context Protocol (MCP) servers, allowing access to thousands of pre-built tools

Strand Agents Architecture

Main Components

1. Agent Core

  • LLM-based reasoning engine that processes user requests
  • Automatic agent lifecycle management (initialization, execution, termination)
  • Support for multiple model providers interchangeably

2. Tool System

  • Native tool system using Python decorators
  • Automatic hot reloading from tool directories
  • Native integration with MCP servers for external tool access

3. Session Management

  • Automatic persistence of conversations and agent state
  • Support for local storage (FileSessionManager) and cloud (S3SessionManager)
  • Intelligent context management with configurable strategies

4. Multi-Agent Orchestration

  • Coordination of multiple specialized agents working together
  • Inter-agent communication to solve complex tasks
  • Automatic task distribution according to each agent’s capabilities

The Power of Strand Agents in Practice

Advanced Capabilities

Structured Output

  • Obtaining structured responses using Pydantic models
  • Automatic type and schema validation
  • Perfect integration with existing data systems

Extensible Hook System

  • Configurable callbacks at different points in the agent lifecycle
  • Behavior modification without changing core code
  • Advanced monitoring and logging of operations

Complete Observability

  • Detailed metrics of each agent execution
  • Complete traces of the reasoning process
  • Information about tokens used, execution time and tools utilized

Strand Agents Advantages

Strand Agents Ecosystem Advantages

  1. Simplicity: Python-based API that allows developing agents simply
  2. Flexibility: Support for multiple model providers and custom tools
  3. Scalability: From simple agents to complex multi-agent systems
  4. Observability: Complete metrics and traces for debugging and optimization
  5. Persistence: Automatic state and long-term session management
  6. Integration: Native support for MCP and extensive tool ecosystem

Combining MCP with Strand Agents

One of the most interesting things about this approach is that we can use Strand Agents with MCP so that we have an orchestration of agents and tools that’s brutal.

  • MCP provides standard integration with tools
  • Strand Agents provides the robust framework to create powerful agents
  • Combining them allows us to create a complete ecosystem for enterprise agents.

This combination allows creating much more complex agents, but also orchestrating these Strand Agents and MCPs so that we have a much more optimized solution, in addition to being able to manage states, contexts, etc.

Additional Resources

If you want to delve deeper into these concepts, here are some useful links:

MCP (Model Context Protocol)

Strand Agents

Mentioned Tools

Conclusion of the First Part

At the beginning of the article I mentioned that other times I didn’t feel like writing about AI, not because I didn’t find it interesting, but because there was too much hype and I think it saturated us a lot.

But this change with the Agentic model is not just an incremental improvement in the AI model.

We’re at a very important moment because these two technologies together have given us two tools in AWS that there are no words to describe them like Amazon Q Developer CLI and Kiro, which have come to change how we work until now.

In the second part we’ll explain how Amazon Q Developer CLI and Kiro are applying these concepts to revolutionize software development, and what this means for the future of our industry.

👉 Next: “Kiro and Amazon Q Developer CLI: The Agentic revolution in our daily lives”