DEV Community: Fathima rasha

Kiro: From Vibe Coding to Spec-Driven Development

Fathima rasha — Sun, 20 Sep 2026 08:42:37 +0000

Kiro: Beyond AI Coding — Building Software with an Agent

AI coding has changed how quickly we can turn an idea into working software.

A few prompts can generate a UI, create an API, write database models, and even fix bugs.

But there is a problem we don't talk about enough.

Writing code is only one part of building software.

A real project also requires understanding requirements, making architectural decisions, maintaining coding standards, testing changes, working with external tools, documenting decisions, and keeping everything consistent as the project grows.

This is where I started looking at Kiro differently.

Kiro isn't just about asking an AI to write code. Its approach is centered around giving an AI agent more of the context, structure, tools, and workflow required to participate in software development.

Kiro describes itself as an AI-powered development environment for building software from prototype to production. Today, its agent capabilities extend across the IDE, CLI, Web, and Mobile through a unified agent harness. (Kiro)

And that leads to a more interesting question:

What happens when an AI agent is given an engineering process, rather than just a prompt?

The Problem With "Just Build This"

Imagine telling an AI:

"Build a scholarship management platform for students."

The model can start generating code almost immediately.

But what exactly should it build?

Should students be able to edit an application after submitting it?

Who verifies the information?

What happens when a student isn't eligible?

What should teachers see?

How should authentication work?

What happens to uploaded documents?

What database structure should be used?

What testing strategy should the project follow?

These decisions exist whether we document them or not.

When they're not documented, they often end up scattered across conversations, code, and the developer's memory.

That's where the difference between code generation and software engineering with agents becomes important.

From Prompt-Driven Development to Spec-Driven Development

One of Kiro's core ideas is spec-driven development.

Instead of immediately jumping from:

Idea → Code

Kiro introduces a more structured path:

Idea
  ↓
Requirements
  ↓
Design
  ↓
Tasks
  ↓
Implementation
  ↓
Verification

A specification becomes an artifact that captures what you're actually trying to build.

Kiro's current spec workflow can generate requirements, a technical design, and implementation tasks, which the agent can then use to carry out the work. (Kiro)

This changes the role of the prompt.

The prompt is no longer just:

"Write the feature."

It can become:

"Understand the feature, clarify the requirements, design the solution, break it into tasks, and then implement it."

That extra structure matters especially when a feature is large enough that the first implementation isn't necessarily the right implementation.

But an Agent Needs Context

Even a powerful model doesn't automatically know how your project works.

Suppose your team has decided:

all APIs use a particular error format
React components follow a specific structure
tests use a certain framework
database access follows a particular pattern
pull requests follow a specific template

You could explain all of this every time you start a conversation.

Or you could make that knowledge part of the project.

That's what Kiro's Steering capability is designed for.

Steering uses Markdown files to give Kiro persistent knowledge about the project's conventions, architecture, technologies, testing practices, and other standards. These can live under .kiro/steering/. (Kiro)

For example:

.kiro/
└── steering/
    ├── product.md
    ├── architecture.md
    ├── coding-standards.md
    └── testing.md

Now the repository doesn't only contain source code.

It also contains instructions about how that source code should be developed.

That's a powerful idea.

The Repository Starts Carrying Engineering Knowledge

Think about a normal project.

src/
tests/
package.json
README.md
...

Now imagine:

project/
│
├── src/
├── tests/
├── README.md
│
└── .kiro/
    ├── steering/
    ├── specs/
    ├── hooks/
    └── agents/

The .kiro directory can become a place where important parts of the development workflow live alongside the project.

Kiro's documentation describes project-level configuration in .kiro/ as shared across its different surfaces, allowing the same steering, specs, agents, hooks, and MCP configuration to travel with the repository. (Kiro)

So the project doesn't just contain:

What the software is.

It can also contain:

How the agent should work with the software.

Then Comes Automation

Now imagine the agent modifies a file.

Normally, you might manually:

run a formatter
run tests
check types
inspect the change
update related files

What if some of those actions could happen automatically?

That's where Kiro Hooks come in.

