DEV Community

AWS Community Builders profile image Nao San
Nao San for AWS Community Builders

Posted on

[AWS] Catching up on the basic functions of Kiro Autonomous Agent (Preview) [FrontierAgents]

#aws #devtools #kiro #frontieragent

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

https://qiita.com/Nana_777/items/dff5729a2bab7fe84d73

Introduction

Kiro Autonomous Agent is an AWS Frontier Agent that autonomously executes development tasks. When you assign a task via a GitHub Issue, it automatically analyzes the codebase, plans, implements the changes, and creates a pull request.

This article provides an overview of Kiro Autonomous Agent and explains its basic usage, with screenshots.

After reading this article, you will be able to:

  • Understand the mechanisms and features of Kiro Autonomous Agent

  • Create tasks from GitHub Issues or the Kiro UI and have the agent execute development tasks

  • Review generated pull requests and improve the agent's quality through feedback

Related Articles

In a previous article, we introduced other AWS Frontier Agents: Security Agent and DevOps Agent.

  • [AWS] AWS Security Agent & DevOps Agent Setup Guide [FrontierAgents]

https://qiita.com/Nana_777/items/b5edfacdb00c3e9f6d17

  • [AWS] Achieving AIOps with FrontierAgents [FrontierAgent]

https://qiita.com/Nana_777/items/22b87cd8d28e3675e5c2

The Kiro Autonomous Agent introduced here is a service classified as a "Frontier Agent," just like the agents mentioned above, and is responsible for the development phase. In future articles, we plan to examine the integration of these three Frontier Agents.

What is Kiro Autonomous Agent?

Frontier Agents

AWS offers a category of highly autonomous AI agents called "Frontier Agents." Unlike traditional AI assistants, they have the following three characteristics:

  • Autonomous: Once the goal is specified, the agent itself determines how to achieve it.

  • Scalable: It can perform multiple tasks simultaneously and distribute work to sub-agents.

  • Independent Operation: It can operate for hours to days without human intervention.

Currently, AWS offers three Frontier Agents.

Agent Phase Role
Kiro Autonomous Agent Development Autonomous execution of development tasks (feature implementation, bug fixing, test creation)
AWS Security Agent Development to Deployment Security review and penetration testing
AWS DevOps Agent Deployment to Operation Incident response and prevention recommendations

This article introduces the Kiro Autonomous Agent, which is responsible for the development phase.

Overview of Kiro Autonomous Agent

The Kiro Autonomous Agent is a frontier agent that independently performs development tasks. From feature implementation to bug fixing, it operates asynchronously in an isolated sandbox environment.

Currently, it is being rolled out in preview to Kiro Pro, Pro+, and Power users in stages.

Key Features:

  • Autonomous Task Execution: Assign tasks from GitHub Issues or the Kiro UI to analyze the repository, plan, implement, and create a pull request.
  • Multi-Repository Support: A single task can span multiple repositories, creating a pull request for each.
  • Persistent Context: Maintain context across sessions and continuously learn from code review feedback.
  • GitHub Integration: Start tasks from GitHub Issues using the /kiro command or kiro label. Feedback commands for pull requests (/kiro all, /kiro fix) are also available.
  • Chat Function: Discuss approaches before creating tasks and steer (correct direction) during task execution. Limit of one task per chat.
  • Team Tool Integration: Connect to team tools such as GitHub, Jira, and Slack.
  • Steering File: Define team standards, conventions, and architectural patterns in .kiro/steering/ to improve agent output quality.

How to Create a Task

There are two main ways to assign a task to the Kiro Autonomous Agent.

Setup (First Time Only)

Before creating a task, you need to link your GitHub account.

Access app.kiro.dev/agent and log in with your Kiro account.

image.png

From Settings, click "Connect" Select “GitHub”

image.png

image.png

Kiro Agent GitHub App Authorize

image.png

Select repositories to grant access to

image.png

A repository will be displayed if both of the following conditions are met:

  1. The Kiro Agent GitHub App is installed and authorized for that repository.
  2. Your GitHub account has access rights to that repository.

Note: When selecting repositories, please select only trusted repositories. Especially when mixing public and private repositories, the agent follows the instructions of the code within the repository, so it can be affected if malicious code is included.

↓This is what it will look like when completed
image.png

↓You can also see Kiro under "Installed GitHub Apps" on the GitHub screen
image.png

Method 1: Creating Tasks from the Kiro UI

You can create tasks directly from the Kiro web interface.

image.png

image.png

