[Presentation Report] At AWS Summit Japan 2026 Builder Community Lounge, I gave a chalk talk titled "Do You Really Need All of AgentCore's Features? Let's Sort Out How to Combine AWS Services Based on Your Use Case Together"

Hello, I'm Jinno from the consulting division, and I'm a huge fan of Amazon Bedrock AgentCore.

This time, I had the opportunity to speak at AWS Summit Japan 2026's Builder Community Lounge in a chalk talk format!
I was genuinely surprised and thrilled that I would ever get to present at Summit.

A chalk talk is a style where instead of one-sidedly showing slides, you organize ideas on a whiteboard while having a dialogue with the audience. Chalk talks are a common format at re:Invent, but I rarely see this format done in Japan, and it was my first time doing it myself, so I was quite nervous going up on stage wondering if it would be okay...!

I was nervous and have some fuzzy memories of parts of the exchange, so if there's anything you're curious about, please feel free to reach out via X...!
I'll add updates right away!

Presentation Materials

Here are the presentation materials.

Content

For this chalk talk, rather than carefully introducing AgentCore's features one by one, I wanted to have a discussion about which features to adopt based on use cases and what kind of design would be best, so I proceeded with the following flow.

My goal was for attendees to "get hints about how they would implement things themselves"!

Ice Breaker

At the start, I asked a few questions by show of hands as an ice breaker!

I asked in stages: "I've mastered AgentCore!", "I've tried it!", and "I'm interested!" — and as expected, no one claimed to have mastered it, with most people having either tried it or being interested in it...! It's great that people want to learn more!
I hope today's talk will inspire some future masters!

I also asked "Is there anything about AgentCore you'd like to know about?", and someone timely spoke up saying "I'm curious about how to use Gateway." That fits perfectly with today's theme.

From here, I gave a rough overview of AgentCore.

A Rough Overview of AgentCore

To reiterate, Amazon Bedrock AgentCore is a managed service optimized for deploying and operating AI agents. It eliminates infrastructure management and provides an environment where developers can focus on building agent logic.

With Runtime as the foundation, the features span a wide range.

Wow, there are a ton of features...!! But you don't need to use all of them!
You can just use what you need, and for something as simple as an Agentic RAG that answers Q&A based on knowledge, Runtime, Memory, Identity, and Observability are sufficient.

The image is that you start with Runtime and add what you need from there. Amplify is convenient for hosting the frontend, and you can quickly create screens with authentication by leveraging Cognito, which is great.

I recently wrote a blog post about implementing something with a similar configuration, so please refer to that as well. There's also a demo, so I think it will help you get a concrete image.

https://dev.classmethod.jp/articles/gemma4-s3vectors-agentcore-rag/

AgentCore Gateway, which also came up as a question, is a service that converts existing APIs, Lambda functions, MCP Servers, and various services into MCP-compatible tools so that AI agents can easily call them.

There are cases where you can call tools directly from Runtime, but Gateway is effective when you want to share tools across multiple agents, centrally manage authentication and authorization for external connections, or search for the right tool from a large number of tools. The ability to automatically select the appropriate tool through semantic search is also a nice bonus.

I think there may be parts that are hard to grasp from this alone, so I've summarized the benefits of Gateway and more in the material below — please refer to it as needed if you're interested. (Around pages 94 to 105)

https://dev.classmethod.jp/articles/amazon-bedrock-agentcore-2025-summary/

After briefly explaining AgentCore, it was finally time to hear about use cases and move forward with architecture design.

Gathering Use Cases

Before getting into the feature explanations, I asked everyone to share what AI agents they "want to build or are curious about."

The three use cases gathered through raised hands and on-the-spot comments were as follows.

• English conversation learning AI agent
  • This was a use case triggered by someone mentioning they study English regularly. It supports user inquiries and English learning. The image is something that reminds you of questions you got wrong when you've forgotten them, and kindly teaches you about your habits.
• AI agent utilizing smart glasses
• Meal planning management AI agent

From these, we chose the English conversation learning AI agent and worked together to organize the architecture. (If nothing had come up, it would have become an AI agent that researches supermarkets, which I love.)

Everyone Thinks About the Design of the English Conversation Learning Agent

We broke down and organized the use case along four axes: "purpose," "users," "external connections," and "constraints."
This is just one example, but when actually designing an architecture, organizing things this way — starting with the use case, then thinking about users and constraints — might make it easier to break things down into a design.

We roughly organized the requirements for the English conversation learning agent on the spot from the slide's perspectives.

• Since it accepts a wide variety of questions to support English conversation learning, user interaction is necessary
• For this session, we're not going deep into role-based business permissions. However, user identification and memory isolation are required
• Tools are DB and RAG
  • DB is for data associated with business logic, metadata, user feedback data, etc.
  • RAG is knowledge for the AI agent to retrieve and improve appropriate responses and experiences in English conversation learning
    • Things like the company's own learning content and frequently asked questions
• Memory management per user
  • This is something we want to guarantee at a minimum. Designing so that long-term memories don't mix, and of course, making sure one person's memories don't mix with another's.
• Cost management
  • Since the image is many users using it a lot, we want to avoid it being too expensive.

As I got overwhelmed trying to converse while writing, I asked Fukuchi-san (@har1101mony) to take over writing on the whiteboard!!

I'm so grateful that they wrote things down in real time...!! While reflecting on my own poor coordination, thanks to them I was able to focus on the discussion.

This case involved a wide range of users, but for a closed application like internal information search, you'd also separately need things like a closed network and permission management. There are also cases of integrating with external SaaS to retrieve information or trigger some kind of action, depending on the use case.

