Microsoft

Software Engineer II

NeoSage

NeoSage is a technical deep-dive newsletter for engineers, solopreneurs, and AI builders who want to develop in-depth intuition on all things AI, from how LLMs work to how to architect agentic systems.

This is where you’ll owl-ways get the insights to ride the AI wave skillfully.

Founder

Amazon Web Services (AWS)

Software Development Engineer II

Adobe

Member Of Technical Staff 2

Member Of Technical Staff

Amazon

Software Development Engineer

Worked on building working prototype(UI/UX development based on provided designs and workflow) of a project in ideation - comicBlast, the project was showcased in Adobe MAX sneaks 2020.

Experience Developer Intern

DMs might get missed, for collabs write to me at: collab.shivanivirdi@gmail.com

Hello 👋

I’m a Software Engineer passionate about solving complex problems and creating innovative solutions that enhance user experiences.

Things I talk about on LinkedIn:
- Artificial Intelligence and LLMs
- Software Engineering and Clean Code
- Productivity Hacks and Career Growth
- Insights from Building LLM-Powered Products

📲 If this resonates with you, let’s connect!

---

🎯 I’m an experienced Software Engineer with a creative mindset and a knack for building impactful solutions. My journey spans working on full-stack development, delivering unique user-facing features, to backend engineering, tackling distributed systems that process large-scale data.

🚀 I thrive on creating value for users by crafting elegant solutions to challenging problems, leveraging cutting-edge technologies, and delivering seamless experiences. My passion lies in blending technical expertise with creativity to build products that make a difference.

💻 Beyond coding, I’m dedicated to sharing practical insights to empower engineers, foster productivity, and drive growth, both in careers and life.

🌍 I aim to use technology as a force for positive change, building tools and systems that create meaningful impact.

🔍 If you’re looking to connect with someone who shares a passion for innovation, engineering excellence, and personal growth, feel free to reach out.

📲 Let’s connect here on LinkedIn or explore more about my journey through my posts!

I developed a multi-agent system (PoC) in a week at Microsoft's Hackathon; this speed is a result of months of upskilling. Here's how I'd start all over again.

After completing the hackathon, I realised the old rules don't apply.

Deterministic logic is replaced by probabilistic reasoning, and the real skill is taming the non-determinism.

Here’s the blueprint to get you started.

LAYER 0: DL, NLP, and LLM Internals
Understand the engine first.

↳ Resources: 
• https://lnkd.in/gwqSPS4J
• https://lnkd.in/gd2JZ5Wt
• https://lnkd.in/g2pXsyHn
• https://lnkd.in/gPimp6mv

LAYER 1: Prompt Lifecycle Management
Your prompts are your control signals.

↳ Understand Patterns: Few-shot, Chain-of-Thought, ReAct.
↳ Implement a Lifecycle: Version control your prompts (Git), A/B test them, and use a registry for production deployment.

↳ Resources:
• https://lnkd.in/g2GfgaBp
• https://lnkd.in/gfByGMzt
• https://lnkd.in/g2RmYfKh

LAYER 2: RAG and Data Preparation

RAG is the memory and knowledge layer of your agent. It’s non-negotiable.

↳ Performant RAG depends entirely on data prep. 
↳ Context Engineering: This is about creating the perfect information package for your agent at runtime.

↳ Resources:
• https://lnkd.in/gTkNFRAz
• https://lnkd.in/gA7maM5Y
• https://lnkd.in/g2Tdc_h2

LAYER 3: Agentic AI Primitives
Before building a multi-agent system, master a single agent.

↳ Agent Capabilities: Understand tool calling, memory management, and planning loops.
↳ Protocols: Learn how standards like MCP enable modular and reusable tools.

↳ Resources:
• https://lnkd.in/ghcxpVXd
• https://lnkd.in/gbXxR4Dp
• https://lnkd.in/gfdJqGU4

LAYER 4: Multi-Agent Systems & Patterns

↳ Frameworks: LangGraph, AutoGen, and CrewAI are powerful, but the architecture comes first.
↳ Communication: Design how agents pass state, delegate tasks, and handle failures.

↳ Resources:
• https://lnkd.in/gY8buZ_c
• https://lnkd.in/gE_dMbYa
• https://lnkd.in/ga3SZAb3

LAYER 5: Evals and Observability

↳ You must be able to trace a decision from input → plan → RAG result → tool output → final response.

↳ Resources:
• https://lnkd.in/gcY8WyjV
• https://lnkd.in/gM4PyrMP

Stop thinking like a software engineer who uses AI.
Start thinking like an AI systems engineer.

What will you learn first?

♻️ Repost this to help your network build the real thing.

Shivani Virdi

Engineering @ Microsoft | Building GenAI Systems | Creator of NeoSage | 60K+ Learn AI Engineering with Me

I've read dozens of AI engineering books this year. 95% are shallow blog posts. But these 2 are the essentials for building production-grade LLM systems.

If you want to cut through the noise, stop browsing and start reading.

𝗕𝗼𝗼𝗸 𝟭: "𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗟𝗟𝗠𝘀 𝗳𝗼𝗿 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻" 𝗯𝘆 𝗟𝗼𝘂𝗶𝘀-𝗙𝗿𝗮𝗻𝗰̧𝗼𝗶𝘀 𝗕𝗼𝘂𝗰𝗵𝗮𝗿𝗱 & 𝗟𝗼𝘂𝗶𝗲 𝗣𝗲𝘁𝗲𝗿𝘀

This is The Architectural Blueprint.

It gives you the "what" – the full system view beyond a single component.

It's the book I wish I had when I started. It excels at:

↳ 𝗖𝗼𝗻𝗻𝗲𝗰𝘁𝗶𝗻𝗴 𝘁𝗵𝗲 𝗗𝗼𝘁𝘀: 
Moving from isolated components (RAG, fine-tuning, agents) to a cohesive system architecture. 

It teaches you to think in terms of tradeoffs, not just tools.

↳ 𝗣𝗿𝗮𝗴𝗺𝗮𝘁𝗶𝗰 𝗗𝗲𝘀𝗶𝗴𝗻 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀: 
It covers the most critical patterns you'll face in the real world, like advanced RAG, evaluation strategies, and data pipelines, without the academic fluff.

↳ 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗙𝗼𝗰𝘂𝘀: 
Every chapter is geared towards building something that works outside a notebook.
 
It forces you to think about reliability, cost, and scalability from day one.

get it here: https://lnkd.in/gncxn4Nv

𝗕𝗼𝗼𝗸 𝟮: "𝗟𝗟𝗠𝗢𝗽𝘀" 𝗯𝘆 𝗔𝗯𝗶 𝗔𝗿𝘆𝗮𝗻

This is The Operational Playbook.

It gives you the "how" – the end-to-end lifecycle management for the systems you design.

It's the definitive guide to not letting your brilliant architecture die in production. 
It nails:

↳ 𝗧𝗵𝗲 𝗙𝘂𝗹𝗹 𝗟𝗶𝗳𝗲𝗰𝘆𝗰𝗹𝗲: 
Moving beyond a simple "deploy" command to a full operational loop, including prompt management, continuous monitoring, and model versioning.

↳ 𝗧𝗼𝗼𝗹𝗶𝗻𝗴 & 𝗜𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲: 
It provides a structured overview of the modern LLMOps stack, helping you make informed decisions about what to build vs. buy.

↳ 𝗚𝗼𝘃𝗲𝗿𝗻𝗮𝗻𝗰𝗲 & 𝗚𝘂𝗮𝗿𝗱𝗿𝗮𝗶𝗹𝘀: 
It tackles the messy-but-critical parts of production AI, like security, compliance, and implementing robust guardrails to prevent failures.

get it here: https://lnkd.in/grk4zY7Q

Reading random articles creates the illusion of learning.
Reading these two books builds a real foundation.

One gives you the map. 
The other teaches you how to drive.

Save this post. 
Read these books. 
Build better systems.

♻️ Repost this to help your network level up.

This is the AI playlist I trust after wasting 3,467+ hours browsing, so you don’t have to.

𝟭. 𝗡𝗲𝘂𝗿𝗮𝗹 𝗡𝗲𝘁𝘄𝗼𝗿𝗸𝘀: 𝗭𝗲𝗿𝗼 𝘁𝗼 𝗛𝗲𝗿𝗼 [𝗣𝗹𝗮𝘆𝗹𝗶𝘀𝘁]
https://lnkd.in/gbwPdm-t
Karpathy walks you from micro-gradients to nanoGPT. Pure code-first intuition.

