GSoC 2026 Introduction: Adarsh Kumar — AI/ML Engineer, IIT Patna

[adarshkumar23]

Hi everyone! 👋

I'm Adarsh Kumar, a BSc CSDA student at IIT Patna and an AI/ML Engineer with production experience. I'm very interested in the Mesa-LLM stabilization project for GSoC 2026.

About Me

• Professional Experience: Progressed from ML Intern → ML Engineer at ValersAI, building and deploying production ML models using BERT, GPT-2, and LLMs on AWS
• Core Skills: Python, PyTorch, TensorFlow, LLM APIs (OpenAI, HuggingFace), async programming, Flask, Node.js, React
• Current Project: Building a personal AI assistant (end-to-end: LLM integration, API design, deployment)
• Certifications: IBM Java Developer Professional Certificate, Meta Python, Michigan Writing & Editing (Coursera)

My Contributions So Far

• ✅ PR fix: handle non-LLM agents in speak_to to prevent AttributeError (#158) #229 — Fixed speak_to crashing with AttributeError when recipients are non-LLM agents (issue speak_to tool call crashes with AttributeError when recipients are non-LLM agents #158). Added safe getattr check and fixed variable shadowing in the return statement.

What I'm Working On Next

• Investigating issue send_message/asend_message store Agent objects in memory content causing JSON serialization errors #156 (JSON serialization errors in send_message when Agent objects are stored in memory)
• Planning to build a small example model (LLM-powered debate/negotiation simulation) to identify API friction points — as suggested in the GSoC getting started guide
• Reading through the architecture discussions ([Architecture RFC] Resolving Step Latency and Implementing the "Pending" Embedding Retrieval in Memory Modules #190 on step latency, Model hallucinations and guardrails #174 on hallucination guardrails)

Why Mesa-LLM Excites Me

My production experience with LLMs has taught me that the gap between "LLM demo" and "LLM in production" is enormous — handling API latency, memory management, context window optimization, and graceful degradation are all hard problems. Mesa-LLM sits exactly at this intersection, and I'd love to help make it production-ready.

I'm particularly interested in:

1. Stabilizing the memory system (issues STLTMemory loses popped memories instead of consolidating them into long-term memory #107, EpisodicMemory: Graded entries are never stored, as a result LLM never receives memory context #108, Memory staging area overwrites concurrent events of same type (leads to Data Loss) #137)
2. Preparing for Mesa 4.0 compatibility (fix: codebase incompatible with Mesa 4.x (mesa.space removed) #152)
3. Building scientific example models that showcase LLM agents vs traditional agents

Questions for Mentors

• For the memory bugs (EpisodicMemory: Graded entries are never stored, as a result LLM never receives memory context #108 EpisodicMemory, STLTMemory loses popped memories instead of consolidating them into long-term memory #107 STLTMemory) — would you prefer fixes that maintain backward compatibility, or is this a good opportunity to refactor the memory API?
• What's the preferred testing approach for LLM-dependent code? Mock LLM responses, or use a lightweight local model via Ollama?
• Are there specific scientific papers you'd like to see replicated as mesa-llm examples?

Looking forward to contributing more!

GitHub: https://github.com/adarshkumar23
PR #229: #229