The Completed Architecture

As a result of organizing everything, the following architecture was created.

When organized, the configuration looks like this.

• Frontend: Amplify (Web UI) + Cognito to quickly provide an authenticated chat interface

  • A native app would also be fine, but for clarity, we went with web this time...

• Backend: API Gateway + Lambda to receive requests

  • Business logic not implemented in the frontend and AgentCore goes here
    • Interactions with the Database are handled here
    • It's not that you can't implement it with AgentCore, but since it's a place to write AI agent logic, I'm conscious of the separation of responsibilities
    • For example, feedback collection logic and metadata management. Feedback is for AI responses.

• AI agent: Hosted on AgentCore Runtime

  • Though not brought up in the discussion, the image is implementing with Strands Agents. Using Agent Loop to recursively retrieve knowledge and create good answers.

• Guardrails: Controls inappropriate inputs and outputs

  • Since it accepts input from unspecified users, configure it to reject conversations unrelated to English conversation learning and exclude inappropriate content

• Memory: AgentCore Memory manages conversation history per user

  • Using a User Preference strategy to remember user preferences and an Episodic Memory strategy to remember the AI agent's successful experiences would likely improve the user experience further.

• RAG: Knowledge Bases + S3 Vectors for searching English learning material data

  • OpenSearch and Managed Knowledge Base are also viable options, but we chose S3 Vectors for the large volume of data and the desire to operate at low cost.

• DB: Manages data such as learning progress, metadata, and feedback information

• Not shown here, but to implement a reminder feature, it would also be good to use something like EventBridge to run periodic batch-like processes that prompt reviews. Things like questions answered incorrectly, content groups targeting areas the user struggles with. You could simply execute an LLM in Lambda and create it in a one-shot, or make it Agentic with a process of create → review → improve, which also sounds interesting.

• The Gateway shown in the diagram came up in a later question, so please skip over it for now

It's interesting how, by judging one by one which AWS services to adopt and which AgentCore features to use based on requirements, the configuration becomes organized. The above is not the definitive answer, just one example. (Of course, it was improvised so it's not perfect, and this isn't necessarily the best approach — there may be better options — but this is just what we came up with in this chalk talk...)

How to Organize Use Cases

In the latter half of the chalk talk, I shared some tips for enabling anyone to do this kind of organization.
This too is just one example, and it will vary depending on your company's policies and priorities. However, I think being able to articulate your own decision criteria will make architecture design easier.

(As you organize requirements, you might sometimes find yourself thinking, "Do we actually even need an AI Agent...?" — it's important to think through scenarios and use things appropriately.)

Also, as mentioned in point 7, AI agents aren't something you just build and leave alone, so it's very important to use features like Observability, Evaluations, and Optimization for continuous analysis and improvement. Let's start small and expand for the better!

Q&A

After the discussion, we had about 8 minutes left for a Q&A session. I'll write down the exchanges here as best I can remember...!!

• Q. You can easily create AI agents with Harness, but what's the distinction between that and implementing from scratch with Runtime? How should you decide?

  • A. First, it's best to try Harness and see if it covers your needs. There may be cases where it doesn't quite hit the mark, and in those cases, you implement it yourself. These days, coding AI agents like Claude Code and Codex are becoming prevalent, so leveraging those tools means implementation may not be that difficult.

• Q. The interface this time was from the frontend, but if you want to call RAG from a coding AI agent like Claude Code and reference it — for example, internal documents — how would you do that?

  • A. Building the RAG itself is necessary either way — the image is just that the interface entry point is different. You could implement the RAG Retrieve process on the Lambda or Runtime side and expose it as an MCP tool via Gateway. The image is that there's a frontend access path for general users and an MCP access path for coding AI agents, respectively. IAM access is also fine, and for Claude Code or Coworker, you could add authentication to Gateway and distribute it to the organization via a connector. The tricky part with IAM is what to do about non-engineers...

• Q. When using a search tool, is it necessary to use an external MCP tool like Tavily?

  • A. Recently, a Web Search Tool that can be natively linked to Gateway has been released. However, as of June 2026, it only supports us-east-1, and the search quality for Japanese-language pages was inconsistent, so if you're primarily working in Japanese, my impression is that using Tavily or Brave Search is the more practical choice.

Closing

AgentCore does not require you to use all of its features — rather, it provides a rich set of options to combine based on your use case and constraints. By carefully thinking about which requirements to fulfill with AgentCore features and which to handle with existing AWS services, it becomes easier to choose a configuration that fits your specific case. Again, it's important to organize your use cases and constraints first, rather than starting with the tools.

AgentCore has many features, but it's perfectly fine to start by building an AI agent with Harness or Runtime, and then add features from there. I think experiencing the power of a small AI agent firsthand makes it easier to feel the possibilities of what it could be used for. We also have a Harness hands-on available, so please give it a try as needed!

https://dev.classmethod.jp/articles/amazon-bedrock-agentcore-managed-harness-handson/

Also, I'd like to once again express my deep gratitude to Fukuchi-san (@har1101mony), who took over the whiteboard writing partway through...!! Thanks to their real-time organization of the discussion content, I think we were able to convey things clearly to the participants! (Honestly, I would have panicked trying to do that myself, so I think it was incredibly impressive how cleanly they organized everything...!!)

And to everyone who asked questions and proposed use cases — thank you so much!! This chalk talk format only works because of everyone's voices, so I was really happy that you all participated so actively!

I hope today's discussion served as a hint for everyone's AI agent design!

I hope this article was helpful in some way. Thank you so much for reading to the end!