Hooks can trigger shell commands or agent prompts when defined events occur. Depending on the environment, events can include file changes, tool execution, prompt submission, and spec-task execution. (Kiro)

For example:

Agent modifies component
        ↓
     File saved
        ↓
      Hook
        ↓
Run validation
        ↓
   Test results

Or:

New component created
        ↓
      Hook
        ↓
Generate/update test

The important concept isn't simply automation.

It's turning development rules into executable workflows.

Instead of repeatedly telling the agent:

"Remember to run the tests."

you can create a workflow where the appropriate action happens automatically.

An Agent Doesn't Have to Work Alone

Modern software development rarely happens inside one editor.

You may need:

GitHub
databases
APIs
documentation
cloud services
monitoring tools
internal systems

This is where MCP — Model Context Protocol — becomes important.

Kiro supports MCP servers to connect agents with external tools and data sources. (Kiro)

Conceptually:

                  Kiro Agent
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
     Project         MCP         External
      Files        Servers        Tools
        │             │             │
        └─────────────┼─────────────┘
                      ↓
               Development
                 Workflow

The agent therefore doesn't have to be limited to:

Read code → generate code.

It can become part of a larger tool-using workflow.

Skills, Custom Agents and Sub-Agents

As projects become more complex, one general-purpose agent may not be enough.

Kiro also provides mechanisms such as Skills, Custom Agents, and Sub-agents.

Skills can package reusable instructions and knowledge.

Custom agents can be configured for specialized workflows.

Sub-agents can handle focused work in parallel.

Kiro's current documentation lists these alongside MCP, permissions, hooks, steering, and other agent capabilities. (Kiro)

This starts to resemble a small engineering team:

                    Main Agent
                        │
          ┌─────────────┼─────────────┐
          ↓             ↓             ↓
       Agent A       Agent B       Agent C
      Frontend        Tests        Backend

The important part is not the analogy itself.

The important part is delegation.

Instead of one conversation becoming responsible for everything, focused pieces of work can be separated.

One Agent, Multiple Surfaces

Another part of Kiro that I find particularly interesting is that the agent isn't tied to one interface.

Kiro currently provides an IDE, CLI, Web, and Mobile experience around a unified agent harness. (Kiro)

That means a workflow can look something like:

          Kiro Agent
               │
     ┌─────────┼─────────┐
     ↓         ↓         ↓
    IDE       CLI       Web
     │                   │
     └─────────┬─────────┘
               ↓
            Mobile

You might start designing a feature in the IDE.

Continue implementation through the CLI.

Run a longer task in Kiro Web.

Then check its progress from your phone.

The important idea is that these aren't necessarily separate agents with completely different project knowledge.

Kiro's unified harness is designed so capabilities and configuration can work across these surfaces. (Kiro)

Let's Put It All Together

Suppose we're building a Student Opportunity Platform.

Students can:

discover scholarships
check eligibility
save opportunities
submit applications
track application status

Teachers can:

create student profiles
verify information
manage applications

Instead of:

"Build the application."

we could approach it like this:

1. Define the product

What problem are we solving?

2. Create the specification

What exactly should the feature do?

Requirements
     ↓
Design
     ↓
Tasks

3. Add project knowledge

Tell Kiro:

Technology stack
Architecture
Coding standards
Testing strategy
Security rules

through steering.

4. Implement

Let the agent work through the defined tasks.

5. Connect tools

Use MCP when the agent needs external systems.

6. Automate repetitive work

Use hooks for validation, testing, documentation, or other recurring workflows.

7. Review

The developer remains responsible for understanding and approving the result.

The complete workflow becomes:

                 PRODUCT IDEA
                       │
                       ▼
                 SPECIFICATION
                       │
                       ▼
                  REQUIREMENTS
                       │
                       ▼
                     DESIGN
                       │
                       ▼
                    TASKS
                       │
                       ▼
                ┌──────────────┐
                │ KIRO AGENT   │
                └──────────────┘
                  │     │     │
                  ↓     ↓     ↓
              Steering MCP  Skills
                  │     │     │
                  └─────┼─────┘
                        ↓
                  IMPLEMENTATION
                        │
                        ↓
                      Hooks
                        │
                        ↓
                   VALIDATION
                        │
                        ↓
                     REVIEW