𝟮. 𝗦𝘁𝗮𝗻𝗳𝗼𝗿𝗱 𝗖𝗦𝟯𝟯𝟲 – 𝗟𝗮𝗻𝗴𝘂𝗮𝗴𝗲 𝗠𝗼𝗱𝗲𝗹𝗹𝗶𝗻𝗴 𝗳𝗿𝗼𝗺 𝗦𝗰𝗿𝗮𝘁𝗰𝗵 (𝟮𝟬𝟮𝟱 𝗲𝗱𝗶𝘁𝗶𝗼𝗻) [𝗣𝗹𝗮𝘆𝗹𝗶𝘀𝘁]
https://lnkd.in/gVrm9CcA
Full-stack LLM engineering: data → training → serving → eval.

𝟯. 𝗠𝗜𝗧 𝟲.𝗦𝟭𝟵𝟭 – 𝗜𝗻𝘁𝗿𝗼 𝘁𝗼 𝗗𝗲𝗲𝗽 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴 (𝟮𝟬𝟮𝟱)
https://lnkd.in/gNGV2kbB
Fast-track tour of modern DL, transformers + diffusion packed into 1h 45m.

𝟰. 𝗖𝗦𝟮𝟱 – 𝗜𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝘁𝗼 𝗧𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺𝗲𝗿𝘀 𝘄/ 𝗞𝗮𝗿𝗽𝗮𝘁𝗵𝘆
https://lnkd.in/gVSwUB2C
Turns “Attention Is All You Need” into deployable code.

𝟱. 𝗦𝘁𝗮𝗻𝗳𝗼𝗿𝗱 𝗖𝗦𝟮𝟮𝟵 𝗚𝘂𝗲𝘀𝘁 𝗟𝗲𝗰𝘁𝘂𝗿𝗲 – 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗟𝗮𝗿𝗴𝗲 𝗟𝗮𝗻𝗴𝘂𝗮𝗴𝗲 𝗠𝗼𝗱𝗲𝗹𝘀
https://lnkd.in/gBEG6Pff
Inside Stanford’s 2025 LLM pipeline: scaling, eval, iteration loops.

𝟲. 𝗗𝗲𝗲𝗽 𝗗𝗶𝘃𝗲 𝗶𝗻𝘁𝗼 𝗟𝗟𝗠𝘀 𝗹𝗶𝗸𝗲 𝗖𝗵𝗮𝘁𝗚𝗣𝗧
https://lnkd.in/gv9c8iHY
3.5 hours of pure wisdom on how GPTs come to life

𝟳. 𝗟𝗲𝘁’𝘀 𝗕𝘂𝗶𝗹𝗱 𝗚𝗣𝗧 𝗳𝗿𝗼𝗺 𝗦𝗰𝗿𝗮𝘁𝗰𝗵
https://lnkd.in/gARg92VT
200 lines of Python → a working GPT. Watch, code, internalise.

⚡️ 𝗦𝗮𝘃𝗲 𝘁𝗵𝗶𝘀 𝗽𝗼𝘀𝘁—50+ hours of signal that beats months of random browsing.
👇 𝗬𝗼𝘂𝗿 𝘁𝘂𝗿𝗻: Which video are you queuing up first?

P.S. I bring deep-dive breakdowns on dense concepts in these videos only on NeoSage → https://blog.neosage.io

Engineering at Microsoft | Simplifying AI for Everyone | Empowering Productivity with Proven Frameworks and Processes

Raghav Ram, PhD

It doesn’t matter if you use LangChain or Haystack.
It doesn’t matter if you use function calls or MCP.
It doesn’t matter if you use AutoGen or crewAI.

What matters is if you can think like an AI systems engineer.

That means mastering these 5 areas:

𝟭. 𝗖𝗮𝗻 𝘆𝗼𝘂 𝘁𝗵𝗶𝗻𝗸 𝗶𝗻 𝘁𝗲𝗿𝗺𝘀 𝗼𝗳 𝗗𝗔𝗧𝗔?
The real gap in most organisations is the data pipeline.

↳ Human-to-Machine Gap: 
Your docs are written for humans, who piece together scattered info. LLMs can't. 
They need complete, structured context.

↳ Maintenance Void: 
No systems exist to maintain, version, and prep this knowledge for an ingestion pipeline. 

↳ Modality Mess: 
You have to handle a mix of data types: PDFs, tables, images, unstructured text, and unify them for the model.

𝟮. 𝗖𝗮𝗻 𝘆𝗼𝘂 𝘁𝗵𝗶𝗻𝗸 𝗶𝗻 𝘁𝗲𝗿𝗺𝘀 𝗼𝗳 𝗖𝗢𝗡𝗧𝗘𝗫𝗧?
This is about orchestrating every piece of information the model sees. 

The final context package is an engineered artifact.

↳ The Context Package: 
A production system engineers the context by dynamically assembling the
system prompt, 
summarising chat history, 
and cleaning tool outputs 
before they are fed to the model.

↳ State & Memory Management: 
LLMs are stateless. This is about building the persistence layer that gives the application memory.

↳ The Write-Back Loop: 
A system that doesn't learn from its interactions is already becoming obsolete.

𝟯. 𝗖𝗮𝗻 𝘆𝗼𝘂 𝘁𝗵𝗶𝗻𝗸 𝗶𝗻 𝘁𝗲𝗿𝗺𝘀 𝗼𝗳 𝗦𝗬𝗦𝗧𝗘𝗠𝗦?

↳ Observability: 
Can you trace a decision from input → plan → RAG result → tool output → final response? 
If not, you're flying blind.

↳ Evaluations: 
You need a CI/CD pipeline for 𝘣𝘦𝘩𝘢𝘷𝘪𝘰𝘶𝘳, too. 
Evals must catch regressions in reasoning.

↳ Graceful Failure: 
What happens when the model is wrong or a tool fails? 
The system must degrade gracefully.

𝟰. 𝗖𝗮𝗻 𝘆𝗼𝘂 𝘁𝗵𝗶𝗻𝗸 𝗶𝗻 𝘁𝗲𝗿𝗺𝘀 𝗼𝗳 𝗖𝗢𝗦𝗧?
This goes beyond API bills. 
It's about unit economics.

↳ Cost Per Task: 
What is the token consumption per user query or completed task? 
Is it sustainable at scale?

↳ Model Selection: 
Every choice is a tradeoff. Do you need large reasoning model, or can a faster SLM suffice?

↳ Caching Layers: 
Are you implementing caching for common queries or retrieved results to reduce redundant, expensive API calls?

𝟱. 𝗖𝗮𝗻 𝘆𝗼𝘂 𝘁𝗵𝗶𝗻𝗸 𝗹𝗶𝗸𝗲 𝘆𝗼𝘂𝗿 𝗨𝗦𝗘𝗥?
The ultimate measure of your system isn't its power, but its reliability.

↳ Solving the Real Problem: 
Does the AI-powered feature actually solve the user's underlying problem better?

↳ Building Trust: 
A system that is transparent, explainable, and fails predictably will earn more user trust than a "magical" one that breaks unexpectedly.

↳ The Last Mile: 
Is the final output structured, useful, and directly applicable for the user?

Stop chasing the new hot framework.

Master the five layers of thinking that actually deliver value.

♻️ Repost this to help your network build better systems.

If I had to bet on one skill for every AI Engineer in 2025, it would be RAG.
But not for the reason you think.

Most see Retrieval-Augmented Generation as a technique to build Q&A bots. 
That’s just the surface.

The real reason RAG is a must-have skill is that it’s a fundamental 𝘀𝘆𝘀𝘁𝗲𝗺 𝗱𝗲𝘀𝗶𝗴𝗻 𝗽𝗮𝘁𝘁𝗲𝗿𝗻. 

It solves the core problem of getting the right context to an LLM, and you'll encounter that problem at every layer of an AI-powered system.

A lot of what RAG does isn't new (indexing, retrieval, etc., have been around for years), 

But RAG 𝘴𝘱𝘦𝘤𝘪𝘢𝘭𝘪𝘴𝘦𝘴 these techniques for LLM-powered applications.

Here’s why it’s non-negotiable:

1. LLMs are Static: Their knowledge is a snapshot from training time.
   
2. Proprietary Data: LLMs weren’t trained on your company’s internal wikis, codebase, or private documents.
   
3. Finite Context Windows: You can’t fit everything into 128k tokens. (neither in a million)
   
4. Cost Optimisation: Every token costs money, and hence it's important to curate context with only what's relevant
   
5. Context is King: The performance of an LLM is only as good as the context it sees. 
RAG is the core of effective Context Engineering.

Here are 4 places RAG shows up in production systems, 
each with its own nuances:

1. The Standard: RAG for Knowledge Retrieval 
This is the one everyone knows. 

↳ You build an index (or a knowledge graph) over proprietary data

↳ Your chatbot or agent then uses this to pull in correct, grounded information and avoid hallucination.


2. The Agentic Skillset: RAG for Extended Instructions 

↳ In complex agentic systems, an agent's "skills" or instructions can change based on the task.

↳ Bloating the system prompt with every possible instruction is inefficient and costly.
 
