DEV Community

Cover image for Building Scalable Context Layers for AI Agents with Elastic and AWS AgentCore
N Chandra Prakash Reddy for AWS Community Builders

Posted on Originally published at devopstour.hashnode.dev

Building Scalable Context Layers for AI Agents with Elastic and AWS AgentCore

I was at AWS Community Day Bengaluru recently on 11 July 2026 and the energy was simply fantastic. There were a lot of great presentations throughout the day, but one presentation really caught my eye. Someshwaran Mohan Kumar, presenting on “Building Scalable Context Layers for AI Agents with Elastic Agent Builder and AWS AgentCore”.

Let’s be honest, we’ve all had an experience with an AI chatbot that sounds very smart one minute and then can’t remember what we were talking about the next. Someshwaran tackled this same pain area. If you are designing AI apps, the principles covered in this webinar are absolute game changers!

So here’s my thorough evaluation of the session, and how we can finally give our AI bots long-term memory.

The Evolution of AI: We Are Beyond Simple Chatbots

To fix AI agents, we first need to understand how we got here. The discussion began with a very essential question: what exactly is a Large Language Model (LLM), and how is it different from an Agent? Someshwaran humorously describes our initial view of LLMs with the popular joke, merely typing away madly at a prompt.

But the landscape has changed quickly during the past few years:

  • 2022: We began by building simple wrappers around chatbots with simple APIs.

  • Early 2023: We went to prompt chains, employing tools to link a series of tasks together.

  • Mid 2023: We observed the emergence of tool-calling bots able to communicate with external functions.

  • 2024: Workflow engines added logic loops and human-in-the-loop judgments.

  • 2025 to 2026: We have officially reached the era of multi-agent systems in which specialized AI roles (e.g. Researchers, Writers, Reviewers) work over common states.

This evolution has been supported by extensive foundational research, on which the engineering community has depended. The emergence of Retrieval-Augmented Generation (RAG) for knowledge intensive tasks has been witnessed. We also learned about the “Lost in the Middle” phenomena, showing that LLMs suffer from a U-shaped performance curve – they recall the beginning and the end of a long prompt, but information in the center affects model performance dramatically. To alleviate these limitations, frameworks such as “ReAct” evolved, which combined reasoning traces with real actions in the environment.

The "Ghajini" Problem: Why Your AI Forgets You

Now this is when it gets fun. Even with complex models, we run across a huge obstacle when designing agents. Agents are stateless by default.

Someshwaran calls this the “Ghajini Problem” (or the Goldfish Problem). It's like dialing up your bank's customer service line. You talk for 10 minutes about your entire account history, your present problem, your preferences. The rep is helping you perfect yourself. But hang up and call back the next day and the new representative knows absolutely nothing. You have to start from scratch.

And this happens with AI bots every single time.

  • Session Starts: The user is shown the whole context, goals, preferences, and history.

  • Agent Responds: The agent works well, uses the context and offers value.

  • Session Ends: All is forgotten. The memory is wiped clean.

The bottom line. Users have to repeat themselves a lot. The agents never learn new preferences, there is no continuity at all and personalization is not possible. It is a problem of context and a problem of agent.

The Infrastructure Solution: AWS AgentCore

So how do we solve this? To build an effective agent, the two parts, the “Conversation Layer + Infra Layer” and the “Knowledge + Context Layer” must collaborate.

The presentation walked over building the base infrastructure using AWS AgentCore. This is the strong wrapper you need for your custom bot. AWS AgentCore enables you to make use of essential runtime resources such as Gateway for safe API routing, Identity management, Policy enforcement for guardrails, and Evaluations for quality tracking.

But the real magic is the fifth resource: Memory. AWS AgentCore introduces session summarizers, analyst preferences and insights natively. It also allows observability to measure memory events API requests, latency and faults.

Code Walkthrough: Building with Strands SDK

We then use the Strands SDK to actually construct this out. Someshwaran gave a good glimpse of how simple the entry point is for an agent developed on top of this architecture.

This is what the code looks like to spin up a memory aware agent:

# src/main.py - Agent Entrypoint

from strands import Agent
from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

@app.entrypoint
async def invoke(payload, context):
    agent = Agent(
        model = bedrock_model,
        tools = mcp_client.tools + es_tools,
        system_prompt = ANALYST_PROMPT,
        session_manager = memory_manager
    )

    response = agent(payload['query'])
    return { 'response': response }

Enter fullscreen mode Exit fullscreen mode

See the @app.entrypoint wrapper? This means your method is a handler compatible with AgentCore, where the memory manager is automatically injected before and after each conversational round.

The Context Solution: Elasticsearch

An agent needs to know the domain really well to be useful and AgentCore keeps track of the communication history. This is where Elasticsearch, the specific Context Layer, comes in.

You might be asking yourself “Is Elasticsearch and AgentCore Memory doing the same thing?” They are not competing; they are complementing. AgentCore Memory is for discussion only (episodic memory, summaries, user preferences). Elasticsearch is, alternatively, domain-centric (RAG over live operational data, hybrid search and semantic insight storage).

Together you obtain an agent that knows exactly what is happening in your business processes right now and remembers the user.