Now we're no longer talking about an AI that simply generates code.

We're talking about an AI agent operating inside a software development system.

The Developer's Role Is Changing

This doesn't mean developers become unnecessary.

Quite the opposite.

The developer increasingly becomes responsible for the things that require understanding the bigger picture:

What are we building?

Why are we building it?

What constraints matter?

What architecture should we use?

What should the agent be allowed to do?

How do we know the result is correct?

The shift looks something like this:

Traditional workflow

Developer
   ↓
Write
   ↓
Debug
   ↓
Test
   ↓
Repeat

versus an increasingly agentic workflow:

Developer
   ↓
Define intent
   ↓
Define constraints
   ↓
Plan
   ↓
Delegate
   ↓
Review
   ↓
Verify

The developer isn't disappearing from the loop.

The developer is moving higher in the loop.

The Bigger Picture

When Kiro launched, its central idea was to bring more structure to AI-assisted development through concepts such as specs and hooks, rather than stopping at rapid prototype generation. (Kiro)

Since then, the platform has expanded considerably.

The current Kiro ecosystem includes:

Spec-driven development
Steering
Hooks
MCP
Skills
Custom agents
Sub-agents
Permissions
CLI workflows
Web-based autonomous development
Multiple agent surfaces (Kiro)

Looking at these individually can make them feel like a collection of features.

But together, they point toward something bigger:

The development environment itself is becoming part of the agent.

That's the interesting shift.

From AI That Writes Code to AI That Understands the Workflow

The first wave of AI coding focused on a simple promise:

Write code faster.

The next wave is asking a broader question:

Can an AI agent participate in the entire software development workflow?

That requires much more than code generation.

It requires:

Context → What does this project look like?

Intent → What are we actually trying to build?

Planning → What needs to happen?

Tools → What systems can the agent interact with?

Execution → Can it actually perform the work?

Automation → Can repetitive workflows happen automatically?

Verification → How do we know the result is correct?

Kiro's approach brings many of these pieces into one development environment.

And perhaps that's the most interesting way to look at Kiro:

It's not just an AI that helps you write software. It's an attempt to make the development environment itself agentic.

The future of AI-assisted development may therefore look less like:

Prompt → Code

and more like:

Intent → Context → Plan → Agent → Tools → Execution → Verification → Software.

And that's a much bigger change than simply generating code faster.

Agentic AI: From AI That Responds to AI That Acts

Fathima rasha — Mon, 14 Sep 2026 09:24:24 +0000

AI applications have traditionally focused on generating responses to user prompts. But what if an AI system could understand a goal, decide what needs to be done, use external tools, retrieve information, and take actions to complete the task?

This is where Agentic AI comes in.

What Is Agentic AI?

For a long time, most AI applications followed a simple pattern: you ask a question, the model generates an answer, and the interaction ends.

With the rise of Agentic AI, the goal is no longer limited to generating a response. AI systems can be designed to understand a goal, reason about what needs to be done, use tools, take actions, observe the results, and decide what to do next.

Imagine telling an AI:

“Plan a three-day trip to Bangalore under ₹15,000, find suitable hotels and activities, compare the options, and create an itinerary.”

A traditional chatbot might give you a suggested itinerary based on the information it already knows.

An agentic system, on the other hand, could break the request into smaller tasks, retrieve information, use external tools, compare the results, and adjust its approach if the initial options don't satisfy the requirements.

That shift—from generating an answer to working toward a goal—is the fundamental idea behind Agentic AI.

From LLMs to AI Agents

Large Language Models (LLMs) are extremely capable at understanding and generating natural language. However, an LLM by itself is primarily a model for generating outputs.

A simple LLM application can be represented as:

User
  ↓
Prompt
  ↓
LLM
  ↓
Response

For example, you might ask:

“How can I plan a trip to Bangalore?”

The model can explain how to plan the trip, suggest places to visit, and provide general recommendations.

But it doesn't necessarily have the ability to search current hotel availability, query a booking system, calculate prices using live data, or perform actions in external systems.