↳ Build a RAG pipeline for your prompts. 
The agent retrieves the specific instructions, heuristics, or templates it needs for a given operation, keeping the core prompt lean.


3. The Long-Term Memory: RAG for Agentic Context

↳ Long-running agents accumulate massive amounts of context—past actions, observations, and user interactions.

↳ Instead of just compressing or losing old information, the agent compresses and offloads its history into a vector store.

↳ When it needs to recall a past event, it queries its own memory via RAG, ensuring it never loses critical information.

4. The Dynamic Toolkit: RAG for Tool Discovery 

↳ An advanced agent might have access to hundreds of different tools or APIs. 
It’s impossible to fit all those function schemas into the prompt. 

↳ The agent uses RAG to dynamically retrieve the most relevant tool definitions based on the user's intent. 

↳ Instead of knowing every tool, it knows how to 𝘧𝘪𝘯𝘥 the right tool for the job

RAG isn't just a feature. 
It's a foundational piece of AI system design.

What's the most surprising place you've seen the RAG pattern used?

♻️ Repost this to help your network think in systems.

RAG Use Cases in Production

If I could keep only five AI books on my desk before a 2025 GenAI interview, this would be it.

No fluff, no hype—just field-tested wisdom that upgrades you from “prompt tinkerer” to “production-ready engineer.”

𝟭. 𝗗𝗲𝘀𝗶𝗴𝗻𝗶𝗻𝗴 𝗠𝗮𝗰𝗵𝗶𝗻𝗲 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 – 𝗖𝗵𝗶𝗽 𝗛𝘂𝘆𝗲𝗻 
↳ Scalable, reliable, observable ML in production. 
↳ 𝘎𝘳𝘦𝘢𝘵 𝘧𝘰𝘳: Explaining trade-offs and pipeline architecture.

𝟮. 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗟𝗟𝗠𝘀 𝗳𝗼𝗿 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 – 𝗟𝗼𝘂𝗶𝘀-𝗙𝗿𝗮𝗻𝗰̧𝗼𝗶𝘀 𝗕𝗼𝘂𝗰𝗵𝗮𝗿𝗱 & 𝗟𝗼𝘂𝗶𝗲 𝗣𝗲𝘁𝗲𝗿𝘀 
↳ Prompting → fine-tuning → RAG in a single, prod-ready workflow. 
↳ 𝘎𝘳𝘦𝘢𝘵 𝘧𝘰𝘳: Real-world LLM deployment and app design.

𝟯. 𝗕𝘂𝗶𝗹𝗱 𝗮 𝗟𝗮𝗿𝗴𝗲 𝗟𝗮𝗻𝗴𝘂𝗮𝗴𝗲 𝗠𝗼𝗱𝗲𝗹 (𝗙𝗿𝗼𝗺 𝗦𝗰𝗿𝗮𝘁𝗰𝗵) – 𝗦𝗲𝗯𝗮𝘀𝘁𝗶𝗮𝗻 𝗥𝗮𝘀𝗰𝗵𝗸𝗮, 𝗣𝗵𝗗 
↳ Tokenizers, training loops, serving—hands-on GPT-style builds. 
↳ 𝘎𝘳𝘦𝘢𝘵 𝘧𝘰𝘳: Knowing how LLMs work under the hood.

𝟰. 𝗧𝗵𝗲 𝗟𝗟𝗠 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿’𝘀 𝗛𝗮𝗻𝗱𝗯𝗼𝗼𝗸 – 𝗣𝗮𝘂𝗹 𝗜𝘂𝘀𝘇𝘁𝗶𝗻 & 𝗠𝗮𝘅𝗶𝗺𝗲 𝗟𝗮𝗯𝗼𝗻𝗻𝗲 
↳ Full LLMOps: evaluation, deployment, monitoring, cost control. 
↳ 𝘎𝘳𝘦𝘢𝘵 𝘧𝘰𝘳: Designing robust, scalable GenAI pipelines.

𝟱. 𝗔𝗜 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 – 𝗖𝗵𝗶𝗽 𝗛𝘂𝘆𝗲𝗻 
↳ Patterns for serving and adapting foundation models in products. 
↳ 𝘎𝘳𝘦𝘢𝘵 𝘧𝘰𝘳: Real-time constraints, model tuning, and rollout.

🔖 𝗦𝗮𝘃𝗲 𝘁𝗵𝗶𝘀
🔄 𝗥𝗲𝗽𝗼𝘀𝘁 𝗶𝗳 𝘀𝗼𝗺𝗲𝗼𝗻𝗲 𝘆𝗼𝘂 𝗸𝗻𝗼𝘄 𝗶𝘀 𝗽𝗿𝗲𝗽𝗽𝗶𝗻𝗴 𝗳𝗼𝗿 𝗔𝗜 𝗿𝗼𝗹𝗲𝘀

💡 Want battle-tested insights from someone building with LLMs every day? 𝗝𝗼𝗶𝗻 𝟳,𝟴𝟬𝟬+ 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀 𝗿𝗲𝗮𝗱𝗶𝗻𝗴 𝗡𝗲𝗼𝗦𝗮𝗴𝗲: https://blog.neosage.io

𝗬𝗼𝘂𝗿 𝘁𝘂𝗿𝗻: Which of these is already on your shelf—and what deserves the #6  spot?

If I had to explain LLMs to every new AI engineer I hire, I’d start with this
This 2-minute read will give you a stronger foundation than most $300 courses.

Once you understand how GPTs are built and trained to be helpful,
you’ll:
→ Prompt better
→ Build smarter
→ And stop expecting magic from a probability engine

𝟭. 𝗚𝗣𝗧𝘀 𝗮𝗿𝗲𝗻’𝘁 𝗶𝗻𝘁𝗲𝗹𝗹𝗶𝗴𝗲𝗻𝘁. 𝗧𝗵𝗲𝘆’𝗿𝗲 𝗽𝗿𝗲𝗱𝗶𝗰𝘁𝗶𝗼𝗻 𝗲𝗻𝗴𝗶𝗻𝗲𝘀.
They don’t “know” or “understand.”
Their only task? Predict the next token, one at a time, based on trillions of prior examples.

𝟮. 𝗣𝗿𝗲𝘁𝗿𝗮𝗶𝗻𝗶𝗻𝗴 𝗯𝘂𝗶𝗹𝗱𝘀 𝘁𝗵𝗲 𝗯𝗿𝗮𝗶𝗻.
The model consumes a cleaned, tokenized internet.
It learns language 𝘴𝘵𝘳𝘶𝘤𝘵𝘶𝘳𝘦, not facts, by seeing what typically comes next.
Think: lossy compression at scale.

𝟯. 𝗧𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺𝗲𝗿𝘀 𝗴𝗶𝘃𝗲 𝗶𝘁 𝘀𝘂𝗽𝗲𝗿𝗽𝗼𝘄𝗲𝗿𝘀.
Self-attention lets each token learn in context.
Example: “𝘛𝘩𝘦 𝘢𝘯𝘪𝘮𝘢𝘭 𝘥𝘪𝘥𝘯’𝘵 𝘤𝘳𝘰𝘴𝘴 𝘵𝘩𝘦 𝘴𝘵𝘳𝘦𝘦𝘵 𝘣𝘦𝘤𝘢𝘶𝘴𝘦 𝘪𝘵 𝘸𝘢𝘴 𝘵𝘪𝘳𝘦𝘥.”
The model learns that “𝘪𝘵” refers to “𝘢𝘯𝘪𝘮𝘢𝘭,” not “𝘴𝘵𝘳𝘦𝘦𝘵.”

𝟰. 𝗚𝗣𝗧𝘀 𝗮𝗿𝗲 𝗱𝗲𝗰𝗼𝗱𝗲𝗿-𝗼𝗻𝗹𝘆 𝗺𝗼𝗱𝗲𝗹𝘀.
They generate outputs one token at a time, using only past context.
This makes them 𝘢𝘶𝘵𝘰𝘳𝘦𝘨𝘳𝘦𝘴𝘴𝘪𝘷𝘦, ideal for generation.

𝟱. 𝗧𝗵𝗲 𝗯𝗮𝘀𝗲 𝗺𝗼𝗱𝗲𝗹 𝗶𝘀 𝗽𝗼𝘄𝗲𝗿𝗳𝘂𝗹, 𝗯𝘂𝘁 𝘂𝗻𝗮𝗹𝗶𝗴𝗻𝗲𝗱.
After pretraining, it can mimic internet patterns—but it doesn’t know when to say “I don’t know” or how to stay helpful. It’s a raw internet simulator.

𝟲. 𝗟𝗟𝗠𝘀 𝗮𝗿𝗲 𝘀𝘁𝗼𝗰𝗵𝗮𝘀𝘁𝗶𝗰, 𝗻𝗼𝘁 𝗱𝗲𝘁𝗲𝗿𝗺𝗶𝗻𝗶𝘀𝘁𝗶𝗰.
Same prompt, different outputs.
Why? Every token is sampled from a probability distribution, not pulled from facts.