Multi-repository tasks are also possible:

  • "Add a new API endpoint to the backend service and update the frontend client."

Method 2: Creating from a GitHub Issue

You can also assign tasks using GitHub Issues. This may be more natural for developers, as it allows them to utilize the agent without disrupting their usual workflow.

Starting with the /kiro command

Writing /kiro in a GitHub Issue comment will cause the agent to receive it as a task.

Starting with the kiro label

You can also start a task by adding the kiro label to a GitHub Issue. Adding the label allows the agent to utilize all comments on the Issue as contextual feedback.

image.png

image.png

↓When an issue is published, Kiro will start implementation
image.png

↓ You can also confirm that the task is running on the Kiro web interface.
image.png

Note: When using the /kiro command, your GitHub account must be registered with Kiro. If not registered, you will be prompted to sign up. Also, the Kiro Agent GitHub App must be installed on the target repository.

Chat Function

You can chat with the agent before and after creating a task.

Before Task Creation

  • Discuss implementation approaches

  • Confirm requirements and constraints

  • Get the agent's opinion on technical decisions

The agent will answer using web searches, learning from past code reviews, and context from other tasks.

Task Execution

Even after a task is created, you can continue chatting and do the following:

  • Steering the implementation approach

  • Providing additional requirements or constraints

  • Requesting additional work after reviewing initial results

Additional comments and steering will update the scope of the current task. You cannot create a second task in the same chat. If you want to work on another task, start a new chat.

Task Execution Flow

Once a task is assigned to an agent, it operates in the following structured process:

``
① Environment Setup

Starting the sandbox, loading the MCP server

↓
② Repository Analysis

Clone the repository and analyze the codebase

↓
③ Plan → Execute (One-Shot Progress)

Planning, distributing work to sub-agents,

Implementing while iterating through change verification

*Pause and ask questions only if there are unclear points

↓
④ Completion

Creating a PR, monitoring feedback and CI results
`

Notably, the process proceeds from planning (③) to execution and PR creation (④) in one go. You won't be asked to approve the plan midway through. The agent will only enter a "Needs attention" state and ask questions if they are unsure of what to do.

Let's actually perform the task and follow each step.

Topic

This time, we will request an agent to "add a priority function" to the TODO app (API Gateway + Lambda + DynamoDB + Cognito CDK configuration) used in the previous article series.

The existing TODO app has the following CRUD APIs:

Method Path Description
POST /todos Create TODO
GET /todos Get a list of my TODOs
GET /todos/{id} Get TODO details
PUT /todos/{id} Update TODO
DELETE /todos/{id} Delete TODO

The current TODO data model consists of the fields id, userId, title, description, completed, createdAt, and updatedAt. We're requesting a task to add a priority (high/medium/low) field here, allowing filtering by priority when retrieving the list.

Reasons for choosing this task:

  • It allows us to evaluate whether the agent can understand existing code patterns (Lambda handler structure, DynamoDB access patterns) and implement them consistently.
  • It requires changes across multiple files (createTodo, getTodos, updateTodo + CDK stack definition), allowing us to see the agent's planning ability.
  • It's not too complex and has a good scope for an article topic.

Task to request from the agent

Request the task via GitHub Issue or Kiro UI as follows:

`
Add priority functionality to the TODO app.