An agentic application adds these capabilities around the model.

The LLM is still an important part of the system, but it is now working as one component within a larger architecture.

A simplified agentic application looks more like:

User Goal
   ↓
AI Agent
   ↓
Reason / Plan
   ↓
Use Tools
   ↓
Observe Results
   ↓
Evaluate
   ↓
Next Action
   ↓
Final Result

What Makes an AI System Agentic?

There isn't a single feature that suddenly turns an LLM into an agent. Agentic systems generally combine several capabilities that allow the system to work toward an objective.

Goal-Oriented Behavior

An agent starts with a goal rather than simply responding to isolated questions.

For example:

“Find me a hotel in Bangalore for three nights under ₹9,000.”

The agent needs to understand the constraints and work toward finding an appropriate option.

The user doesn't necessarily tell it every step.

They provide the objective, while the system determines what needs to happen to achieve it.

Reasoning and Planning

Once the agent understands the goal, it needs to determine what actions are required.

For the travel example, it might determine that it should:

Identify the travel dates
Search for suitable hotels
Check prices
Compare available options
Verify that the total fits the budget

This is where the underlying model provides reasoning and decision-making capabilities.

The important point is that the agent can determine the next step based on the current situation rather than simply following a fixed response template.

Tool Use

An AI model cannot automatically access every external system.

Tools give an agent the ability to interact with the outside world.

For example, a travel agent could have access to:

Flight search APIs
Hotel APIs
Maps
Weather services
Databases
Calculators

The agent determines which capability it needs, while the tool performs the actual operation.

For example:

Agent
  │
  │ "I need hotel availability"
  ▼
Hotel Search Tool
  │
  │ Search external system
  ▼
Hotel Results
  │
  ▼
Agent

This is one of the biggest differences between a simple chatbot and an agentic application.

The Agentic Loop

The combination of reasoning, tools, and feedback creates what is commonly described as an agent loop.

An agent can reason about a task, take an action, observe the result, and use that result to determine its next action.

For example, suppose the agent needs to find a hotel under ₹3,000 per night.

It searches for hotels and receives:

Hotel A — ₹4,500/night
Hotel B — ₹2,800/night
Hotel C — ₹3,700/night

The agent can evaluate these results and recognize that Hotel B satisfies the budget constraint.

But imagine the search returned:

Hotel A — ₹4,500/night
Hotel B — ₹3,800/night
Hotel C — ₹4,200/night

Now the agent can determine that none of the options satisfy the requirement.

It could decide to search for more options, change the search criteria, or ask the user whether the budget can be increased.

The important part is that the result of one action influences the next action.

A simplified agent loop is:

Reason
  ↓
Act
  ↓
Observe
  ↓
Evaluate
  ↓
Reason Again
  ↓
Act Again

This iterative behavior is at the heart of many agentic systems.

Knowledge and Context

An agent may also need information that isn't contained in the model itself.

Imagine a company's internal support agent.

A user asks:

“What is our refund policy for enterprise customers?”

The model may understand what a refund policy is, but it doesn't automatically know the company's private policy.

The agent therefore needs access to external knowledge.

That knowledge could come from:

Documents
Databases
APIs
Internal documentation
Product catalogs
Company policies

The agent can retrieve relevant information and use it as context when generating its response.

This is particularly important for enterprise applications, where the AI needs to work with an organization's own data.

Memory and State

Agentic applications may also need to maintain context.

Consider a conversation:

User: “I'm planning a family trip to Bangalore.”

Agent: “What's your budget?”

User: “₹15,000.”

Later, the user says:

“Find a hotel.”

A useful system should understand that the request relates to the earlier conversation.

Memory and application state allow an agentic system to maintain useful information across steps or interactions.

This can range from short-term conversation context to longer-term information that an application intentionally stores for future interactions.

Adaptation

Another important characteristic of agentic systems is the ability to adapt based on what happens.

Suppose the user asks:

“Find a laptop under ₹80,000 with 16 GB RAM.”

The agent searches available products and discovers that the preferred option is unavailable.

Instead of simply stopping, an agentic workflow could search for alternatives and evaluate them against the original requirements.