𝟳. 𝗪𝗵𝘆 𝗟𝗟𝗠𝘀 𝘀𝘁𝗿𝘂𝗴𝗴𝗹𝗲 𝘄𝗶𝘁𝗵 𝗺𝗮𝘁𝗵, 𝗰𝗼𝘂𝗻𝘁𝗶𝗻𝗴, 𝗮𝗻𝗱 𝗹𝗶𝗺𝗶𝘁𝘀.
They’re pattern matchers, not reasoning engines.
They 𝘨𝘶𝘦𝘴𝘴 likely sequences; they don’t 𝘤𝘢𝘭𝘤𝘶𝘭𝘢𝘵𝘦.
For these tasks, tool use work better.

𝟴. 𝗦𝘂𝗽𝗲𝗿𝘃𝗶𝘀𝗲𝗱 𝗳𝗶𝗻𝗲-𝘁𝘂𝗻𝗶𝗻𝗴 𝘁𝗲𝗮𝗰𝗵𝗲𝘀 𝗯𝗲𝗵𝗮𝘃𝗶𝗼𝘂𝗿.
Curated examples show the model how to answer, format, follow instructions, and reject unsafe queries.
It starts acting like an assistant.

𝟵. 𝗥𝗲𝗶𝗻𝗳𝗼𝗿𝗰𝗲𝗺𝗲𝗻𝘁 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝘀𝗵𝗮𝗿𝗽𝗲𝗻𝘀 𝗶𝘁 𝗯𝗲𝘆𝗼𝗻𝗱 𝗶𝗺𝗶𝘁𝗮𝘁𝗶𝗼𝗻.
→ 𝘚𝘵𝘢𝘯𝘥𝘢𝘳𝘥 𝘙𝘓 teaches via trial and error—generate, score, repeat—to discover token patterns that work.
→ 𝘙𝘓𝘏𝘍 uses human-ranked outputs to train a reward model, helping the LLM mimic tone, clarity, and helpfulness.

𝟭𝟬. 𝗧𝗵𝗲𝘀𝗲 𝘀𝘁𝗲𝗽𝘀 𝘀𝗵𝗮𝗽𝗲 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴
Alignment doesn’t make the model 𝘴𝘮𝘢𝘳𝘵𝘦𝘳, just safer and more predictable.
But underneath, it’s still the same prediction engine, just better guided.

If you're building with LLMs, start with the right mental models.

I broke this down in more detail in the first two issues of NeoSage:
https://lnkd.in/g2pXsyHn
https://lnkd.in/gPimp6mv

I’ve built RAG systems. I’ve built agentic systems. 
But when you combine them, 𝘁𝗵𝗮𝘁’𝘀 𝘄𝗵𝗲𝗿𝗲 𝘁𝗵𝗲 𝗺𝗮𝗴𝗶𝗰 𝗵𝗮𝗽𝗽𝗲𝗻𝘀.

RAG brought external knowledge into LLMs.

But it struggles with complex workflows, tool use, and multi-step reasoning.

That’s where Agentic RAG comes in.
It’s not just about 𝘳𝘦𝘵𝘳𝘪𝘦𝘷𝘪𝘯𝘨 𝘪𝘯𝘧𝘰—it’s about 𝘳𝘦𝘢𝘴𝘰𝘯𝘪𝘯𝘨 𝘸𝘪𝘵𝘩 𝘪𝘵 like an autonomous agent.

𝗛𝗲𝗿𝗲’𝘀 𝗵𝗼𝘄 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗥𝗔𝗚 𝘄𝗼𝗿𝗸𝘀:
🔹 𝗜𝗻𝘁𝗲𝗻𝘁 𝗥𝗲𝗰𝗼𝗴𝗻𝗶𝘁𝗶𝗼𝗻
Understands what the user 𝘸𝘢𝘯𝘵𝘴, not just what they said.
🔹 𝗗𝘆𝗻𝗮𝗺𝗶𝗰 𝗥𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗣𝗹𝗮𝗻𝗻𝗶𝗻𝗴
Doesn’t stop at the first result—iteratively refines what it pulls in.
🔹 𝗧𝗮𝘀𝗸 𝗗𝗲𝗰𝗼𝗺𝗽𝗼𝘀𝗶𝘁𝗶𝗼𝗻
Breaks down complex queries into sub-goals and handles them step-by-step.
🔹 𝗔𝘂𝘁𝗼𝗻𝗼𝗺𝗼𝘂𝘀 𝗔𝗴𝗲𝗻𝘁𝘀
Uses a network of specialized agents to retrieve, verify, and generate.
🔹 𝗧𝗼𝗼𝗹 & 𝗔𝗣𝗜 𝗜𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗶𝗼𝗻
Calls external APIs, runs searches,accesses databases on the fly.
🔹 𝗠𝗲𝗺𝗼𝗿𝘆 & 𝗖𝗼𝗻𝘁𝗲𝘅𝘁
Keeps track of past interactions, updates context mid-task, and reasons over it.
🔹 𝗤𝘂𝗮𝗹𝗶𝘁𝘆 𝗖𝗼𝗻𝘁𝗿𝗼𝗹
Agents verify and correct responses before replying. Less hallucination. More precision.

Architecturally, they’re in different leagues:
𝗥𝗔𝗚
• One-shot: retrieve, augment, generate
• No memory, no planning, no tools
• Great for static Q&A, not for solving dynamic problems

𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗥𝗔𝗚
• Multi-step: reason, plan, retrieve, reflect
• Built on autonomous agents
• Handles workflows, adapts context, self-corrects
• Thinks before it answers

𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀:
Agentic RAG isn’t just more complex—it’s more 𝘤𝘢𝘱𝘢𝘣𝘭𝘦.
✅ Learns your intent
✅ Breaks down the task
✅ Retrieves the right info
✅ Verifies it
✅ Responds with context
✅ Adapts over time

𝗧𝗵𝗶𝘀 𝗶𝘀 𝘄𝗵𝗮𝘁 𝗥𝗔𝗚 𝗯𝗲𝗰𝗼𝗺𝗲𝘀 𝘄𝗵𝗲𝗻 𝗶𝘁 𝗴𝗿𝗼𝘄𝘀 𝘂𝗽.
From search-and-say → to autonomous, goal-driven assistants.

𝗢𝘃𝗲𝗿 𝘁𝗼 𝘆𝗼𝘂:
What would 𝘺𝘰𝘶 build if your RAG system could think, plan, and act like an AI agent?

♻️ Repost to share with your network
➕ Follow Shivani Virdi for more.

If I had to bet on one skill in AI as an engineer… I’d go for RAG. And this is exactly how I’d learn it from scratch in 2025.

Why RAG?

When context windows are getting bigger.

You might think: “Why not just upload my entire doc DB or codebase to the chat?”

But that’s flawed for two reasons:

1. Bigger context ≠ better context
Just because the model can see more doesn’t mean it sees what matters.

2. Tokens aren’t free
If you're building anything beyond a personal project, 
cost becomes very real.

Serving millions of users with token-heavy prompts? 
That’ll burn a hole through your API budget.
You can’t afford to brute-force context.

You need to engineer it, and that’s where RAG becomes non-negotiable.

So if I were starting fresh, 
here’s the roadmap I’d follow:

1 paper – the OG
https://lnkd.in/gp7y4zFu

1 blog – Understand it in plain English
https://lnkd.in/gTkNFRAz

1 hands-on tutorial – Get your hands dirty
https://lnkd.in/gneRRxg9

1 GitHub repo – by Nir Diamant
https://lnkd.in/gA7maM5Y

1 framework tutorial – LangChain’s RAG guide
https://lnkd.in/g_U6GtqG

1 progressive course list – curated by DeepLearning.ai
https://lnkd.in/gPQMJVF9

1 newsletter – for weekly breakdowns, tech deep dives, and AI systems thinking
NeoSage https://blog.neosage.io

Save this. Share it. Build AI systems that don’t hallucinate for no reason.

Know a great RAG resource I missed?
Drop it below.

♻️ Reposting this helps everyone in your network upskill

Cursor just doesn't work for data science. And I wish I had known what works before wasting countless hours on it.

Here's the frustrating loop every data scientist knows:

1. You ask the AI to write a data science workflow.
   
2. It generates code that 𝘭𝘰𝘰𝘬𝘴 right.
   
3. You copy-paste it into your notebook. 
   It fails with an obscure error.
   
4. You copy the error message back to the AI.
   
5. It apologises and gives you slightly different, but still broken, code.
   
The problem isn't the LLM. 
It's the context. The AI is programming blindfolded.

It can't see your data schema.
It can't execute the code cells.
It can't see the output or the error trace.