Bridging the Gap with MCP

But to be able to safely hook the agent into this huge pool of Elasticsearch data, we need a standardized means to communicate context. Enter MCP (Model Context Protocol).

Someshwaran explains hilariously accurately with a real-world comparison why MCP exists – comparing how outsiders save phone contacts vs. how Indians save contacts. A foreigner might just save a number as “Alex” or “Mark”. Meanwhile, the Indian contact list reads “Tina Airtel”, “Pappu Jio”, “Crush Airtel.” We naturally provide metadata and context to everything to make it easily searchable. MCP achieves just that for AI models . It fills the gap to standardize passing of information and tools across .

The Before and After: Code Simplification

The effect of MCP is huge for the developers. Let’s look at the difference Someshwaran presented.

Before MCP: You had to build brittle, hard-coded integration code. To simply look for a server error we had to manually configure the client, hardcode the index and build sophisticated JSON match queries.

# Before
from elasticsearch import Elasticsearch

es = Elasticsearch(
    "https://my-elastic.example.com",
    api_key="MY_API_KEY"
)

def search_logs(error_code: str):
    return es.search(
        index="weblogs-*",
        query={
            "match": {
                "status": error_code
            }
        }
    )

results = search_logs("500")
print(results)

Enter fullscreen mode Exit fullscreen mode

After MCP: The code is beautifully clean. You start the agent, you define the bedrock model, and you just pass mcp_client.tools. The Elastic MCP server offers tools (eg execute_esql or search_index) dynamically to the agent.

# After
from strands import Agent

agent = Agent(
    model=bedrock_model,
    tools=mcp_client.tools  # discovered from Elastic MCP server
)

response = agent("""
Find the top 5 countries generating 5xx errors this week
and show the trend over time.
""")

print(response)

Enter fullscreen mode Exit fullscreen mode

Instead of writing database queries you just ask the agent a natural language inquiry and it does the rest using the tools it dynamically discovered.

Architecture Deep Dive and Demo

The architecture makes sense when it’s assembled. The Strands Agent orchestrator takes a user request and coordinates LLM processing with Amazon Bedrock, historical context with AgentCore Memory, and tool access with the MCP Client. The MCP Client connects to Elastic Cloud Serverless securely to query live indices.

The live demo showed this architecture using an Elastic AI Agent UI. The user only asked “Describe what data I have available” and the agent took the autonomy to list the 8 indices present in the cluster, automatically categorizing them into CRM & Customer Data and Marketing Data.

Key Takeaways

So here's the bottom line on building your own context-aware AI agents:

  • Memory turns a stranger into a trusted partner: Think of going to your favorite neighborhood coffee shop every morning. When the waitress remembers you enjoy an oat milk latte with no sugar, you immediately feel loved. Without memory, your agent is like a stranger who forgets your face the second you walk out the door. AWS AgentCore gives your AI a friendly memory of user preferences and interaction history, spanning sessions.

  • Context works best as a team effort: Don't ask one database to do everything. Think about ordering dinner on an app like Swiggy. AgentCore is like a saved profile, it remembers your dietary preferences and previous orders. Elasticsearch is the restaurant kitchen and delivery fleet – it’s keeping tabs on what ingredients are in stock, current order status and road conditions right now. Together, they ensure sure the user always gets the proper result.

  • Standardize how your tools connect: Remember when every phone brand had a separate charging pin and you required a drawer full of adapters? It used to be as messy connecting tools to AI bots. The Model Context Protocol (MCP) is an universal USB-C cable. Your agent can plug directly into Elasticsearch tools, no hard-coded bespoke code needed.

  • If you are building a startup: Now you can deploy customer care agents that remember earlier discussions, no more users needing to re-explain their concerns from scratch.

  • For engineering and operations teams: You can deploy internal AI assistants who automatically analyze live production logs, and troubleshoot faults, saving your team hours of manual querying.

Conclusion

By the conclusion of the day, this seminar changed how I think about modern AI architecture entirely. We’re finally out of the era of stateless, forgetful chatbots, and into the age where software can actually remember who we are, and grasp what’s occurring in our systems in real time.

Constructing a memory-aware AI was once thought of as a hard problem, accessible only to specific research labs. But as Someshwaran has showed with AWS AgentCore and the Strands SDK, the infrastructure is already in place to handle the heavy lifting for us. Combining conversational memory with the instant search capabilities of Elasticsearch allows us to create AI applications that give true compounding value over time.

If you want to roll up your sleeves and get your hands dirty with these architecture patterns, check out the resources over at elastic.co/search-labs. The tools are there – it’s our turn to construct!

About the Author

As an AWS Community Builder, I enjoy sharing the things I've learned through my own experiences and events, and I like to help others on their path. If you found this helpful or have any questions, don't hesitate to get in touch! 🚀

🔗 Connect with me on LinkedIn

References

Event: AWS Community Day Bengaluru

Speaker: Someshwaran Mohan Kumar

Topic: Building Scalable Context Layers for AI Agents with Elastic and AWS AgentCore

Date: July 11, 2026

Also Published On

AWS Builder Center

Hashnode

Top comments (0)