The system's next action is influenced by the outcome of the previous action.

That is very different from a fixed sequence where every request follows exactly the same path.

Agentic AI Is Not the Same as Automation

It is tempting to think that an AI agent is simply automation with an LLM attached.

There is an important difference.

Traditional automation generally follows a predefined sequence:

Step 1
  ↓
Step 2
  ↓
Step 3
  ↓
Step 4

An agentic system can dynamically determine what to do next based on the current state and results:

Goal
 ↓
Reason
 ↓
Action
 ↓
Observe
 ↓
Decision
 ├── Continue
 ├── Try another tool
 ├── Change approach
 └── Finish

For example, a traditional travel workflow might always execute:

Search → Filter → Display

An agent could determine that it needs to:

Search
   ↓
Compare
   ↓
Check Budget
   ↓
Search Again
   ↓
Retrieve Additional Information
   ↓
Create Itinerary

The agent has more flexibility in determining the path toward the goal.

Agentic AI Doesn't Mean Unlimited Autonomy

Agentic systems can take actions, but that doesn't mean they should have unrestricted access to everything.

Imagine an agent that has access to:

Your email
Your database
Payment systems
Cloud infrastructure
File storage

Giving the agent unrestricted permissions could create serious security risks.

A production system therefore needs controls around what the agent can do.

For sensitive actions, a workflow might look like:

Agent
  ↓
Prepare Action
  ↓
Human Approval
  ↓
Execute Action

For example, an agent might be allowed to prepare a payment but require a human to approve it before the payment is actually executed.

Agentic AI should therefore be thought of as controlled autonomy, not unlimited autonomy.

Agentic AI Is a System, Not Just a Model

This is perhaps the most important concept to understand.

An AI agent isn't simply a powerful LLM.

A practical agentic application can combine:

                 Agentic AI System
                        │
       ┌────────────────┼────────────────┐
       ↓                ↓                ↓
     Model            Tools           Knowledge
       │                │                │
       └────────────────┼────────────────┘
                        ↓
                    Orchestration
                        │
              ┌─────────┴─────────┐
              ↓                   ↓
           Memory              Actions

The model provides intelligence and language understanding.

Tools provide the ability to interact with external systems.

Knowledge provides additional information.

Memory maintains useful context.

The orchestration layer coordinates the process.

Together, these components create an agentic system.

A Simple Mental Model

If you are new to Agentic AI, remember this progression:

LLM
 ↓
LLM + Tools
 ↓
LLM + Tools + Knowledge
 ↓
LLM + Tools + Knowledge + Memory
 ↓
Agentic AI System

The fundamental idea can be summarized as:

Generative AI focuses on generating content. Agentic AI focuses on achieving goals through reasoning, actions, tools, and feedback.

And this is what makes Agentic AI particularly interesting for application development: instead of building an AI that only talks about a task, we can build systems that are capable of working through the task.

Implementing using AWS

Understanding Agentic AI is only the first step.

The next question is:

How do we turn these concepts into a real AI agent using AWS?

To make this practical, let's design a Travel Planning Agent.

A user should be able to say:

“Plan a 3-day trip to Bangalore under ₹15,000.”

The agent should understand the request, retrieve relevant information, use tools to search for options, evaluate the results, and produce an itinerary.

Instead of treating this as one large AI problem, we can break the system into several components and map each capability to AWS.

Start With a Foundation Model — Amazon Bedrock

Every agent needs a model capable of understanding instructions and making decisions.

With Amazon Bedrock, we can access foundation models through a managed AWS service rather than managing model infrastructure ourselves.

For our travel agent, the model is responsible for understanding requests such as:

“Plan a 3-day trip to Bangalore under ₹15,000.”

It can identify important information such as:

Destination → Bangalore
Duration    → 3 days
Budget      → ₹15,000
Goal        → Create a travel plan

However, the foundation model alone is not the agent.

It provides the intelligence used by the agent, while other components give the system tools, memory, knowledge, and the ability to execute actions.

Run the Agent — Amazon Bedrock AgentCore Runtime

Our agent needs somewhere to execute.