𝗜𝘁'𝘀 𝗴𝘂𝗲𝘀𝘀𝗶𝗻𝗴. And in data science, guessing is a death sentence for productivity.

This is why I've always been skeptical of "AI coding assistants" for data work. 

For an AI to be useful, it can't just be a code generator. 

It needs to be a 𝗳𝗶𝗿𝘀𝘁-𝗰𝗹𝗮𝘀𝘀 𝗰𝗶𝘁𝗶𝘇𝗲𝗻 𝗼𝗳 𝘁𝗵𝗲 𝗱𝗮𝘁𝗮 𝘀𝘁𝗮𝗰𝗸.

It needs an environment where it can:
↳ Execute code and see the result.
↳ Inspect data schemas and outputs directly.
↳ Understand the entire workflow as a graph (DAG), not just a single script.
↳ Learn from its mistakes in a tight feedback loop.

I've been waiting for a performant agentic setup to get the context right

And 𝗭𝗲𝗿𝘃𝗲 𝗔𝗜 is the first I've seen to actually deliver.

I tried a typical Exploratory Data Analysis task with Cursor and Zerve.

Where Cursor proposed EDA findings without ever executing the code cells,

Zerve: 
↳ Planned the analysis in clear, logical steps.
↳ Executed each code block and passed the results forward in a DAG.
↳ Fed outputs, charts, and dataframes from one as context to the next.
↳ Summarised 𝗿𝗲𝗮𝗹 𝗿𝗲𝘀𝘂𝗹𝘁𝘀, as it updated its context after every single run.

If you haven’t already, check out Zerve here: 
https://lnkd.in/gdXFSFum

What's the biggest limitation you've found with AI coding assistants in your data work?

♻️ Repost this to help your data team save hours

Enterprise AI isn't just building agents.
Enterprise AI isn't connecting to MCP servers.
Enterprise AI isn't connecting to a vector DB.
Enterprise AI isn't a demo that works on your machine.

Enterprise AI is the disciplined practice of 𝗢𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻.

Our feeds are flooded with cool AI demos built from a Frankenstein stack of open-source libraries, scripts, and API keys.

They work, but they are fragile.

The moment they face the realities of an enterprise
security reviews, 
budget constraints, and 
complex data systems
They break.

To build something that lasts, 
You need to stop thinking about agents and 
start thinking in layers of orchestration.

𝟭. 𝗧𝗵𝗲 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 𝗣𝗹𝗮𝗻𝗲: A Unified Hub, Not a Dozen Tools

Your system needs a central nervous system, not a chaotic collection of parts.

❌ Juggling separate tools for prototyping, prompt management, and deployment.

✅ You operate from a unified Prototyping Studio. 
It’s a single, governed environment to design, test, and deploy agents, moving from concept to production without the chaos.

𝟮. 𝗧𝗵𝗲 𝗢𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀 𝗟𝗮𝘆𝗲𝗿: Full Visibility, Not a Black Box of Costs

An unmonitored AI system is a blank check for your cloud provider.
Enterprise-grade means having total operational and financial control.

❌ Hardcoding a single, expensive model and having no visibility into token consumption.

✅ You use an Intelligent Routing Engine to dynamically pick the right model for the job—balancing cost and performance.

𝟯. 𝗧𝗵𝗲 𝗚𝗼𝘃𝗲𝗿𝗻𝗮𝗻𝗰𝗲 𝗟𝗮𝘆𝗲𝗿: 

In the enterprise, trust is not optional. 
Security and governance must be built in.

❌ Building with no security in mind. 
No access control, no traceability, no logs. 
It’s a system that’s completely blind. 

✅ Building on a foundation with 
Responsible AI Guardrails to detect hallucinations, 
Prompt Injection Security to prevent manipulation, 
and Full Interaction Logs for compliance.

𝟰. 𝗧𝗵𝗲 𝗗𝗮𝘁𝗮 𝗟𝗮𝘆𝗲𝗿:
Your agent is only as good as the data it can access.
That access must be secure, flexible, and reliable.

❌ Writing risky, custom scripts to connect to production data sources, locking you into one data structure.

✅ Using secure, pre-built connectors to your existing enterprise systems. 
This ensures your data layer is a flexible foundation, 
ready to feed any model you choose to orchestrate.

I was looking for a one-stop, enterprise-grade AI orchestration platform and came across Airia.

It checks all the boxes:
↳ Build Agents Fast: A flexible builder for both no-code and full-code development.
↳ Swap any LLM without vendor lock-in.
↳ Get full FinOps visibility and control over token spend.
↳ Govern Everything: Use built-in enterprise security, guardrails, and audit logs.
↳ Securely integrate with existing enterprise systems and databases.

Try it here: https://airia.com/register

♻️ Repost to help your network find an enterprise-grade AI platform

Four Layers of Orchestration for Enterprise Grade AI

Agent evolution isn't fine-tuning.
Agent evolution isn't bigger models.
Agent evolution isn't just better prompts.

Agent evolution is building systems that learn from their own experience. In real-time.

Not from static prompts, knowledge base or finetuning, but through evolving context

Two recent papers from Google and Stanford lay out competing blueprints for this.

𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸 𝟭: Google's REASONINGBANK

This framework aims to create a memory of "distilled reasoning." It learns from an agent's successes 𝘢𝘯𝘥 failures.

𝗛𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀:
↳ After a task, the agent's trajectory is analyzed and distilled into structured memory items.

↳ It uses Memory-Aware Test-Time Scaling (MATTS). This allocates more compute to each task, generating multiple trajectories.

↳ This creates a feedback loop where better memory drives better exploration, which in turn builds superior memory.

𝗧𝗵𝗲 𝗚𝗼𝗼𝗱:
↳ 𝚁𝙴𝙰𝚂𝙾𝙽𝙸𝙽𝙶𝙱𝙰𝙽𝙺 transforms errors into "constructive signals" and "preventative lessons."

↳ The paper's key insight is that memory and scaling aren't independent and co-evolve with each other

𝗧𝗵𝗲 𝗚𝗮𝗽 (𝗠𝘆 𝗧𝗮𝗸𝗲):

↳ The "distillation" process relies on a single LLM's interpretation, which could be hard to control in production.

↳ MATTS implies a significant jump in inference-time compute, a barrier for low-latency or cost-sensitive applications.

𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸 𝟮: Stanford's Agentic Context Engineering (ACE)

ACE treats an agent's context as a structured, evolving "playbook."

𝗛𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀:
↳ 1. The Generator: An agent that performs the task using the current playbook. Its full trace is logged.

↳ 2. The Reflector: A separate analysis agent that inspects the Generator's trace. It identifies what went right or wrong and proposes a concrete "delta" to improve the playbook.

↳ 3. The Curator: A final, non-LLM process that takes the proposed delta and deterministically merges it into the playbook.

𝗧𝗵𝗲 𝗚𝗼𝗼𝗱:
↳ The paper reports a +10.6% average gain on agent benchmarks.

↳ The structured, incremental "delta updates" prevent "context collapse," where valuable knowledge is often lost during monolithic rewrites.

𝗪𝗵𝗶𝗰𝗵 𝗼𝗻𝗲 𝗶𝘀 𝗯𝗲𝘁𝘁𝗲𝗿? 
I think ACE is the Superior Architecture 

Here's why:

1. It's a Reliable, Debuggable Pipeline.
The Generator → Reflector → Curator model has separation of concerns. Each component has one job, which makes the system highly debuggable

2. It's Built for Scalable Learning.
ACE operates on "delta updates." It appends small, atomic chunks of knowledge, thus avoiding the risk of an LLM randomly deciding to "summarise" and destroy hard-won knowledge.

3. The Curation is Deterministic.
The final, critical step of integrating a new learning is handled by simple, non-LLM logic.

Over to you: do you think evolving context can lead to self-evolving AI?

♻️ Repost this if you're an AI systems engineer.

MCP is hot, but it isn't the only protocol
If you're building Agentic AI systems, you need to know these 5 protocols.

To scale intelligence across tools, agents, and humans, AI systems need shared standards for context, communication, and coordination.

These open protocols are shaping how agents talk, think, and work together.

Here’s what’s defining the future of interoperable AI:

1. Model Context Protocol (MCP)

↳ What it is:
An open protocol that standardizes how applications deliver context: data, tools, and prompts to LLMs.

↳ Why it matters:
LLMs rely on external context to function.
Without MCP, each app or data source requires custom integration per LLM.
MCP solves this with a plug-and-play architecture.

↳ Key features:
• Client-server architecture
• Lightweight servers expose capabilities
• Host apps connect and deliver structured context
• Enables tools and data to be reused across models

2. Agent Communication Protocol (ACP)

↳ What it is:
A universal communication protocol for AI agents, applications, and humans.

