Himanshu Sangshetti
AI Engineer @ Mem0
Pune, India
Actions
Himanshu Sangshetti is an AI Engineer at Mem0 and the Founder of CloudFluently.
He actively speaks on AI, Cloud, DevOps and has delivered 30+ talks and workshops across global communities, including AWS Community Day Taiwan 2025, AWS Community Gatherings Japan 2025, AWS Amarathon China 2024, HashiTalks 2026, among others.
He is the Organizer of the Build Club AI Community in Pune, India, which has grown to 1k+ members. Previously, he was selected as an AWS Cloud Captain (one of 87 worldwide) and led a student cloud community that scaled to 4k+ members, becoming the largest in India.
At Mem0 (OSS - 50k+ stars), he works on building a memory layer for AI agents and harness
He also founded CloudFluently, a free cloud learning platform with 10k+ active learners, offering 20+ courses and 150+ blogs spanning 10+ cloud certifications. CloudFluently has been officially selected in AWS Activate for Startups and the Google for Startups Cloud Program.
Links
Area of Expertise
Topics
Prevent Memory Poisoning: Agent Memory as an attack surface
Prompt injection dies with the session. A poisoned memory doesn't - it persists, and the consolidation step meant to clean your memory is what makes it dangerous.
When an injected claim passes through extraction and consolidation, it's merged with legitimate facts, promoted from episodic to semantic, and stripped of provenance. The system now serves it as trusted context- to any user, on any future task.
The more sophisticated the memory pipeline, the more effectively it launders the attack. OWASP formalized this as ASI06 in 2026; MINJA reports over 95% injection success against production agents; Agent Security Bench shows current defenses stopping barely 16%.
The talk is how you make memory poison-resistant without crippling it.
- Provenance on every write
- Trust-aware retrieval that weights sources
- A verify-before-promote gate
- Write-path sanitization that strips injected instructions before they're ever stored
- Behavioral drift detection
- And strict per-user scoping that kills the cross-user blast radius
You'll leave with a concrete checklist for hardening agent memory- which layers to add, in what order, and where each one still falls short
Memory is not just markdown files or vectors, memory is an infrastructure layer of an agent harness
Make Your Agent Harness Self-Evolving with Persistent Memory
Your agent keeps repeating the same mistakes. Ship it, and its behavior is frozen- every improvement has to come from you.
Retraining is the usual fix: slow, costly, and overkill for "remember what worked last time."
In 2026 a cheaper path took over: let the agent rewrite its own persistent memory between runs, so it improves at test time- no fine-tuning, no retraining. Huawei shipped a self-evolving memory engine on 1 July; EvolveMem beat the strongest baseline by 25.7% on LoCoMo; ICLR gave it a workshop. Sleep-time consolidation reaches the same accuracy with ~5x less compute.
In this lab you take a plain agent harness and make it self-evolving, from primitives:
- Extract → store → retrieve: the persistent memory base
- The evolve step: turn a failed run into a lesson the agent recalls next time
- A live checkpoint: your agent fails a task, consolidates what went wrong, and passes on the retry
- The failure mode, watch it mislearn: reinforce a bad heuristic, drift sycophantic
- The guardrails that make it converge instead of rot
Leave with a self-evolving agent harness you can drop into your own stack. The talk would be harness agnostic- can adapt it for any of the personal harness to make sure every user is adapting their workflow into a self evolving one
Stop Stranding Your GPUs with HAMi and Volcano on Kubernetes
The most expensive hardware in your cluster is also the most wasted. A pod asks for a whole GPU, uses 20% of it, and holds the rest hostage. Across a fleet, most teams strand 60 to 70% of their accelerator capacity.
Kubernetes treats a GPU as one indivisible unit by default. Three things change that:
- HAMi (CNCF) slices a physical GPU by memory and compute so many workloads share one card;
- Volcano adds gang scheduling and queue fairness so distributed jobs and teams coexist;
- and Dynamic Resource Allocation, GA since 2025, makes fine-grained, topology-aware assignment native to Kubernetes.
This session shows how to share and schedule accelerators in production: fractional GPUs, gang scheduling, fair queues, and how the same approach handles heterogeneous chips beyond NVIDIA. We'll walk real utilization numbers before and after.
You'll leave able to run more workloads on the GPUs you already pay for.
State-of-the-Art Autonomous Agent Architectures: Design Patterns and Production Lessons
Autonomous agents are evolving into persistent, goal-oriented systems that reason, plan, coordinate, and operate under real-world constraints.
But agents fail for architectural reasons- not model limitations.
This session examines the design patterns behind modern autonomous agent systems, from single-agent loops to coordinated multi-agent architectures.
We will explore:
- ReAct-style reasoning–acting loops and their limitations
- Planning–execution–reflection architectures
- Manager–worker and hierarchical agent patterns
- State machine workflows (LangGraph-style architectures)
- Memory systems: working, episodic, and semantic integration
- Tool orchestration and learned tool selection
- Constraint-aware optimization across latency, cost, and token budgets
Rather than focusing on a single framework, this talk synthesizes architectural principles emerging across research and production systems including neuro-symbolic multi-agent approaches, reflection-based improvement loops, and resource-constrained coordination strategies.
We will examine architectural trade-offs between specialization and coordination overhead, autonomy and constraint enforcement, and simplicity versus hierarchical decomposition.
This session is for engineers building complex agent workflows, multi-agent systems, or long-running autonomous processes.
___
Supporting Link:
1. https://medium.com/@himanshusangshetty/state-of-the-art-autonomous-agent-architecture-design-patterns-and-best-practices-f456addd9f07
Stateless MCP: Inside the 2026 Transport Spec
Most MCP servers in production today are stateful- each client session is pinned to one server instance.
That works on a single node. Add a load balancer and scale horizontally, and sessions start breaking: Kubernetes routes a request to the wrong pod, a Fargate deployment rolls and drops active connections, and NGINX or AWS ALB need special configuration just to keep the server reachable.
The 2026 spec release candidate, locked May 21, fixes this at the transport layer through three SEPs.
- SEP-1442 removes the mandatory init handshake so negotiation folds into the first request.
- SEP-2322 makes elicitation stateless.
- SEP-2243 mirrors routing data into HTTP headers so load balancers can route without parsing the payload.
This session covers what each SEP changes, what breaks in the server you run today, and what to refactor before the spec ships. I'll also show how we externalize session state at Mem0, so a stateless server keeps the memory and context a real agent needs.
You'll leave with a migration checklist and an architecture for stateless-first MCP.
Reachability-Aware Autonomous SOC: AI-Driven SBOM and CVE Remediation on Cloud Native Pipelines
In modern cloud native delivery, the speed of shipping outpaces the speed of security.
Vulnerability scanners produce thousands of CVEs against every release; engineering teams ignore most of them; and the ones that actually matter slip through.
The fundamental problem is not detection, it is decision and remediation at machine speed.
In this session, Himanshu walks through how to build a reachability-aware autonomous Security Operations Center directly into Kubernetes-native CI/CD pipelines. AI agents consume SBOMs and CVE feeds generated with Trivy, score vulnerabilities through reachability analysis (does this CVE actually touch a live code path?), and propose patches as policy-gated pull requests via Kyverno, OPA, and Argo CD. Falco and Tetragon provide runtime signals back to the agent loop, closing the cycle from runtime evidence to source-tree fix.
The talk covers the closed-loop architecture, the failure modes real teams hit.
I Gave My CVE Backlog to an Agent: Reachability, VEX, and Agentic Triage
Your scanner finds 400 CVEs in a container image. A handful are actually exploitable. The rest is noise your team patches anyway.
So I gave that backlog to my AI agent. Working from a Trivy scan, it:
1. reads the reachability graph onto which vulnerable functions your code actually calls
2. decides what's genuinely exploitable
3. writes the verdict as OpenVEX, signed and attested with in-toto and Sigstore
This talk is the honest report: what the agent got right, what it got dangerously wrong, and the human-in-the-loop design that keeps a confident LLM from waving through a live CVE.
We'll build the full pipeline on Kubernetes: Trivy scan, reachability, agentic triage, OpenVEX, in-toto/Sigstore signing, and a deployment gate with real before/after numbers on the noise it removes.
You'll leave with a pattern for cutting CVE noise with reachability and VEX, and a clear-eyed view of where an agent belongs in security work and where it absolutely does not.
Context Engineering for Production AI Agents
Context engineering is emerging as the core systems layer in production AI agents.
In multi-step agents with tool calls, token growth is exponential. Without deliberate context control, agents degrade over time through context rot, window overflow, or compaction loss.
The companies building the most capable AI agents today: Manus, Cursor, Anthropic AI, OpenAI, Google DeepMind, LangChain are all solving the same problem: what information should an LLM see, when should it see it, and how should it be structured?
This session covers the invisible layer that makes or breaks production:
- Context window lifecycle management
- In-loop retrieval vs static RAG
- Logit masking and MCP tool gating strategies
- Memory compaction and state consolidation
- Multi-agent context isolation
- Cost-performance trade-offs in long-running trajectories
We will also examine a comparative analysis of how leading AI teams from Manus, OpenAI, Cursor etc. approach these design decisions where their strategies converge, where they conflict, and what practical lessons emerge.
___
Supporting Links:
1. How Top AI Companies Handle Context Engineering- https://x.com/Hxlfed14/status/2022984467380682856
2. Advanced Context Engineering Techniques: A Technical Deep Dive- https://medium.com/@himanshusangshetty/advanced-context-engineering-techniques-a-technical-deep-dive-b997e74cab92
Auditing the MCP Supply Chain
Every MCP server you install pulls in a supply chain you don't see: the npm or PyPI packages it depends on, the registry you fetched it from, and the official SDK it's built on.
Most teams never audit any of it. In 2026 that gap turned into real incidents.
- The postmark-mcp package silently BCC'd emails from 300+ organizations
- The Smithery registry breach exposed credentials for 3,243 hosted MCP apps through a single path traversal
- A design flaw in the official MCP SDKs allowed command execution over the STDIO transport, across 150 million downloads.
OWASP now lists supply chain as its own entry, MCP04, separate from tool poisoning and prompt injection.
This talk maps the MCP supply chain attack surface across its three layers: package, registry, and SDK and shows how to audit each one.
We'll cover what SBOM tooling catches, where it falls short on MCP specifically, and what a practical defense stack looks like in production.
You'll leave knowing how to audit an MCP server before you trust it.
Amazon S3 Vectors vs OpenSearch for RAG: A Production Comparison
Amazon S3 Vectors launched at re:Invent 2025 as a new way to store and query vector embeddings with familiar S3 economics.
But if you're already running OpenSearch for vector search in production, the question is practical: should you migrate, run both, or stay put?
We run OpenSearch-based vector retrieval in a production RAG pipeline. When S3 Vectors launched, we loaded the same dataset into both services and benchmarked them head-to-head: ingestion speed, query latency at p50/p95/p99, cost per million queries, and filtering capabilities.
This lightning talk walks through those results, where each service wins and where it falls short, and closes with a decision flowchart you can apply to your own RAG pipeline. We'll also share a practical pattern for using both services together rather than choosing one.
If you're building RAG on AWS and trying to decide between these two, this talk gives you the numbers so you don't have to run the benchmarks yourself.
Scaling LLM Inference on Kubernetes with KV-Cache-Aware Routing
Every token an LLM generates depends on the KV cache- the model's running memory of the request so far.
Manage it well and inference is fast and cheap. Manage it badly and you recompute the same prefixes over and over, burning GPU you never needed. This session treats the KV cache as the thing that actually governs LLM inference performance on Kubernetes.
We serve models on KServe (now a CNCF project), then go where the speed and savings are:
1. prefix caching in vLLM- reuse the cache within a worker
2. KV-cache-aware routing with llm-d- send a request to the worker that already holds its prefix instead of recomputing it
3. prefill/decode disaggregation- split the two phases across GPU pools and move the cache between them
We'll walk real before/after numbers on throughput, time-to-first-token, and GPU cost.
You'll leave knowing why the KV cache is your inference bottleneck, and the Kubernetes-native patterns that fix it.
From IaC to IaL (Infrastructure as Lifecycle) using Terraform Stacks
For years, Infrastructure as Code (IaC) has been the foundation of modern DevOps.
But as systems grow more distributed and multi-environment, maintaining consistent lifecycles across “Dev → Stage → Prod” becomes a challenge. Enter Infrastructure as Lifecycle (IaL), a natural evolution of IaC, powered by Terraform Stacks.
In this session, we’ll explore how Terraform Stacks redefines the way infrastructure is managed, promoted, and governed across multiple environments. We’ll walk through the journey from traditional IaC to a lifecycle-driven model that embraces composability, dependency mapping, policy enforcement, and environment promotions- all natively supported in HCP Terraform.
You’ll see how Terraform Stacks allows platform teams to structure their configurations into modular, interdependent components- enabling automation of Day 2 operations, versioned environment pipelines, and golden-path provisioning.
We’ll also discuss real-world patterns for migration, policy integration with Sentinel, and lifecycle management best practices.
This talk will help you move beyond static configuration management and adopt a lifecycle-first mindset, one that scales securely and sustainably with your organization.
A2A + MCP: Building Self-Orchestrating Multi-Agent Workflows on AWS Serverless
Give a single AI agent 30+ tools and watch its accuracy drop to 48%. The answer isn't a smarter model- it's specialized agents that coordinate.
Multiagent systems is where things get real.
This session combines two open protocols- Google's Agent-to-Agent (A2A) for inter-agent communication and Anthropic's Model Context Protocol (MCP) for tool access to build multi-agent workflows on AWS serverless.
We'll build a system where specialized agents discover each other via A2A, invoke tools through MCP servers, and orchestrate on Lambda, Step Functions, and Bedrock. No long-running servers.
What we'll cover:
- Deploying MCP servers on Lambda and zero-code via AgentCore Gateway
- A2A agent discovery and task delegation
- Step Functions for parallel agent invocation with retries and timeouts
- Strands Agents SDK; open source by AWS
- Sharp edges: cold start compounding, tool selection accuracy, context window limits
- When multi-agent makes sense vs when a single agent is enough
Includes a live demo, protocols, architecture, and code.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top