This is where Amazon Bedrock AgentCore Runtime comes in.

AgentCore Runtime provides a managed environment for deploying and running agents. It is designed to support different agent frameworks and models, allowing the agent's orchestration logic to run in a managed environment.

Inside the runtime, our agent can execute its workflow:

User Request
     ↓
AgentCore Runtime
     ↓
Agent
     ↓
Reason → Plan → Act → Observe

This gives us the execution environment required to turn our model and agent logic into an actual agentic application.

Give the Agent Knowledge — Amazon Bedrock Knowledge Bases

Our travel agent may need information that isn't contained in the model itself.

For example, suppose we provide it with:

Bangalore travel guides
Destination information
Local activity information
Company travel policies
Other application-specific documents

We can use Amazon Bedrock Knowledge Bases to retrieve relevant information from connected data sources.

Knowledge Bases supports Retrieval-Augmented Generation (RAG), allowing an application to retrieve relevant information and provide it to the model as context.

For example, the user could ask:

“Which activities are suitable for a three-day Bangalore trip?”

The agent can retrieve relevant information from the knowledge base and use it when constructing the itinerary.

With a knowledge base, the application can retrieve domain-specific information from connected data sources and provide that information to the model as context.

Give the Agent Tools — AgentCore Gateway

Now we have an agent that can reason and retrieve information.

But reasoning alone isn't enough.

Suppose our agent needs to:

Search flights
Search hotels
Check weather
Find activities
Calculate costs

These capabilities can be exposed as tools.

This is where Amazon Bedrock AgentCore Gateway becomes useful.

AgentCore Gateway provides a managed connectivity layer between agents and tools. It can connect APIs, Lambda functions, existing services, MCP servers, and other tool sources so that agents can discover and invoke capabilities.

Conceptually:

                 AI Agent
                    │
                    ▼
           AgentCore Gateway
                    │
        ┌───────────┼───────────┐
        ↓           ↓           ↓
    Hotel API   Flight API   Weather API
        │           │           │
        └───────────┼───────────┘
                    ↓
              Tool Results
                    ↓
                  Agent

The agent doesn't need to know how every backend system works.

Instead, it can work with defined capabilities such as:

search_hotels()
search_flights()
get_weather()
find_activities()

The agent can then determine which tool is appropriate for the current task.

How Does the Agent Actually Use a Tool?

Let's follow one step.

The user says:

“Find hotels under ₹3,000 per night.”

The agent determines that it needs hotel information.

It selects a hotel-search tool.

The interaction can be represented as:

User
 ↓
Agent
 ↓
Decides: "I need hotel data"
 ↓
AgentCore Gateway
 ↓
Hotel Search API
 ↓
Hotel Results
 ↓
Agent
 ↓
Evaluate Results

For example:

Hotel A → ₹4,500/night
Hotel B → ₹2,800/night
Hotel C → ₹3,700/night

The agent can determine that Hotel B satisfies the user's budget.

This is the reason → act → observe loop discussed earlier.

Execute Custom Actions — AWS Lambda

Not every capability needs to be an external API.

We may need our own application logic.

For example:

“Calculate the total cost of this itinerary and determine whether it is within ₹15,000.”

We could implement that operation using AWS Lambda.

The Lambda function could perform deterministic calculations such as:

Hotel Cost
    +
Transportation
    +
Activities
    +
Other Expenses
    =
Total Cost

The Lambda function can then be exposed as a tool through AgentCore Gateway.

This creates an important separation:

The agent decides what needs to be done; deterministic application code performs the operation.

This is a useful design pattern for production agentic systems because not every decision should be left to probabilistic model output.

Give the Agent Memory — AgentCore Memory

Now imagine a longer conversation.

The user says:

“I'm travelling with my family.”

Later:

“Find accommodation.”

The second request makes more sense if the system remembers the earlier context.

Amazon Bedrock AgentCore Memory can provide memory capabilities for agentic applications, including short-term conversational context and longer-term information that can persist across sessions.

Conceptually:

Conversation
     ↓
AgentCore Memory
     ↓
Relevant Context
     ↓
Agent

This allows the application to maintain useful context instead of treating every interaction as completely independent.