↳ Why it matters:
Today’s agents are fragmented across frameworks and infrastructures.
ACP introduces a standardized layer for secure, asynchronous, cross-platform message exchange.

↳ Key features:
• RESTful API structure
• Supports multiple message types
• Uses MIME types for extensibility
• Enables communication across any tech stack

3. Agent-to-Agent Protocol (A2A)

↳ What it is:
An open standard for direct, multi-modal, secure communication between AI agents.

↳ Why it matters:
Collaborative AI requires agents to work together deeply and over time.
A2A supports long-running, stateful, and secure interactions between agents from different platforms.

↳ Key features:
• Built on HTTP and JSON-RPC
• Enterprise-grade encryption
• Real-time state updates
• Supports text, audio, video streaming for multi-modal collaboration
  
4. Agent Network Protocol (ANP)

↳ What it is:
An open-source protocol for building a global-scale “agent internet.”

↳ Why it matters:
Current infrastructure isn’t optimized for billions of autonomous agents.
ANP addresses discovery, identity, secure communication, and scalable collaboration.

↳ Key features:
• Three-layer architecture 
• Decentralized identity & secure E2E messaging 
• Meta-protocols for communication negotiation 
• Application layer for capability registration & discovery
• Supports trusted agent interaction in distributed systems

5. Agent User Interaction Protocol (AG-UI)

↳ What it is:
A protocol for standardizing the connection between front-end UIs and AI agents.

↳ Why it matters:
AG-UI provides a consistent, event-driven way for users to interact with agents across systems.

↳ Key features:
• Event-driven architecture
• Standardized agent event types
• Supports bidirectional interaction.
• Streams real-time agent updates to clients

These protocols are the infrastructure for scalable AI ecosystems.

♻️ Reposting this helps your network upskill

I spent 104+ hours digging through papers and articles on Context Engineering so you don't have to. These are the only 6 resources worth your time.

𝗪𝗵𝗮𝘁 𝗶𝘀 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴?
It's not just an evolution of prompt engineering.

It’s the art of designing, managing, and optimizing all the information an AI model receives to perform a task. 

That includes:
🔹 The system prompt
🔹 Chat history
🔹 Retrieved data (from RAG systems)
🔹 Tool outputs
🔹 The model’s memory

It’s not just about what you say, it’s about everything the model sees. 

Done right, it leads to more intelligent, robust, and grounded outcomes.

Here are the 6 hand-picked resources:

1️⃣ Karpathy's Views on Context Engineering
🔗 https://lnkd.in/ghrbWKFr

2️⃣ LangChain’s Guide
🔗 https://lnkd.in/gDzC2uPF

3️⃣ Anthropic's Practical Guide
🔗 https://lnkd.in/gvy8vpxt

4️⃣ The 12-Factor Agents
🔗 https://lnkd.in/d6QCNrv3

5️⃣ Lessons from Building Manus
🔗 https://lnkd.in/g2kehh35

6️⃣ Academic Perspective
🔗 https://lnkd.in/gw2RyFaa

If you have to pick one, go with #5.

This field is just getting started, but it’s going to be central to building smart, agentic systems.

Have you found other great reads on this? 
Drop them in the comments.

♻️ Reposting this helps everyone in your network upskill.

Everyone is focused on Anthropic's learning hub. When the real edge for AI engineers is in their engineering blog

It’s a masterclass in how the teams behind Claude actually build, test, and scale their models. 

A compilation of production-grade wisdom.

Here’s a look at what you can find on this engineering arc:

• 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗠𝘂𝗹𝘁𝗶-𝗔𝗴𝗲𝗻𝘁 𝗦𝘆𝘀𝘁𝗲𝗺𝘀: 
A deep dive into their orchestrator-worker architecture and how they use prompt engineering for complex coordination.

