On stage

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

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

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.

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

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 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

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.