Store Application Data — Amazon DynamoDB

Memory and application data are not necessarily the same thing.

Our travel application may need to store structured information such as:

User preferences
Saved itineraries
Previous trips
Booking information
Application state

We can use Amazon DynamoDB for this type of application data.

For example:

Travel Application
       ↓
    DynamoDB
       │
 ┌─────┼─────────────┐
 ↓     ↓             ↓
Users  Trips      Itineraries

This gives the application a persistent data layer separate from the agent's conversational memory.

Putting the Agent Together

At this point, we have several individual capabilities:

Capability	AWS Service
Foundation model	Amazon Bedrock
Agent execution	Amazon Bedrock AgentCore Runtime
External knowledge	Amazon Bedrock Knowledge Bases
Tool connectivity	AgentCore Gateway
Custom actions	AWS Lambda
Agent memory	AgentCore Memory
Application data	Amazon DynamoDB

Now let's see what happens when a real request arrives.

The Complete Agentic Workflow

The user says:

“Plan a 3-day trip to Bangalore under ₹15,000.”

Step 1 — Understand the Request

The agent receives the user's goal.

It identifies:

Destination → Bangalore
Duration    → 3 days
Budget      → ₹15,000
Objective   → Create itinerary

Step 2 — Determine What It Needs

The agent realizes that it needs information about:

Transportation
Hotels
Activities
Prices

Step 3 — Retrieve Relevant Knowledge

The agent can use the Knowledge Base to retrieve relevant destination information.

For example, it could retrieve information about:

Places to visit
Local activities
Travel information
Relevant policies

Step 4 — Use Tools

The agent can use Gateway-connected tools to search for:

Flights
Hotels
Activities
Weather

The results are returned to the agent.

Step 5 — Calculate

The agent can invoke a Lambda function to calculate the estimated total cost.

Suppose the result exceeds the user's ₹15,000 budget.

Step 6 — Adapt

The agent now has new information.

Instead of simply returning the result, it can search for cheaper alternatives.

For example:

Expensive Hotel
      ↓
Budget Constraint Violated
      ↓
Search Alternatives
      ↓
Evaluate New Options
      ↓
Select Suitable Option

Step 7 — Generate the Result

The agent now has enough information to create a plan that satisfies the user's constraints.

It can generate the final itinerary.

The complete process can be summarized as:

                 User Goal
                     ↓
              Understand Goal
                     ↓
               Reason / Plan
                     ↓
          ┌──────────┼──────────┐
          ↓          ↓          ↓
      Knowledge     Tools      Memory
          ↓          ↓          ↓
          └──────────┼──────────┘
                     ↓
                  Observe
                     ↓
                  Evaluate
                     ↓
              Constraint Check
                     ↓
              ┌──────┴──────┐
              ↓             ↓
          Satisfied      Not Satisfied
              ↓             ↓
          Complete      Adapt / Retry
              │             │
              └──────┬──────┘
                     ↓
                Final Result

This is the important transition from an AI model to an agentic application.

The model isn't working alone.

It is working together with tools, knowledge, memory, application logic, and runtime infrastructure.

How the AWS Components Fit Together

The architecture can be understood as a set of layers.

Intelligence

Amazon Bedrock

Provides access to foundation models that power the agent's understanding and reasoning.

Agent Execution

Amazon Bedrock AgentCore Runtime

Provides the managed environment where the agent runs.

Knowledge

Amazon Bedrock Knowledge Bases

Provides access to information from connected data sources through retrieval.

Tools

AgentCore Gateway

Provides a managed interface through which agents can discover and invoke tools and connect to APIs, Lambda functions, MCP servers, and other services.

Actions

AWS Lambda / APIs

Perform deterministic business operations and interact with external systems.

Memory

AgentCore Memory

Maintains useful conversational and longer-term agent context.

Data

Amazon DynamoDB

Stores application-specific structured data.

