Monica R
Software Development Engineer @ Autodesk - Speaks AI, Tech & Careers
Bengaluru, India
Actions
I speak AI, Tech, Open Source & Career Development. Bring my professional experience as an SDE to advise and give insights on the current tech market.
International speaker having invited for global AI-Native Workplace Summit and GDSC workshop.
Selected as Open Source Contributor and Ambassador at city (Bengaluru) for GSSoC'26.
Past community experiences, leadership and talks at: Microsoft Learn Student Ambassadors, Google Developer Student Club, Computer Society of India, Newton School Club
Area of Expertise
Topics
Your Next Teammate Won’t Be Human: Inside the Rise of Digital Workers
The workplace is changing faster than ever. AI is no longer just assisting employees, it is beginning to operate like a digital coworker capable of summarizing meetings, managing tasks, generating reports, handling communication, and supporting decision-making.
This session explores the rise of Digital Workers powered by Microsoft Copilot, AI Agents, and intelligent automation platforms.
Attendees will learn:
What Digital Workers actually are
How AI agents differ from chatbots
Real workplace use cases across HR, operations, support, and productivity
How Microsoft 365 Copilot is reshaping daily work
Where humans still outperform AI
The future of collaboration between employees and AI systems
Skills professionals need in an AI-native workplace
Through demos, scenarios, and practical examples, this session helps attendees understand how organizations are moving from traditional workflows toward AI-native work environments.
Your AI System Passed the Demo. How Do You Know It Works?
Traditional software gives us a familiar question: does the test pass?
AI systems make that question much harder. The same input can produce different outputs, a response can be factually correct but poorly grounded, and an agent can complete a workflow successfully while making an unsafe intermediate decision.
This session explores how to evaluate AI applications beyond a handful of example prompts. We will build an evaluation approach around correctness, relevance, groundedness, tool behaviour and failure cases, and examine how evaluations can become part of the development workflow rather than a final check before production.
Through practical examples, we will compare manual testing, curated datasets and automated evaluation, and discuss where each approach breaks down. We will also look at how evaluation results can be connected to model, prompt, retrieval and agent changes so teams can tell whether an AI system is actually improving.
The goal is simple: replace "the demo looked good" with measurable evidence that an AI system is becoming more reliable.
Your AI Wrote the Code. Now Who Owns It?
AI can generate a function in seconds. It can scaffold an API, write tests, refactor a module and even explain its own code. But when that code reaches production, who is responsible for deciding whether it is actually correct?
This session looks beyond the “AI makes developers faster” story and into what happens when AI becomes a real part of the software development lifecycle. We’ll explore where AI-assisted development genuinely helps, where it creates new failure modes, and why engineering judgement becomes more important - not less, as AI writes more of the code.
Through practical examples and real-world development scenarios, we’ll examine AI-generated code, testing, debugging, architecture, security, code review and the decisions that still need a human owner. We’ll also look at the uncomfortable gap between generating code quickly and being able to trust it.
The goal isn't to convince developers to use AI - or to avoid it. It is to develop a better engineering workflow for a world where writing code is increasingly easy, but owning the consequences of that code is still very human.
Your AI Agent Works. Now Try to Break It.
Building an AI agent is becoming easier. Knowing whether you can trust it in production is not.
An agent can successfully call a tool, retrieve information and produce a convincing answer while still failing in ways that are difficult to notice. It can choose the wrong tool, misunderstand context, invent an answer when retrieval fails, or take an action that was technically valid but operationally wrong.
This session takes a practical approach to testing AI agents on Azure. We will deliberately break an agent and examine what happens when tools fail, retrieved context is incomplete, instructions conflict, responses are incorrect, or an external dependency becomes unavailable.
We will explore practical patterns for evaluating agent behaviour, validating tool calls, handling failures, adding guardrails and observing agent workflows before they become production incidents.
The goal is not another session showing how to build an impressive AI agent. It is to answer the harder question: how do you know your agent is ready to be trusted?
Your AI Agent Knows Your Data. Does It Understand It?
Giving an AI agent access to a database is easy. Getting it to understand what the data actually means is much harder.
Ask an agent, "Which product grew the most last quarter?" and it can generate SQL, execute it and return a confident answer. But did it understand what "grew" means? Did it choose the correct date? Did it account for returns? Did it use the business definition of revenue?
This session explores the gap between data access and data understanding when building AI agents for analytics. Through practical examples and live demonstrations, we will see how an agent can produce technically valid queries and still reach the wrong analytical conclusion.
We will then explore how semantic context, metadata, business definitions, structured tools and validation can ground AI agents in trustworthy data. The focus is not on building another chatbot over a database, but on understanding what an agent actually needs to become a useful analytical partner.
Attendees will leave with practical architectural patterns for building AI systems that reason over data with more context, transparency and trust.
What We Got Wrong Building AI Systems
AI projects rarely fail for the reasons we expect when we start them.
The prototype works. The model looks impressive. The architecture seems reasonable. Then real data, real users, real latency and real costs arrive.
This session is an honest look at the engineering lessons that emerge when AI moves from experimentation toward real use. We will examine the assumptions that looked reasonable at the beginning, the problems that appeared later, and the changes that made the system more useful and reliable.
Topics include data quality, retrieval, context, evaluation, latency, cost and the gap between a successful demonstration and a dependable application.
Rather than presenting a polished success story, the session focuses on the decisions that had to be revisited, the approaches that did not work as expected and the engineering principles that emerged from those failures.
Attendees will leave with a practical checklist for identifying risky assumptions earlier in their own AI projects and avoiding some of the expensive lessons that only become obvious after implementation.
When Agents Act, Identity Becomes the Security Boundary
When software acts on behalf of a user, identity and authorization have always been fundamental security boundaries. AI agents make that boundary much harder to define.
An agent may read documents, call APIs, access business systems and trigger workflows, sometimes across multiple Microsoft services. If the agent inherits too much of the user's authority, one incorrect decision can have consequences far beyond a bad chatbot response.
This session explores identity and authorization for agentic applications, focusing on how to reason about agent identity, delegated permissions, least privilege, tool access and human approval when autonomous systems act on behalf of people.
We will map the identity flow from user to agent to tool and examine where traditional application permissions become insufficient. We will also look at practical patterns using Microsoft Entra and cloud services to constrain what an agent can access and what it is allowed to do.
The goal is to give developers and architects a practical security model for agents that can act without turning every autonomous workflow into an uncontrolled privileged account.
When AI Writes Your Data Pipeline: Who Reviews the Decisions?
AI-assisted development can generate a data pipeline in seconds. The harder question is whether the generated pipeline reflects the decisions your data actually requires.
A syntactically correct pipeline can still introduce subtle problems: incorrect joins, duplicated records, broken incremental logic, inappropriate transformations or assumptions about what a business metric means.
In this session, we will examine what changes when AI becomes part of the data engineering workflow. Through practical examples, we will look at where AI-assisted development can accelerate pipeline development, where it tends to make dangerous assumptions, and how developers and data engineers can introduce review, testing and validation into the workflow.
Rather than presenting AI as a replacement for data engineering expertise, the session focuses on a more useful model: AI handles more of the implementation, while engineers become increasingly responsible for specifying intent, validating results and catching the mistakes that code review alone may not reveal.
Attendees will leave with practical patterns for using AI-assisted development without turning data pipelines into code that is fast to generate but difficult to trust.
Your Agent Has a Context Problem
An AI agent can have a powerful model, the right tools and a carefully designed system prompt, yet still make the wrong decision because it was given the wrong context.
As agents become more capable, context is becoming an engineering problem of its own. Too little context and the agent misses critical information. Too much and important signals disappear in the noise. Stale memory, conflicting instructions, irrelevant retrievals and poorly scoped tool results can all push an agent toward a confident but incorrect action.
This session explores context engineering as an architectural discipline for building reliable AI agents. We will look at how instructions, retrieved information, conversation state, memory and tool outputs flow through an agent, where context becomes noisy or misleading, and how to deliberately control what the model sees.
We will examine practical patterns for context selection, retrieval, memory and context compression, along with the trade-offs between relevance, reliability, latency and cost.
Attendees will leave with a practical framework for designing agents that receive the right information at the right time, instead of simply giving increasingly capable models increasingly large amounts of information.
Your Agent Has a Context Problem
An AI agent can have the best model, the right tools and a carefully written system prompt, yet still make the wrong decision because it was given the wrong context.
As agents become more capable, context is becoming an engineering problem of its own. Too little context and the agent misses critical information. Too much and the signal gets buried in noise. Stale context, conflicting instructions, irrelevant retrievals and poorly scoped tool results can all lead an agent toward confident but incorrect actions.
This session explores context engineering as a core discipline for building reliable AI agents. Through practical examples, we will examine how context flows through an agent, where it can become noisy or misleading, and how to design context deliberately across instructions, retrieved information, conversation state, memory and tool outputs.
We will compare different context strategies and examine the trade-offs between relevance, reliability, latency and cost. The goal is to move beyond prompt engineering and treat context as an explicit part of the agent architecture.
Attendees will leave with practical patterns for designing agents that receive the right information at the right time, instead of simply giving an increasingly large amount of information to an increasingly capable model.
Your AI Agent Has Access to the Data. Can It Actually Understand It?
Giving an AI agent access to a database is easy. Giving it the right understanding of that data is much harder.
Ask an agent, "What were our best performing products last quarter?" and it may produce a confident answer. But which definition of revenue did it use? Which date did it filter on? Did it account for returns? Did it understand what "best performing" means in the business context?
This session explores the gap between data access and data understanding when building AI agents for analytics. We will look at how semantic models, metadata, business definitions and governed context can help agents reason about data more reliably.
Using practical examples, we will walk through common failure cases where an agent has technically valid access to data but still produces the wrong analytical conclusion. We will then examine architectural patterns for grounding agents in trustworthy business semantics, including how semantic layers can work alongside modern AI and data platforms.
The goal is not to build another chatbot over a database. It is to understand what an AI agent actually needs to become a useful analytical partner rather than a very convincing source of incorrect answers.
Your AI Agent Is the New Attack Surface
AI agents are moving beyond generating text. They can retrieve sensitive information, call APIs, execute tools and take actions on behalf of users. That changes the security model.
A prompt is no longer just a request for an answer. It can become an indirect path to a tool, a data source or an external system.
This session explores the security risks that appear when LLMs become agentic, focusing on prompt injection, indirect prompt injection, excessive tool permissions, untrusted context and unsafe tool use. Rather than treating these as isolated LLM problems, we will examine how they connect across the full agent architecture.
Through a controlled demonstration, we will start with an apparently harmless AI agent and progressively introduce malicious or untrusted inputs to show how an attacker can influence the agent's decisions. We will then apply practical defenses such as least-privilege tool access, input and output validation, trust boundaries, permission controls and human approval for high-impact actions.
The goal is not to show that AI agents are inherently unsafe. It is to understand the new attack surface they create and develop a security mindset for building agents that can act without giving them more authority than they should have.
The Productivity Trap: When AI Makes Developers Faster but Software Slower
We were promised a productivity revolution: ask AI for the code, accept the suggestion, move faster.
But software engineering has never been measured by how quickly code appears on a screen.
As AI takes over more implementation work, the bottleneck can move somewhere else-to reviewing generated code, debugging “almost-right” solutions, validating architecture, maintaining systems and understanding decisions nobody remembers making.
This session explores that shift through the practical realities of AI-assisted development. We'll look at what developers should measure when AI becomes part of the workflow, which tasks benefit from automation, where human judgement remains critical, and how teams can avoid confusing “more code produced” with “more value delivered.”
We'll also examine the emerging evidence around AI and developer productivity, including the uncomfortable trade-offs reported by both the developer community and software-delivery research.
The takeaway isn't “AI is bad” or “AI is the future.” It's a more useful question: if AI changes the cost of writing code, how should we change the way we engineer software?
The Hidden Engineering Problems Nobody Talks About in Generative AI
Building a GenAI demo is easy. Building reliable enterprise AI systems is an entirely different challenge.
This session uncovers the hidden engineering problems teams encounter while deploying AI systems in production environments. Rather than focusing on hype, this talk dives into the operational realities of modern AI engineering.
Topics include:
Token explosion and context limits
Latency bottlenecks
Prompt drift
Memory inconsistencies
AI cost unpredictability
Evaluation challenges
AI observability
Governance and compliance
Failure recovery architectures
AI system debugging
Attendees will gain practical strategies, architecture patterns, and engineering insights rarely discussed in mainstream AI conversations.
The Code Is Open Source. Can You Trust It?
Open source gives developers something powerful: the ability to inspect, modify and improve the software they depend on. But as AI-generated code becomes increasingly common, a new question is emerging: does visible source code automatically mean trustworthy software?
AI can generate an impressive open-source project in minutes. It can create dependencies, configuration, authentication logic, tests and documentation too. But who reviewed those decisions? Where did the code come from? Which dependencies are safe? What happens when nobody understands the generated implementation well enough to maintain it?
This session explores what trust should mean in modern open-source development. We will examine practical examples around AI-generated code, dependency risk, maintainability, licensing, security and human review, and look at how developers can use open-source software without treating "the source is available" as equivalent to "the software is trustworthy."
The goal is not to discourage AI or open source. It is to develop a stronger engineering mindset for building with software that is increasingly generated, reused and assembled at unprecedented speed.
The AI Supply Chain Nobody Is Watching
We already know how dangerous a compromised software dependency can be. AI applications quietly introduce a much larger supply chain.
A modern LLM application may depend on open-source packages, pretrained models, model weights, datasets, embedding models, adapters, plugins, external APIs and container images. Any of those components can become a security or integrity problem long before the application reaches production.
This session maps the attack surface of a modern AI application from source code to model runtime. We will examine practical risks around untrusted models, dependency compromise, model provenance, poisoned datasets, vulnerable components and AI-specific supply chain failures.
Through a controlled demonstration, we will follow a seemingly harmless AI dependency from ingestion to execution and identify where traditional software supply chain controls stop being sufficient.
We will then build a practical AI supply chain security checklist covering provenance, dependency inventory, model integrity, SBOMs, verification, access controls and monitoring.
The goal is simple: if your application has a software bill of materials, what should you have when part of your application is a model, dataset or AI component?
The AI Demo Worked. Production Had Other Ideas.
Everyone has seen the AI demo that works perfectly: give an agent a prompt, connect a few tools, ask a question and watch it produce an impressive result.
Then real users arrive.
The context is incomplete. A tool returns unexpected data. The model makes a confident assumption. Costs start accumulating. A workflow that looked reliable in a prototype becomes unpredictable when people actually depend on it.
This session explores what happens between an impressive AI prototype and a system that can survive real use. We will break down practical failure points across agents, RAG, tool calling, evaluation, guardrails, observability and cost, and examine the engineering decisions that determine whether an AI solution becomes useful or remains a demo.
Through concrete examples and failure scenarios, attendees will learn how to move beyond "it works on my prompt" and build AI systems that are measurable, controllable and ready for real-world use.
The goal is not another perfect AI demo. It is the part of the story that usually gets edited out: what broke, why it broke, and what we changed to make it work.
RAG Poisoning: When Your AI's Knowledge Base Becomes the Attack
RAG is often presented as the safer way to ground an LLM in trusted information. But what happens when the information you retrieve is the thing an attacker controls?
A malicious document does not need to exploit the model directly. If it enters a knowledge base, gets embedded and is retrieved at the right moment, it can influence what the model sees and ultimately what the application does.
This session explores the security boundary around RAG systems, focusing on data poisoning, malicious documents, retrieval manipulation, cross-context leakage and unsafe trust in retrieved content.
Through a controlled demonstration, we will start with a normal RAG application and introduce poisoned content into its knowledge base. We will then trace how that content moves through ingestion, retrieval and generation, and examine the controls that can prevent or limit the attack.
We will finish with a practical defensive architecture covering data provenance, ingestion validation, access control, retrieval filtering, content trust boundaries and monitoring.
The goal is to stop treating the vector database as a passive knowledge store and start treating the entire RAG pipeline as a security boundary.
RAG Is Not Search: Teaching AI to Find the Right Evidence
RAG demos are easy to build. Getting an AI system to consistently retrieve the right evidence is much harder.
When a RAG application gives a wrong answer, the instinct is often to blame the LLM. But many failures happen earlier: the right document was never retrieved, the relevant passage was ranked too low, the query did not match the user's intent, or semantic similarity simply wasn't enough.
This session goes behind the RAG demo and into the search problem underneath it. Using OpenSearch as the retrieval layer, we'll explore how lexical search, vector search and hybrid retrieval behave on real-world queries - and why relevance matters just as much as generation.
We'll look at practical failure cases, retrieval strategies, chunking and ranking decisions, and how to evaluate whether a RAG system is actually retrieving useful evidence rather than merely producing convincing answers.
The goal is not another “build a RAG app” tutorial. It is to show how to think like a search engineer when building AI applications - and how better retrieval can make the difference between an impressive demo and an AI system people can actually trust.
RAG Is Not Search: Teaching AI to Find the Right Evidence
RAG systems are often judged by the answer the LLM produces. But many of the hardest failures happen before generation even begins.
If the relevant evidence was never retrieved, was ranked too low, was fragmented across poor chunks, or was drowned out by irrelevant context, even the best model cannot produce a reliable answer.
This session looks at RAG as a retrieval engineering problem rather than simply an LLM integration pattern. We will compare lexical, semantic and hybrid retrieval approaches and examine how chunking, metadata, query formulation, ranking and reranking affect the evidence that reaches the model.
Using realistic failure cases, we will trace a RAG question from user query to retrieval to final generation and identify where quality is actually being lost. We will also explore practical ways to evaluate retrieval independently from the final LLM response.
The goal is to help developers stop asking only "Did the LLM answer correctly?" and start asking the more useful question: "Did we retrieve the right evidence in the first place?"
RAG Is Not Search: Teaching AI to Find the Right Evidence
Your AI can give a confident answer from completely wrong evidence. Discover why RAG fails before the LLM ever gets a chance to answer.
RAG Is Not Search: Teaching AI to Find the Right Evidence
A RAG application can generate a convincing answer from the wrong evidence.
When a retrieval system fails, the problem is often blamed on the LLM. But the model can only work with the information it receives. Poor chunking, weak metadata, an ineffective query, irrelevant retrievals or incorrect ranking can silently remove the evidence needed to answer correctly.
This session treats RAG as a retrieval engineering problem rather than simply an LLM integration pattern.
We will follow a question through query formulation, retrieval, ranking, context construction and generation, examining where information can be lost at each stage. We will compare lexical, semantic and hybrid retrieval strategies and discuss chunking, metadata, reranking and retrieval evaluation.
Most importantly, we will separate retrieval quality from generation quality so that teams can identify whether a poor answer is actually an LLM problem or a data and retrieval problem.
Attendees will leave with a practical framework for designing and evaluating RAG systems that retrieve useful evidence consistently rather than simply returning more documents.
Open Source in the AI Era: Why Community Contributions Matter More Than Resumes
In today’s competitive tech industry, traditional résumés are no longer enough to stand out. Open source contributions, technical communities, and public developer presence are becoming powerful signals of real-world engineering capability.
This session explores how open source participation is evolving in the age of AI and why community-driven development matters more than ever.
Attendees will learn:
How AI is changing open source ecosystems
Why companies value OSS contributions
Beginner-friendly ways to start contributing
Building technical credibility through community
GitHub as a professional portfolio
The hidden career opportunities in tech communities
Lessons from developer programs and ambassador experiences
How students and early-career developers can stand out
This session is especially valuable for students, aspiring developers, and professionals looking to grow their visibility in the modern tech industry.
MCP Is Easy to Demo. Harder to Operate.
MCP makes it much easier for AI applications to discover and use tools, data and external capabilities. But connecting an agent to more tools also creates a new engineering problem: how do we keep the system reliable, observable and controlled as the number of tools grows?
This lightning talk looks beyond the first MCP demo and explores what changes when MCP becomes part of a real AI application architecture. We will examine tool discovery, context, permissions, failure handling and the operational challenges that appear when agents depend on multiple external capabilities.
The focus is not on building another MCP server from scratch. Instead, we will look at the engineering questions teams should answer before allowing an agent to interact with real systems: What should it be allowed to access? What happens when a tool fails? How do we know which tool was used and why? And how do we keep an expanding tool ecosystem manageable?
Attendees will leave with a practical checklist for thinking about MCP as infrastructure rather than simply another AI developer tool.
From AI Prototype to Cloud-Native System: What Actually Changes?
Getting an AI application to work once is increasingly easy. Operating it reliably is a different engineering problem.
A prototype can tolerate manual steps, unpredictable latency, limited observability and a handful of users. A production AI service cannot.
This lightning talk explores the transition from an AI prototype to a cloud-native system, focusing on the engineering concerns that become important as usage grows: workload isolation, scalability, observability, failure handling, resource consumption, model and service dependencies, and the operational cost of inference.
Rather than focusing on a specific cloud provider or product, we will look at the architectural shift required when AI becomes another production workload that platform teams need to operate.
The goal is to give developers and platform engineers a practical mental model for recognizing when an AI experiment has outgrown its prototype architecture and what needs to change next.
AI Agents Are Easy Until They Need to Work Reliably
Building an AI agent demo is easy. Building one that behaves reliably, maintains context, uses tools correctly, and scales in real-world environments is a completely different challenge.
This session explores the hidden engineering problems behind modern AI agents and how developers can build more reliable agentic systems using Azure AI services and modern software engineering practices.
Topics include:
Why most AI agents fail in production
Prompt engineering vs system engineering
Agent memory and context management
Tool orchestration challenges
Retrieval reliability and hallucination reduction
Observability for AI systems
Cost and latency tradeoffs
Human-in-the-loop workflows
Practical architecture patterns using Azure AI
Attendees will gain practical insights into designing AI systems that move beyond demos into usable engineering solutions.
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