Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Agentic Generative AI architecture opinions

-3

Hello,

Could you please give some opinions about this AWS Cloud architecture : Agentic Generative AI with custom data ?

If you need to see the output, the applications are available here: museums, weather.
The MCP Server is a Proof of Concept built in Python that runs in Amazon Bedrock AgentCore Runtime, and the MCP Client is Kiro IDE.

Thank you,

Topics
Machine Learning & AIGenerative AI on AWS
Tags
Amazon BedrockAmazon Bedrock AgentCore
Language
English

asked 5 months ago295 views

2 Answers
0

Your architecture demonstrates a solid implementation of agentic AI patterns using AWS services. Here are some key observations and considerations:

Strengths of Your Approach:

Your use of Amazon Bedrock AgentCore Gateway as an MCP server is an excellent architectural choice. This approach allows you to expose existing APIs as MCP-compatible tools without modifying your source code, which is particularly valuable for modernizing applications. By wrapping your custom data APIs in an MCP server, you've created a reusable integration layer that can be shared across multiple agents, eliminating duplication.

Using Kiro IDE as your MCP client provides a good development environment for building and testing your agentic workflows. The combination of AgentCore Gateway with Kiro enables rapid experimentation and iteration on your AI workloads.

Architectural Considerations:

For production deployments, consider implementing several key components:

  1. Authentication and Security: Implement proper authentication mechanisms to control access to your agents and tools. Amazon Cognito is commonly used for this purpose in agentic architectures.

  2. Memory Management: For more sophisticated agentic systems, consider implementing a dedicated memory service. This would provide centralized management of both short-term (session) and long-term memory, allowing memory to be shared and reused across different agents and interactions for more coherent experiences. Amazon DynamoDB and Amazon S3 can support this capability.

  3. Observability: Given the non-deterministic behavior of LLMs, implementing comprehensive observability is crucial. You'll want to capture logs, metrics, and especially traces to understand the path taken to reach each response. This helps with debugging and quality assurance.

  4. API Gateway: Consider implementing an AI gateway as a unified entry point. This would provide centralized governance, security, authentication management, dynamic load balancing, quota management, and cost control across your agentic applications.

  5. Documentation Quality: Ensure your OpenAPI specifications are well-documented, as the documentation becomes the tool description that your AI agent uses when deciding which tools to invoke. Better documentation leads to more accurate tool selection and efficient request handling.

Scalability and Cost Optimization:

As you move toward production, develop a detailed cost model that accounts for query volume, token usage, and infrastructure costs. Consider implementing caching strategies and right-sized models to optimize both performance and cost.

Your proof-of-concept demonstrates the art of the possible for introducing AI capabilities into applications, and with these production-ready enhancements, you'll have a robust foundation for scaling your agentic AI implementation.
Sources
Architecting for agentic AI development on AWS | AWS Architecture Blog
Architecting generative AI applications for production - AWS Prescriptive Guidance
re:Invent 2025 - Generative and Agentic AI on Amazon EKS | AWS re:Post
Modernize your applications using Amazon Bedrock AgentCore Gateway and Kiro powers | Migration & Modernization

answered 5 months ago

-1
Accepted Answer

The architecture pattern is solid and reflects where enterprise agentic AI is heading in 2026. A few observations:

What's well-designed

Running the MCP Server in Bedrock AgentCore Runtime is the right call for a production POC. AgentCore handles the container lifecycle, scaling, and IAM integration — things you'd otherwise build manually if you ran the MCP server on ECS or Lambda. For a custom data use case this matters because the server needs persistent tool availability without cold-start penalties on every agent invocation.

Using Kiro IDE as the MCP client is an interesting choice — it keeps the client-side lightweight and lets you iterate on the agent behaviour without redeploying the server. That separation of concerns is good architecture.

Considerations for moving beyond POC

For the custom data layer, the main question is whether your data access pattern is better served by RAG (retrieval at query time via Knowledge Bases) or direct tool calls to a structured data source. The museums and weather demos suggest structured/API-backed data, which suits direct MCP tools well. If the data grows to unstructured documents, adding a Bedrock Knowledge Base as a backing store for one of your tools is a natural extension.

For production, add Bedrock Guardrails to the AgentCore runtime to handle any user-facing safety requirements — especially relevant if the agent has write access to any data source.

One question worth validating: How are you handling MCP server authentication between Kiro and AgentCore? Bearer tokens via Secrets Manager is the cleanest pattern here if you haven't landed on one yet.

Overall this is a clean, modern stack. The AgentCore + MCP pattern will become more common as MCP adoption grows across IDEs and clients.

answered 5 months ago

  • rePost-User-4717319
    5 months ago

    Thank you very much for your answer,
    It was extremely easy to build MCP Server using Bedrock AgentCore Runtime: I had to build only a Python file with the tools. Because it is about a POC, authentication was done using AWS credentials. Please see below the mcpServer from Kiro's mcp.json:

        "mike-agentcore": {
      "command": "uvx",
      "args": ["mcp-proxy-for-aws@latest",
        "<bedrock-agentcore_runtime_URL>",
        "--metadata", "AWS_REGION=us-west-2"
      ],
      "env": {
        "AWS_ACCESS_KEY_ID": "<KEY>",
        "AWS_SECRET_ACCESS_KEY": "<SECRET>",
        "AWS_REGION": "us-west-2"
      },
      "disabled": false
    }
  • meghana rajagopal
    5 months ago

    Thanks for sharing the config — that's a clean setup. mcp-proxy-for-aws as a uvx tool is a nice lightweight approach for connecting Kiro to AgentCore without any custom client code.

    One note for when you move beyond POC: hardcoding AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in mcp.json is a security risk if that file gets committed to a repo. For production, swap to an IAM role with an instance profile or use AWS SSO credentials — that way no long-term keys are stored anywhere in the config.

    Great work on the build — the AgentCore + Kiro + MCP pattern is one of the cleaner agentic architectures I've seen recently. If the answer was helpful, an upvote would be much appreciated and helps others in the community find it more easily. If my answer was helpful, I would appreciate it if you could mark it as the accepted answer. 🙌

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content