• 𝗠𝗼𝗱𝗲𝗹 𝗕𝗲𝗵𝗮𝘃𝗶𝗼𝗿 & 𝗦𝗮𝗳𝗲𝘁𝘆: 
"Inverse Scaling" (why more compute isn't always better), 
"Subliminal Learning" (how models pick up hidden traits), 
and how they counter misuse.

• 𝗠𝗼𝗱𝗲𝗹 𝗜𝗻𝘁𝗲𝗿𝗻𝗮𝗹𝘀: 
Technical breakdowns on concepts like "Persona Vectors" to understand and steer model personality.

• 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗪𝗼𝗿𝗸𝗳𝗹𝗼𝘄𝘀: 
Actionable playbooks on turning models into reliable, goal-driven agents.

Their recent post on context engineering is a godsend for anyone building serious AI agents.

It’s one of the most practical breakdowns I’ve read on moving beyond simple "prompt engineering" to true 𝘴𝘺𝘴𝘵𝘦𝘮-𝘭𝘦𝘷𝘦𝘭 context management.

Here’s the breakdown:

• 𝗜𝘁’𝘀 𝗮𝗻 𝗔𝘁𝘁𝗲𝗻𝘁𝗶𝗼𝗻 𝗕𝘂𝗱𝗴𝗲𝘁 𝗣𝗿𝗼𝗯𝗹𝗲𝗺: 
↳ LLMs have a finite "attention budget." 
↳ Overload them with low-signal information, and you get "context rot." 
↳ The goal is to provide the smallest, highest-signal set of tokens.

• 𝗨𝘀𝗲 "𝗝𝘂𝘀𝘁-𝗶𝗻-𝗧𝗶𝗺𝗲" 𝗥𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹: 
↳ Don't stuff the context window. 
↳ Use lightweight identifiers (like file paths or URLs) and let the agent use tools to pull in the full data only when needed.

• 𝗘𝗺𝗯𝗿𝗮𝗰𝗲 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 𝗡𝗼𝘁𝗲-𝗧𝗮𝗸𝗶𝗻𝗴: 
↳ For long tasks, give the agent a <𝚜𝚌𝚛𝚊𝚝𝚌𝚑𝚙𝚊𝚍> to write down its thoughts, plans, and intermediate results. 
↳ This acts as an external memory and keeps it on track.

• 𝗖𝗼𝗺𝗽𝗮𝗰𝘁𝗶𝗼𝗻 𝗶𝘀 𝗞𝗲𝘆: 
↳ For long conversations, don't pass the entire chat history. 
↳ Use an agent to summarize previous turns, preserving key information while saving tokens.

𝗟𝗲𝘃𝗲𝗿𝗮𝗴𝗲 𝗦𝘂𝗯-𝗔𝗴𝗲𝗻𝘁 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲𝘀: 
↳ Decompose complex problems. 
↳ Have a main "orchestrator" agent that delegates sub-tasks to specialized agents, each with its own focused, clean context window.

Find the full engineering arc here:
https://lnkd.in/gZtZ-nuu

And the context engineering deep dive is a must-read:
https://lnkd.in/gvy8vpxt

What are you reading first? 👇

♻️ Repost to help your network upskill.

I've spent countless hours building and evaluating AI systems. This is the 3-part evaluation roadmap I wish I had on day one.

Evaluating an LLM system isn't one task. 
It's about measuring the performance of each component in the pipeline. 

You don't just test "the AI"; 
You test the retrieval, 
the generation, and 
the overall agentic workflow.

𝗣𝗮𝗿𝘁 𝟭: 𝗘𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗻𝗴 𝗥𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 (𝗧𝗵𝗲 𝗥𝗔𝗚 𝗣𝗶𝗽𝗲𝗹𝗶𝗻𝗲)
Your system is only as good as the context it retrieves.

𝗞𝗲𝘆 𝗠𝗲𝘁𝗿𝗶𝗰𝘀:
↳ 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗣𝗿𝗲𝗰𝗶𝘀𝗶𝗼𝗻: How much of the retrieved context is actually relevant vs. noise?
↳ 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗥𝗲𝗰𝗮𝗹𝗹: Did you retrieve all the necessary information to answer the query?
↳ 𝗡𝗗𝗖𝗚: How high up in the retrieved list are the most relevant documents?

𝗞𝗲𝘆 𝗥𝗲𝘀𝗼𝘂𝗿𝗰𝗲𝘀:
↳ 𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸: RAGAs Framework (Repo)
 https://lnkd.in/gAPdCRzh
↳ 𝗣𝗮𝗽𝗲𝗿: RAGAs Paper
 https://lnkd.in/gUKVe4ac

𝗣𝗮𝗿𝘁 𝟮: 𝗘𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗻𝗴 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻 (𝗧𝗵𝗲 𝗟𝗟𝗠'𝘀 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗲)
Once you have the context, how good is the model's actual output?

𝗞𝗲𝘆 𝗠𝗲𝘁𝗿𝗶𝗰𝘀:
↳ 𝗙𝗮𝗶𝘁𝗵𝗳𝘂𝗹𝗻𝗲𝘀𝘀: Does the answer stay grounded in the provided context, or does it start to hallucinate?
↳ 𝗥𝗲𝗹𝗲𝘃𝗮𝗻𝗰𝗲: Is the answer directly addressing the user's original prompt?
↳ 𝗜𝗻𝘀𝘁𝗿𝘂𝗰𝘁𝗶𝗼𝗻 𝗙𝗼𝗹𝗹𝗼𝘄𝗶𝗻𝗴: Did the model adhere to the output format you requested?

𝗞𝗲𝘆 𝗥𝗲𝘀𝗼𝘂𝗿𝗰𝗲𝘀:
↳ 𝗧𝗲𝗰𝗵𝗻𝗶𝗾𝘂𝗲: LLM-as-Judge Paper
 https://lnkd.in/gyhaU5CC
↳ 𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸𝘀: OpenAI Evals & LangChain Evals
 https://lnkd.in/g9rjmfGS
 https://lnkd.in/gmJt7ZBa

𝗣𝗮𝗿𝘁 𝟯: 𝗘𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗻𝗴 𝘁𝗵𝗲 𝗔𝗴𝗲𝗻𝘁 (𝗧𝗵𝗲 𝗘𝗻𝗱-𝘁𝗼-𝗘𝗻𝗱 𝗦𝘆𝘀𝘁𝗲𝗺)
Does the system actually accomplish the task from start to finish?

𝗞𝗲𝘆 𝗠𝗲𝘁𝗿𝗶𝗰𝘀:
↳ 𝗧𝗮𝘀𝗸 𝗖𝗼𝗺𝗽𝗹𝗲𝘁𝗶𝗼𝗻 𝗥𝗮𝘁𝗲: Did the agent successfully achieve its final goal? This is your north star.
↳ 𝗧𝗼𝗼𝗹 𝗨𝘀𝗮𝗴𝗲 𝗔𝗰𝗰𝘂𝗿𝗮𝗰𝘆: Did it call the correct tools with the correct arguments?
↳ 𝗖𝗼𝘀𝘁/𝗟𝗮𝘁𝗲𝗻𝗰𝘆 𝗽𝗲𝗿 𝗧𝗮𝘀𝗸: How many tokens and how much time did it take to complete the task?

𝗞𝗲𝘆 𝗥𝗲𝘀𝗼𝘂𝗿𝗰𝗲𝘀:
↳ 𝗚𝗼𝗼𝗴𝗹𝗲'𝘀 𝗔𝗗𝗞 𝗗𝗼𝗰𝘀:
 https://lnkd.in/g2TpCWsq
↳ 𝗗𝗲𝗲𝗽𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴(.)𝗔𝗜 𝗔𝗴𝗲𝗻𝘁𝘀 𝗘𝘃𝗮𝗹 𝗖𝗼𝘂𝗿𝘀𝗲:
 https://lnkd.in/gcY8WyjV

Stop testing your AI like a monolith. 
Start evaluating the components like a systems engineer. 
That's how you build systems that you can actually trust.

Save this roadmap.

What's the hardest part of your current eval pipeline?

♻️ Repost this to help your network build better systems.
➕ Follow Shivani Virdi for more.

I spent 102+ hours last week building and delivering a multi-agent system for Microsoft's Global Hackathon, and I wish I had this guide earlier. 

Here's the framework I took away for repeated success.

1. Start with the "Why" 

Focus on the core business value. Agentic systems are a powerful tool, but they aren't a silver bullet.

↳Pinpoint the user problem: 
What is the exact pain point you are solving?

↳Validate the need: 
Is an agentic system truly the 𝘣𝘦𝘴𝘵 solution

2. Blueprint Before Building 

I created a high-level, visual architecture of the entire system before diving in, and 

↳ Clarified the workflow: Forcing me to think through every single step, from input to final output.

↳ Defined data needs: Helping me immediately identify the required data sources and categories.

↳ Exposed roadblocks early: Allowing plan trade-offs upfront.

3. Know Your Stacksss (yes multiple)

In an enterprise setting, security, infrastructure, and resource constraints will dictate your choices.

↳ Understand the approved tools and security protocols you 𝘮𝘶𝘴𝘵 work within.

↳ Identify alternatives: I mapped out three potential tech stacks.

↳ My chosen stack hit roadblocks, but its flexibility meant I could adapt without starting over. Phew!

4. You Can't Outrun Unprepared Data 

It’s tempting to just dump all your wikis and specs into a RAG pipeline, but this will not scale.

↳ Humans vs. LLMs: Enterprise documentation is written for humans, who can connect the dots across multiple resources. LLMs can't.

↳ I spent two full days manually curating my knowledge base. Deleted 50 low-quality documents, created 10 highly specific, LLM-ready files.

5. Strive for Determinism

Enterprise systems demand reliable, repeatable outcomes. 

↳ Bridge the gap: Intent mapping to translate natural language into specific function calls.

↳ Build tools:
For outputs that required a very specific format, 
I built deterministic scripts to act as tools for the agent and worked backwards from code to natural language.


6. The Multi-Agent Trade-Off 
Understand the real costs.

↳ If a single, well-designed agent can solve the problem, stick with that.

↳ The trade-offs are real: 
Multi-agent systems add complexity in debugging, communication overhead, and operational cost.

7. Build One Agent at a Time

↳ Focus on a single agent. 
Finalize its prompt, define its inputs/outputs, and test every possible scenario in isolation.

↳ After each agent works on its own, begin connecting them into a cohesive system.

8. Simplify, Then Scale
Don't try to solve for every possible case on day one.

↳ Pick one small, highly targeted slice of your bigger scenario.

↳ Build for one, perfectly: Design the entire system to solve that single use case correctly. 
Expand from that stable, proven foundation.

P.S. I used the Azure AI Foundry (azure/ai-agents and azure/ai-projects sdk), and I can't recommend it enough for enterprise-level systems!

♻️ Repost this to help your network upskill

Here’s how I’d break into AI Engineering,

If I were starting from absolute zero.

One of the most common questions in my DMs:
"𝘏𝘰𝘸 𝘥𝘰 𝘐 𝘨𝘦𝘵 𝘴𝘵𝘢𝘳𝘵𝘦𝘥 𝘪𝘯 𝘈𝘐 𝘪𝘧 𝘐 𝘥𝘰𝘯’𝘵 𝘤𝘰𝘮𝘦 𝘧𝘳𝘰𝘮 𝘵𝘩𝘦 𝘧𝘪𝘦𝘭𝘥?"

So here’s a clear path I’d recommend:

𝟭. 𝗟𝗲𝗮𝗿𝗻 𝘁𝗼 𝗖𝗼𝗱𝗲 (𝘆𝗲𝘀, 𝘀𝘁𝗶𝗹𝗹 𝗲𝘀𝘀𝗲𝗻𝘁𝗶𝗮𝗹)
Forget the “coding is dead” fallacy.

To code 𝘸𝘪𝘵𝘩 AI, you need to be good 𝘸𝘪𝘵𝘩𝘰𝘶𝘵 it.

↳ Start with a programming language (𝗣𝘆𝘁𝗵𝗼𝗻, ML/DL ecosystem thrives on it)
↳ Understand 𝗢𝗢𝗣
↳ Practice 𝗗𝗦𝗔 (helps model real-world problems cleanly)

𝟮. 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻 (𝗿𝗲𝗮𝗹 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝘀𝘁𝗮𝗿𝘁𝘀 𝗵𝗲𝗿𝗲)
You’re building systems.
↳ Distributed Systems
↳ Databases
↳ Async APIs
↳ Security
↳ Observability
↳ Reliability

𝟯. 𝗗𝗮𝘁𝗮 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗙𝗼𝘂𝗻𝗱𝗮𝘁𝗶𝗼𝗻
You’ll work with data-intensive systems.
Understanding data pipelines, storage, and compute matters more than you think.

𝟰. 𝗠𝗟 𝗙𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝗮𝗹𝘀 (𝘁𝗵𝗲 '𝘄𝗵𝘆' 𝗯𝗲𝗵𝗶𝗻𝗱 𝘁𝗵𝗲 𝗺𝗼𝗱𝗲𝗹𝘀)
↳ Supervised & Unsupervised Learning
↳ Regression & Classification
↳ Real-world intuition > formulas

𝟱. 𝗗𝗲𝗲𝗽 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝗖𝗼𝗿𝗲 (𝗻𝗼𝗻-𝗻𝗲𝗴𝗼𝘁𝗶𝗮𝗯𝗹𝗲 𝘁𝗼𝗱𝗮𝘆)
↳ Neural Nets
↳ Backpropagation
↳ Hyperparameters

𝟲. 𝗡𝗟𝗣 𝗣𝗿𝗼𝗴𝗿𝗲𝘀𝘀𝗶𝗼𝗻 (𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 𝘁𝗵𝗲 𝗳𝗶𝗲𝗹𝗱’𝘀 𝗲𝘃𝗼𝗹𝘂𝘁𝗶𝗼𝗻)
↳ RNNs
↳ LSTMs
↳ Attention
↳ Transformers
Each phase reveals 𝘸𝘩𝘺 today’s LLMs work the way they do.

𝟳. 𝗟𝗟𝗠 𝗜𝗻𝘁𝗲𝗿𝗻𝗮𝗹𝘀
↳ How LLMs are trained
↳ Fine-tuning vs. instruction tuning
↳ Prompting, context windows, inference

𝟴. 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗔𝗜-𝗙𝗶𝗿𝘀𝘁 𝗦𝘆𝘀𝘁𝗲𝗺𝘀
↳ Prompt Engineering
↳ Retrieval-Augmented Generation (RAG)
↳ Context Engineering
↳ Agentic AI
↳ MLOps & LLMOps

𝗗𝗼 𝘆𝗼𝘂 𝗻𝗲𝗲𝗱 𝘁𝗼 𝗺𝗮𝘀𝘁𝗲𝗿 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴?
No. Tailor your path to your goals and experience

𝗛𝗼𝘄 𝗹𝗼𝗻𝗴 𝘄𝗶𝗹𝗹 𝗶𝘁 𝘁𝗮𝗸𝗲?
If you’re starting from zero, it’ll take time to build the engineering muscle

But it gets progressively easier and quicker

𝗜𝘀 𝗶𝘁 𝘄𝗼𝗿𝘁𝗵 𝗶𝘁?
1000%.
This is the most exciting time in tech, and the demand for engineers who can 𝘣𝘶𝘪𝘭𝘥 𝘸𝘪𝘵𝘩 𝘈𝘐 is only growing.

What would you add or remove from the list?

♻️ Reposting this helps someone who's confused find their way

I wish I had this checklist when I first started using MCP servers. Here are the 5 deadly sins of MCP implementation.

𝟭. 𝗧𝗿𝘂𝘀𝘁𝗶𝗻𝗴 𝗨𝘀𝗲𝗿 𝗜𝗻𝗽𝘂𝘁 (Leads to RCE)

↳ If your MCP tool takes user input and passes it to a system shell (os.system(f'process {user_file}')), you’re practically inviting Remote Code Execution.

↳ An attacker can inject malicious commands like "image.jpg; cat /etc/passwd" to steal sensitive data.

↳ Impact: Full system compromise, data theft, or lateral movement across the network.

↳ The Fix: Validate and sanitize all inputs. Avoid passing raw user data to system shells.

𝟮. 𝗘𝘅𝗽𝗼𝘀𝗶𝗻𝗴 𝗧𝗼𝗼𝗹 𝗠𝗲𝘁𝗮𝗱𝗮𝘁𝗮 (Leads to Data Exfiltration via Prompt Injection)

↳ Attackers can hide malicious instructions inside MCP tool metadata (e.g., its description).

↳ When passed to the LLM as trusted context, it executes them, for example, sending your conversation history to a malicious URL.

↳ Impact: Stealthy data leakage that bypasses application-layer defences.

↳ The Fix: Treat all context passed to the LLM as untrusted and implement strict output validation.

𝟯. 𝗟𝗲𝗮𝗸𝗶𝗻𝗴 𝗦𝗲𝗰𝗿𝗲𝘁𝘀 𝗶𝗻 𝗦𝗲𝗿𝘃𝗲𝗿𝘀 (Leads to Privilege Escalation)

↳ Your MCP server needs to talk to other APIs, which means it likely stores OAuth tokens or API keys.

↳ If an attacker finds a vulnerability (like RCE or path traversal), they can read these secrets from memory, environment variables, or insecure config files.

↳ Impact: Ability to impersonate the AI tool or its users, gaining full access to connected systems.

↳ The Fix: Use a secure secret management system. Never hardcode credentials.

𝟰. 𝗡𝗲𝗴𝗹𝗲𝗰𝘁𝗶𝗻𝗴 𝗧𝗿𝗮𝗻𝘀𝗽𝗼𝗿𝘁 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 (Leads to Man-in-the-Middle)

↳ Without enforced mutual TLS (mTLS) and host verification, an attacker can spin up a rogue MCP server.

↳ They can intercept, read, and manipulate all traffic between your agent and its tools.

↳ Impact: Complete loss of confidentiality and integrity for all queries, responses, and sensitive data.

↳ The Fix: Mandate mTLS for all communication between the MCP client and server.

𝟱. 𝗗𝗲𝗽𝗲𝗻𝗱𝗶𝗻𝗴 𝗼𝗻 𝗨𝗻𝘃𝗲𝗿𝗶𝗳𝗶𝗲𝗱 𝗟𝗶𝗯𝗿𝗮𝗿𝗶𝗲𝘀 (Leads to Supply Chain Attacks)

↳ A compromised open-source MCP dependency can inject malicious code into your system.

↳ This code may stay dormant until triggered, then deploy ransomware or exfiltrate credentials.

↳ Impact: A single poisoned dependency can cause widespread, hard-to-trace breaches across every system that uses it.

↳ The Fix: Harden the supply chain by verifying dependencies, pinning versions, and using security scanners.

𝗦𝗲𝗰𝘂𝗿𝗶𝗻𝗴 𝗠𝗖𝗣 𝗶𝗻 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻
MCP’s utility is undeniable, but it requires proactive security engineering.

↳ Threat-Model Everything
↳ Implement Zero Trust
↳ Enforce Least Privilege
↳ Harden Your Supply Chain
↳ Log and Monitor

Convenience is not a substitute for security.

♻️ Repost to help your network ship secure AI.

If I could only give one piece of advice for building reliable AI agents, it would be this: Master context engineering. Here's the playbook from Manus AI.

You don’t need to pick and choose models.
You need better context engineering.

That’s the core philosophy behind Manus
An agent deployed to millions.

And their new blog might be the most practical breakdown I’ve read on building production-grade agents.

1. Why context is the real lever

Manus made a strategic bet:
Skip fine-tuning. Engineer context.

It means faster iteration, modularity, and model independence.

“If model progress is the rising tide, we want Manus to be the boat—not the pillar stuck to the seabed.”

But it’s not plug-and-play.

Context engineering is experimental: 
• part architecture search, 
• prompt design, 
• and trial-by-debugging.

They call it Stochastic Graduate Descent

2. Optimise for the KV-cache, or pay 10x

In agents, the input:output token ratio is often 100:1.
So latency and cost are driven by KV-cache hit rate.

Cached tokens are ~10x cheaper.

And cache breaks come from tiny mistakes:
• Dynamic timestamps
• Reordered JSON keys
• Mid-context edits
• Prefix changes

Cache stability is survival.

3. Don’t remove tools. Mask them.

Dynamic tools are necessary, 
but swapping them mid-run?

It breaks cache and confuses the model.
Instead, Manus masks action logits at decode time.

It limits choices without touching context.
They also use structured naming (browser_, shell_, etc.) so tools are easily constrained by state.

4. External memory > massive context windows

Even 128K isn’t enough.
Agents deal with long logs, pages, PDFs, and models degrade on huge inputs.

So Manus treats the file system as true memory:
• Unlimited
• Persistent
• Structured
• Operable
• Cheap
The trick? Restorable compression.

Drop the content, keep the path. 
The model fetches on demand.

5. Recite objectives to guide attention

Long loops = drift.
LLMs forget what they’re solving.

So the agent recites its objective into a todo(.)md, appended at every step.

Not just relying on LLM memory, but smart use of attention recency to stay on task.

6. Leave your failures in

Erasing errors erases evidence.
And without evidence, the model can’t adapt.

Seeing a failed action + trace lets it implicitly update beliefs.

Failure recovery is a core sign of agentic behaviour.

7. Avoid over-imitation with controlled noise

Few-shot prompting often backfires.
The model overfits to the pattern, hallucinating or drifting.

Manus injects small variations in phrasing, order, format, keeping the model reasoning, not mimicking.

The takeaway?

Agent performance isn’t defined by the model.
It’s defined by context:
how it’s shaped, stabilised, and evolved.

This blog is a must-read for anyone building agents seriously:
https://lnkd.in/g2kehh35

♻️ Reposting this helps everyone in your network upskill

Taplio

Shivani Virdi's Linkedin Analytics

's Best Posts (last 30 days)

Want to drive more opportunities from LinkedIn?

Taplio

.css-1jgreyo{background-image:linear-gradient(284deg, rgba(39,43,72,1) 0%, rgba(33,47,183,1) 100%);color:transparent;-webkit-background-clip:text;background-clip:text;}Shivani Virdi's Linkedin Analytics

's Best Posts .css-qqfgvy{font-size:var(--chakra-fontSizes-md);}(last 30 days)

Want to drive more opportunities from LinkedIn?

Shivani Virdi's Linkedin Analytics

's Best Posts (last 30 days)