Requirements:

  • Add a priority field (high/medium/low) to TODOs
  • Allow specifying priority when creating a TODO (default is medium)
  • Allow changing priority when updating a TODO
  • Add filtering by priority parameter to GET /todos
  • Implement in accordance with existing code patterns (Lambda handler structure, error handling) ` image.png

Step 1: Environment Setup

Upon receiving a task, the agent first launches an isolated sandbox environment. Cloning the repository, installing dependencies, loading the MCP server, etc., are performed automatically.

image.png

image.png

Step 2: Repository Analysis

The agent analyzes the codebase to understand the project structure, the technology stack being used, and existing patterns.

image.png

Step 3: Planning → Execution → PR Creation

Based on the analysis results, the agent internally plans and proceeds with implementation.

image.png

image.png

↓After implementation is complete, the changes will be summarized and explained.

image.png

↓PR creation is completed, and the GitHub URL is provided.
image.png

↓"Give The "feedback" was feedback regarding the preview version of the service.
image.png
↓GitHub screen
image.png

The agent internally plans and then proceeds with implementation. It doesn't pause at the planning stage to await approval; it proceeds directly from planning to execution to PR creation. It only enters the "Needs attention" state and asks questions if there are any unclear points.

In short, developers primarily intervene after a pull request (PR) has been created. By reviewing the PR and providing feedback using the /kiro all or /kiro fix commands if necessary, the agent will commit the fix.

The clearer the task description, the higher the likelihood that the agent will implement it as intended. Discussing the approach via chat beforehand is also effective.

Once implementation is complete, the agent creates a PR on GitHub. The PR includes a description of the changes, the implementation approach, and any trade-offs considered. Both the task creator and the agent are listed as co-authors in the commit.

Feedback on PRs

There are several ways to provide feedback on a PR.

Feedback from app.kiro.dev/agent

Feedback can also be provided from the task view.

GitHub Actions feedback (automatic checks, tests, security scans) is automatically handled when a user provides feedback.

Once feedback is provided, the task transitions from Queued to In progress, and the agent begins working on the fix.

image.png

image.png

image.png

↓Check on GitHub screen
image.png
image.png

Feedback Commands on GitHub

  • /kiro all: Addresses all comments from all reviewers at once

  • /kiro fix: Addresses comments in a specific conversation thread

If there are comments you don't want to address, delete them or reply with your opinion before using the command.

↓ Comments with /kiro fix are immediately marked as "read"
image.png

↓ Confirm that the modification has started on the Kiro web screen.
image.png
↓When the modification is complete, you will be guided to the pull request you created.

image.png

↓You can also check Kiro's work on GitHub
image.png

Task Lifecycle

A task transitions through the following states:

Status Description
Queued Waiting state when the concurrent execution limit (10 tasks) is reached.
In progress Agent is actively working.
Needs attention User input or confirmation is required.
Completed Task completed, PR created. Further work is possible with feedback.
Cancelled Cancelled. Cannot be resumed.

The "Needs attention" status occurs when the agent is unsure of what to do or needs additional information. Answering the question will allow the agent to resume work.

Even in the "Completed" status, you can request further work by sending feedback to the PR.

Persistent Context and Learning

One of the distinctive features of the Kiro Autonomous Agent is persistent context and continuous learning.

Persistent Context

The agent maintains context across sessions. Understanding the codebase gained from the first task is utilized in subsequent tasks.

Learning from Code Reviews

When you send code review feedback to a pull request, the agent learns from that feedback. Feedback such as "This is how we write code in our team" or "Please avoid this pattern" will be reflected in future tasks.

Importantly, only the feedback from the task creator (yourself) influences the agent's learning. Comments from other reviewers do not affect the agent's learning.

Utilizing Steering Files

In addition to code review feedback, you can also communicate the team's standards, conventions, and architectural patterns to the agent in advance by placing Steering files in the .kiro/steering/ directory.


.kiro/
└── steering/
├── coding-standards.md # Coding Conventions
├── architecture.md # Architectural Patterns
└── testing.md # Testing Policy

Defining Steering files makes it easier for agents to generate code that conforms to the team's conventions from their first task. The official documentation highlights the following uses as particularly effective:

  • Coding conventions
  • Architectural patterns
  • Technology stack preferences
  • Testing approaches

In conclusion

Kiro Autonomous Agent is a frontier agent that autonomously performs repository analysis, planning, implementation, and PR creation simply by assigning tasks via GitHub Issues.

This time, we requested a feature modification for an existing TODO app from the Kiro Autonomous Agent.

Previously, Kiro would start implementation only after specification creation, confirmation, and approval. However, in this test, after a human communicated the requirements, the process went straight to PR creation.

While Kiro's more autonomous operation reduces human intervention, it seems necessary to communicate the initial requirements and specifications more accurately.

Since it's still in preview, we don't know what it will be like after GA, but I'm looking forward to the future where humans and Frontier Agents like Kiro collaborate to create great things.

Reference

Kiro autonomous agent

https://kiro.dev/docs/autonomous-agent/

Setup

https://kiro.dev/docs/autonomous-agent/setup/

Using the agent

https://kiro.dev/docs/autonomous-agent/using-the-agent/

Creating tasks

https://kiro.dev/docs/autonomous-agent/using-the-agent/creating-tasks/

Chatting with the agent

https://kiro.dev/docs/autonomous-agent/using-the-agent/chatting/

GitHub Integration

https://kiro.dev/docs/autonomous-agent/github/

Agent Sandbox

https://kiro.dev/docs/autonomous-agent/sandbox/

Amazon launches frontier AI agents

https://www.aboutamazon.com/news/aws/amazon-ai-frontier-agents-autonomous-kiro

Top comments (0)