Together:

                 ┌─────────────────────┐
                 │        User         │
                 └──────────┬──────────┘
                            ↓
                    Application Layer
                            ↓
                 AgentCore Runtime
                            ↓
                    ┌──────────────┐
                    │   AI Agent   │
                    └──────┬───────┘
                           │
          ┌────────────────┼────────────────┐
          ↓                ↓                ↓
   Amazon Bedrock    Knowledge Bases   AgentCore Memory
    Foundation             │                │
      Model                │                │
          │                │                │
          └────────────────┼────────────────┘
                           ↓
                  AgentCore Gateway
                           │
              ┌────────────┼────────────┐
              ↓            ↓            ↓
          Hotel API    Flight API    AWS Lambda
                                         │
                                         ↓
                                    DynamoDB

Why This Architecture Matters

The important lesson isn't simply which AWS service to use.

It is understanding why each component exists.

The foundation model provides intelligence.

The runtime provides an environment for the agent.

Knowledge Bases provide external information.

Gateway connects the agent to tools.

Lambda and APIs perform actual operations.

Memory maintains context.

DynamoDB stores application data.

This separation also gives us better control over security, reliability, and maintainability.

For example, we don't want the model to have unrestricted direct access to a database simply because it needs to retrieve information.

Instead, we can expose carefully defined tools and control what the agent is allowed to invoke.

AgentCore Gateway can provide a managed boundary for tool access and authorization, helping separate the agent from the underlying systems it interacts with.

You Don't Need Every Component

A real agent doesn't necessarily need all of these services.

For example, a simple agent might only need:

Amazon Bedrock
      +
Agent Runtime
      +
A Few Tools

A more advanced application might add:

Knowledge Bases
      +
AgentCore Gateway
      +
AgentCore Memory
      +
Lambda
      +
DynamoDB
      +
Monitoring / Security

The architecture should therefore be designed around the actual capabilities the application needs, rather than adding AWS services simply because they are available.

From Concept to Architecture

We started with a simple idea:

“Build an AI that can plan a trip.”

We then decomposed it into capabilities:

Understand the goal
        ↓
Reason and plan
        ↓
Retrieve knowledge
        ↓
Use tools
        ↓
Execute actions
        ↓
Observe results
        ↓
Adapt
        ↓
Complete the goal

AWS provides building blocks for each part of this architecture.

And that's the key idea:

Agentic AI isn't one model or one AWS service. It is a system in which models, tools, knowledge, memory, and application infrastructure work together to pursue a goal.

AWS Implementation Architecture

                              USER
                                │
                                ▼
                     Web / Mobile Application
                                │
                                ▼
                       Application / API
                                │
                                ▼
                 Amazon Bedrock AgentCore Runtime
                                │
                                ▼
                       ┌────────────────┐
                       │   AI AGENT     │
                       │                │
                       │ Understand     │
                       │ Reason         │
                       │ Plan           │
                       │ Decide         │
                       └───────┬────────┘
                               │
             ┌─────────────────┼─────────────────┐
             │                 │                 │
             ▼                 ▼                 ▼
     Amazon Bedrock     Knowledge Bases    AgentCore Memory
     Foundation Model        │                 │
             │               │                 │
             └───────────────┼─────────────────┘
                             │
                             ▼
                    AgentCore Gateway
                             │
               ┌─────────────┼─────────────┐
               │             │             │
               ▼             ▼             ▼
          Hotel API      Flight API     AWS Lambda
                                           │
                                           ▼
                                      DynamoDB

The Agentic Loop

              ┌──────────────┐
              │     Goal     │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │    Reason    │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │     Act      │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │   Observe    │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │   Evaluate   │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │    Adapt?    │
              └───┬──────┬───┘
                  │      │
                 Yes     No
                  │      │
                  ↓      ↓
              Reason    Done
               Again

AWS Cheat Sheet

Amazon Bedrock
→ Foundation Models / Intelligence

AgentCore Runtime
→ Run the Agent

Knowledge Bases
→ Retrieve External Knowledge

AgentCore Gateway
→ Connect and Manage Tools

AWS Lambda
→ Execute Custom Logic

AgentCore Memory
→ Maintain Agent Context

Amazon DynamoDB
→ Store Application Data

The big picture:

LLM + Tools + Knowledge + Memory + Orchestration + Actions = Agentic AI System