AI Limitations Overview

"More AI agents running doesn't mean there's more of you available - your cognitive bandwidth doesn't parallelize" Watch the full video: https://lnkd.in/gW8nwJHk from our fireside chat at Google I/O We are in a fascinating era of software development where the floor for building has been completely raised. The ability for anyone to spin up many background agents means code can be written while your laptop is closed. But as our toolsets expand, we are slamming into a very human bottleneck: the orchestration tax. Running 20 agents at once might make you feel incredibly busy, but feeling busy is not the same as being productive. When we offload problem-solving without intentionality, we risk falling into cognitive surrender - blindly merging an AI's output without understanding the underlying mechanics. When we stop thinking critically, we lose the ability to debug the very systems we are building. As the role of a developer shifts from writing syntax to writing intentions, we have to evolve our habits to protect our cognitive bandwidth. I personally try to be very intentional with what isolated tasks I delegate to background/cloud agents and which ones I pay more close attention to. How about you? #ai #programming #softwareengineering

A few self-driving taxis in San Francisco just demonstrated the real problem with autonomy. They were too rational. For a brief moment, several robotaxis aligned at an intersection and created a perfectly polite deadlock. No aggression. No improvisation. No human-style “you go, I’ll go.” Just algorithms waiting for clarity. And that is exactly why this moment matters. What interests me is that this was not a failure of sensing. The vehicles could see. The problem was social judgment. Because cities are not just physical systems. They are negotiation systems. They run on: → tiny signals → hesitation → assertiveness → eye contact → imperfect timing That is where autonomy gets much harder than people think. We are not only teaching machines how to detect objects and follow lanes. We are asking them to operate inside messy human environments where the right move is not always the most logical one. To me, that is the deeper lesson. The next frontier in self-driving is not just better perception. It is better judgment under uncertainty. And that is a much more difficult problem. What do you think matters more for autonomous vehicles now: seeing the road better, or learning how to navigate human ambiguity? #AI #AutonomousVehicles #SelfDrivingCars #FutureOfMobility #Innovation #Technology #SmartCities #MachineLearning #FutureOfWork

Agent memory has quickly become one of the most discussed topics in AI. As more teams start building real agent systems, one limitation keeps showing up: agents don’t remember much. Most agents today are essentially stateless. They can reason through tasks, call tools, and generate impressive responses, but once the session ends, the system forgets everything. And the conversation often gets simplified into two layers: 𝟏) 𝐒𝐡𝐨𝐫𝐭-𝐭𝐞𝐫𝐦 𝐦𝐞𝐦𝐨𝐫𝐲 = 𝐭𝐡𝐞 𝐜𝐨𝐧𝐭𝐞𝐱𝐭 𝐰𝐢𝐧𝐝𝐨𝐰 This is where agents keep conversation history, reasoning steps, and recent tool outputs.  But context windows are temporary. 𝟐) 𝐓𝐡𝐞𝐧 𝐭𝐡𝐞𝐫𝐞’𝐬 𝐥𝐨𝐧𝐠-𝐭𝐞𝐫𝐦 𝐦𝐞𝐦𝐨𝐫𝐲 This is where agents remember things across sessions: - user preferences - past interactions - knowledge collected over time - intermediate results from previous tasks And once you start thinking about long-term memory, the problem quickly shifts. This is really a data infrastructure problem. In many cases, long-term agent memory ends up living in the data layer. Which is why databases are starting to play a bigger role in modern AI systems. For example, 𝐌𝐨𝐧𝐠𝐨𝐃𝐁 has been building more capabilities around this idea. By integrating vector search directly into the database, application data and embeddings can live in the same system instead of being split across multiple tools. That makes it easier to store agent memory, retrieve relevant context with vector search, and keep embeddings synchronized with the underlying data. For teams building AI systems, this kind of architecture reduces a lot of the complexity around memory. If you're exploring this space, MongoDB’s Learning Hub has some useful courses and hands-on labs worth checking out https://lnkd.in/gazxytWP As agents start running longer workflows, memory quickly becomes part of the system architecture. Designing how that memory is stored, retrieved, and updated may turn out to be one of the most important pieces of agent design. #aiagents #agenticai #machinelearning #data #database

🚨 BREAKING: OpenAI has just launched ChatGPT Agent. Below are important privacy & security risks everybody should be aware of: Agentic AI applications differ from non-agentic ones particularly regarding the access rights/permissions they require in order to engage with external tools on the user's behalf. The more autonomous the agent, the more permissions/access rights it will require. For example, if a user wants an AI agent to search and buy a dress for them without asking further questions, besides accessing the internet, the AI agent will need to access their wallet. If the user wants the agent to schedule an event and invite friends, it will need access to at least the calendar and contact list. Having said that, any permission given to a third-party app or system has potential privacy and security risks. ChatGPT already presents privacy risks due to the way it's trained, the way it processes personal data, the user's privacy settings, and the type of personal information being input by users. The privacy risks from ChatGPT Agent will be exponentially higher as many people will be giving access rights to external tools containing personal information (calendar, email, wallet, and more). OpenAI knows that malicious actors will try to trick other people's AI agents into sharing private information, including address, email, phone, credit card information, and more. Sam Altman has just posted on X, recommending that people give agents "the minimum access required to complete a task." In many cases, the privacy and security risks of letting an AI agent perform a task will greatly outweigh any productivity benefits it can offer (but people will use AI agents anyway, because of hype, curiosity, or because their company is "AI first") Unfortunately, the pace of AI development is much faster than the pace of AI literacy. Most people haven't yet understood ChatGPT's privacy risks, but they will be thrown a new feature with exponentially MORE risks. - 👉 Never miss my analyses on AI: join my newsletter's 68,200+ subscribers (below).

The Voice Stack is improving rapidly. Systems that interact with users via speaking and listening will drive many new applications. Over the past year, I’ve been working closely with DeepLearning.AI, AI Fund, and several collaborators on voice-based applications, and I will share best practices I’ve learned in this and future posts. Foundation models that are trained to directly input, and often also directly generate, audio have contributed to this growth, but they are only part of the story. OpenAI’s RealTime API makes it easy for developers to write prompts to develop systems that deliver voice-in, voice-out experiences. This is great for building quick-and-dirty prototypes, and it also works well for low-stakes conversations where making an occasional mistake is okay. I encourage you to try it! However, compared to text-based generation, it is still hard to control the output of voice-in voice-out models. In contrast to directly generating audio, when we use an LLM to generate text, we have many tools for building guardrails, and we can double-check the output before showing it to users. We can also use sophisticated agentic reasoning workflows to compute high-quality outputs. Before a customer-service agent shows a user the message, “Sure, I’m happy to issue a refund,” we can make sure that (i) issuing the refund is consistent with our business policy and (ii) we will call the API to issue the refund (and not just promise a refund without issuing it). In contrast, the tools to prevent a voice-in, voice-out model from making such mistakes are much less mature. In my experience, the reasoning capability of voice models also seems inferior to text-based models, and they give less sophisticated answers. (Perhaps this is because voice responses have to be more brief, leaving less room for chain-of-thought reasoning to get to a more thoughtful answer.) When building applications where I need a more control over the output, I use agentic workflows to reason at length about the user’s input. In voice applications, this means I end up using a pipeline that includes speech-to-text (STT) to transcribe the user’s words, then processes the text using one or more LLM calls, and finally returns an audio response to the user via TTS (text-to-speech). This, where the reasoning is done in text, allows for more accurate responses. However, this process introduces latency, and users of voice applications are very sensitive to latency. When DeepLearning.AI worked with RealAvatar (an AI Fund portfolio company led by Jeff Daniel) to build an avatar of me, we found that getting TTS to generate a voice that sounded like me was not very hard, but getting it to respond to questions using words similar to those I would choose was. Even after much tuning, it remains a work in progress. You can play with it at https://lnkd.in/gcZ66yGM [At length limit. Full text, including latency reduction technique: https://lnkd.in/gjzjiVwx ]

Here are my Top AI Mistakes over the course of my career - and guess what thebtakeawaybis - deploying AI doesn’t guarantee transformation. Sometimes it just guarantees disappointment—faster (if these common pitfalls aren’t avoided). Over the 200+ deployments I’ve done most don’t fail because of bad models. They fail because of invisible landmines—pitfalls that only show up after launch. Here they are 👇 🔹 Strategic Insights Get Lost in Translation Pitfall: AI surfaces insights—but no one trusts them, interprets them, or acts on them. Why: Workforce mistrust OR lack of translators who can bridge business and technical understanding. 🔹 Productivity Gets Slower, Not Faster Pitfall: AI adds steps, friction, and tool-switching to workflows. Why: You automated a task without redesigning the process. 🔹 Forecasting Goes From Bad → Biased Pitfall: AI models project confidently on flawed data. Why: Lack of historical labeling, bad quality, and no human feedback loop. 🔹 The Innovation Feels Generic, Not Differentiated Pitfall: You used the same foundation model as your competitor—without any fine-tuning. Why: Prompting ≠ Strategy. Models ≠ Moats. IP-driven data creates differentiation - this is why data security is so important, so you can use the important data. 🔹 Decision-Making Slows Down Pitfall: Endless validation loops between AI output and human oversight. Why: No authorization protocols. Everyone waits for consensus. 🔹 Customer Experience Gets Worse Pitfall: AI automates responses but kills nuance and empathy. Why: Too much optimization, not enough orchestration. 👇 Drop your biggest post-deployment pitfall below ( and it’s okay to admit them - promise) #AITransformation #AIDeployment #HumanCenteredAI #DigitalExecution #FutureOfWork #AILeadership #EnterpriseAI

I frequently see conversations where terms like LLMs, RAG, AI Agents, and Agentic AI are used interchangeably, even though they represent fundamentally different layers of capability. This visual guides explain how these four layers relate—not as competing technologies, but as an evolving intelligence architecture. Here’s a deeper look: 1. 𝗟𝗟𝗠 (𝗟𝗮𝗿𝗴𝗲 𝗟𝗮𝗻𝗴𝘂𝗮𝗴𝗲 𝗠𝗼𝗱𝗲𝗹) This is the foundation. Models like GPT, Claude, and Gemini are trained on vast corpora of text to perform a wide array of tasks: – Text generation – Instruction following – Chain-of-thought reasoning – Few-shot/zero-shot learning – Embedding and token generation However, LLMs are inherently limited to the knowledge encoded during training and struggle with grounding, real-time updates, or long-term memory. 2. 𝗥𝗔𝗚 (𝗥𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹-𝗔𝘂𝗴𝗺𝗲𝗻𝘁𝗲𝗱 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻) RAG bridges the gap between static model knowledge and dynamic external information. By integrating techniques such as: – Vector search – Embedding-based similarity scoring – Document chunking – Hybrid retrieval (dense + sparse) – Source attribution – Context injection …RAG enhances the quality and factuality of responses. It enables models to “recall” information they were never trained on, and grounds answers in external sources—critical for enterprise-grade applications. 3. 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁 RAG is still a passive architecture—it retrieves and generates. AI Agents go a step further: they act. Agents perform tasks, execute code, call APIs, manage state, and iterate via feedback loops. They introduce key capabilities such as: – Planning and task decomposition – Execution pipelines – Long- and short-term memory integration – File access and API interaction – Use of frameworks like ReAct, LangChain Agents, AutoGen, and CrewAI This is where LLMs become active participants in workflows rather than just passive responders. 4. 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗔𝗜 This is the most advanced layer—where we go beyond a single autonomous agent to multi-agent systems with role-specific behavior, memory sharing, and inter-agent communication. Core concepts include: – Multi-agent collaboration and task delegation – Modular role assignment and hierarchy – Goal-directed planning and lifecycle management – Protocols like MCP (Anthropic’s Model Context Protocol) and A2A (Google’s Agent-to-Agent) – Long-term memory synchronization and feedback-based evolution Agentic AI is what enables truly autonomous, adaptive, and collaborative intelligence across distributed systems. Whether you’re building enterprise copilots, AI-powered ETL systems, or autonomous task orchestration tools, knowing what each layer offers—and where it falls short—will determine whether your AI system scales or breaks. If you found this helpful, share it with your team or network. If there’s something important you think I missed, feel free to comment or message me—I’d be happy to include it in the next iteration.

AI security/securing the use of AI is going to kill me. I use Claude Code almost daily. It's a problem.... Here's what I have to change AGAIN this week. Security researcher Ari Marzuk disclosed 30+ vulnerabilities across AI coding tools. Cursor. GitHub Copilot. Windsurf. Claude Code. All of them. He called it IDEsaster. The attack chain includes prompt injection, hijacking LLM context, and auto-approved tool calls executing without permission. Then, legitimate IDE features are weaponized for data exfiltration and RCE. Your .env files. Your API keys. Your source code. Accessible through features you thought were safe. Most studies I read claim that around 85% of developers now use AI coding tools daily. Most have no idea their IDE treats its own features as inherently trusted. 𝗦𝗼... 𝗮𝗳𝘁𝗲𝗿 𝗿𝗲𝘃𝗶𝗲𝘄𝗶𝗻𝗴 𝗔𝗿𝗶'𝘀 𝗿𝗲𝘀𝗲𝗮𝗿𝗰𝗵, 𝗵𝗲𝗿𝗲'𝘀 𝗜 𝘄𝗶𝗹𝗹 𝗯𝗲 𝗱𝗼𝗶𝗻𝗴... Be warned: All this is SO much easier said than done! Audit every MCP server connection. Checked for tool poisoning vectors where legitimate tools might parse attacker-controlled input from GitHub PRs or web content. Removed servers I couldn't verify. Disabled auto-approve for file writes. The attack chains weaponize configuration files and project instructions like .claude/settings.json and CLAUDE.md. One malicious write to these files can alter agent behavior or achieve code execution without additional user interaction. Move all credentials to a secrets manager. No .gitignored .env files in agent-accessible directories. API keys live in 1Password CLI. Environment variables inject at runtime through a wrapper script the LLM never sees. Start running Claude Code in isolated containers. Mounted volumes limited to specific project directories. No access to ~/.ssh, ~/.aws, or ~/.config. If the agent gets compromised, blast radius stays contained. Enable all security warnings. Claude Code added explicit warnings for JSON schema exfiltration and settings file modifications. These exist because Anthropic knows the attack surface. Add pre-commit hooks for hidden characters. Prompt injections hide in pasted URLs, READMEs, and file names using invisible Unicode. Flag non-ASCII characters in any file the agent might ingest. The fix isn't to stop using AI coding tools. The fix is to stop trusting them implicitly. What controls do you have for AI tools with write access to your codebase? 👉 Follow for more AI and cybersecurity insights with the occasional rant #AISecurity #DevSecOps

The NYT just reported that patients are uploading entire medical records into chatbots - but the risks are not what most people think. Patients are pasting labs, imaging, clinical notes, and oncology reports directly into LLMs. • 26-year-old told her labs “most likely” indicated a pituitary tumor. MRI: normal • 63-year-old advised to escalate to catheterization. Found ~85% LAD stenosis Because of how the chatbot responds, many assume the AI reasons about their symptoms and medical record the same way a clinician does. But AI systems are capable of both meaningful help and serious error, without any calibration signal visible to the user. Most worry about wrong AI recommendations. But the bigger risk is what the AI does not say. 📊 Harm preprint study A new Stanford-Harvard study (David Wu, MD, PhD, Fateme (Fatima) Nateghi, Adam Rodman, Jonathan H. Chen et al.) evaluated 31 models on 100 real outpatient eConsult cases across 10 specialties: - 4,249 management actions - 12,747 expert ratings Severe harm per 100 cases: - Best models: ~12–15 - Worst models: ~40 ~77% of severe harms were omissions: - Not ordering a critical test - Missing a needed referral - Neglecting follow-up suggestions 🔷 Additional findings: 1) Top models outperformed generalists using conventional resources (though these were difficult eConsult cases that PCPs were posing to specialists) 2) No link between safety and model size, recency, “reasoning modes,” or standard benchmarks 3) Multi-agent + RAG approaches reduced harm; heterogeneous ensembles had ~6× higher odds of top-quartile safety 📌 Implications When a patient asks AI for medical advice, the primary risk is not incorrect recommendations. It's neglecting critical actions a clinician might suggest (notably, humans also make a lot of mistakes). ⚠️ Why this matters 1) 2/3 of US physicians report using LLMs, and millions of patients. Errors will become more subtle as models get better. Both harms of omissions and commission will become harder for clinicians (and especially patients) to detect. 2) Sampling a few outputs is not enough: clinical AI evaluation needs explicit, systematic harm measurement on real cases, not just performance or accuracy on knowledge benchmarks. 3) If we don’t measure omission harms, we will systematically underestimate risk. 🔴 Open Call: State of Clinical AI Report (Jan 2026) The ARISE Network (Stanford + Harvard) is compiling a State of Clinical AI Report for 2026. Audience: health system leaders, clinicians, researchers, tech/pharma, media, investors 2025 peer reviewed and preprint studies within scope: • Clinical AI (doctor- or patient-facing) • Benchmarks, evaluations, real-world deployments, prospective trials • Workflow, outcomes, and implementation studies 📅 Submission deadline: Dec 21, 2025 - Comment with study link + 1–2 sentences on key findings and why it matters - We will follow up with a one-slide reference example for invited submissions

Palo Alto Networks (𝘁𝗵𝗲 𝘄𝗼𝗿𝗹𝗱’𝘀 𝗹𝗮𝗿𝗴𝗲𝘀𝘁 𝗰𝘆𝗯𝗲𝗿𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗳𝗶𝗿𝗺) 𝗷𝘂𝘀𝘁 𝗲𝘅𝗲𝗰𝘂𝘁𝗲𝗱 𝗮𝘁𝘁𝗮𝗰𝗸𝘀 𝗼𝗻 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁𝘀. 𝗛𝗲𝗿𝗲’𝘀 𝘄𝗵𝗮𝘁 𝘁𝗵𝗲𝘆 𝗳𝗼𝘂𝗻𝗱: ⬇️ They ran real-world attack simulations on two identical AI agents. Both agents had the same purpose, did the same tasks, and used the same tools — the only difference was the framework behind them: one used CrewAI, the other Microsoft AutoGen. 𝗧𝗟;𝗗𝗥: 𝗕𝗼𝘁𝗵 𝗮𝗴𝗲𝗻𝘁𝘀 𝗳𝗮𝗶𝗹𝗲𝗱! The key lesson? It’s not about the framework. It’s about how you build, what you expose, and what you mistakenly assume is secure. 𝗛𝗲𝗿𝗲 𝗮𝗿𝗲 6 𝘁𝗵𝗶𝗻𝗴𝘀 𝘁𝗵𝗮𝘁 𝘀𝘁𝗼𝗼𝗱 𝗼𝘂𝘁 𝘁𝗼 𝗺𝗲 𝗮𝗯𝗼𝘂𝘁 𝘁𝗵𝗶𝘀 𝗿𝗲𝗽𝗼𝗿𝘁: 1. 𝗣𝗿𝗼𝗺𝗽𝘁 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 𝗦𝘁𝗶𝗹𝗹 𝗪𝗼𝗿𝗸𝘀 → It’s way easier than you think. Attackers can hide malicious instructions inside user inputs or documents — and if your agent reads it, it might follow those hidden commands. No jailbreak needed. Just poor design. 2. 𝗧𝗼𝗼𝗹𝘀 𝗔𝗿𝗲 𝘁𝗵𝗲 𝗥𝗲𝗮𝗹 𝗥𝗶𝘀𝗸 → Your fancy toolset is probably wide open. Agents often have access to files, APIs, or other systems. If these tools don’t have checks in place, attackers can trigger them — and do damage using the agent’s own capabilities. 3. 𝗔𝗴𝗲𝗻𝘁𝘀 𝗖𝗮𝗻 𝗟𝗲𝗮𝗸 𝗜𝗱𝗲𝗻𝘁𝗶𝘁𝘆 → Your agent might "think" it’s someone else. If you don’t control session state and role tightly, an agent can accidentally (or intentionally) reveal secrets, switch roles, or act on behalf of the wrong user. Think: bot impersonates an admin. 4. 𝗠𝘂𝗹𝘁𝗶-𝗔𝗴𝗲𝗻𝘁 ≠ 𝗦𝗮𝗳𝗲 𝗯𝘆 𝗗𝗲𝘀𝗶𝗴𝗻 → More agents = more chaos. Just because agents talk to each other doesn’t mean they can be trusted. Attackers can poison one message, and the whole team of agents starts doing the wrong thing. 5. 𝗦𝗮𝗻𝗱𝗯𝗼𝘅𝗶𝗻𝗴 ≠ 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 → Code execution is risky — even in a “safe” environment. If you’re letting agents run code, you need real isolation. One misstep (like mounting the wrong file system) and your so-called sandbox becomes a front door for attackers. 6. 𝗦𝗲𝗰𝘂𝗿𝗲 𝘁𝗵𝗲 𝗪𝗵𝗼𝗹𝗲 𝗖𝗵𝗮𝗶𝗻 → It’s not just the prompt. It’s everything. You can’t patch one layer and call it secure. You need to think about the full flow: the user input, the prompt design, the tool stack, the memory system, and the runtime environment. 𝗠𝗼𝘀𝘁 𝘁𝗲𝗮𝗺𝘀 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮𝗴𝗲𝗻𝘁𝘀 𝘁𝗼𝗱𝗮𝘆 𝗮𝗿𝗲 𝘀𝗵𝗶𝗽𝗽𝗶𝗻𝗴 𝗠𝗩𝗣𝘀 𝘄𝗶𝘁𝗵 𝘇𝗲𝗿𝗼 𝗿𝗲𝘀𝗶𝗹𝗶𝗲𝗻𝗰𝗲 𝗯𝗮𝗸𝗲𝗱 𝗶𝗻. 𝗕𝗲𝗰𝗮𝘂𝘀𝗲 “𝗶𝘁 𝘄𝗼𝗿𝗸𝘀” 𝗶𝘀𝗻’𝘁 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗮𝘀 “𝗶𝘁’𝘀 𝘀𝗲𝗰𝘂𝗿𝗲.” 𝗔𝗻𝗱 𝗮𝘀 𝘁𝗵𝗲𝘀𝗲 𝗮𝗴𝗲𝗻𝘁𝘀 𝗴𝗲𝘁 𝗺𝗼𝗿𝗲 𝗰𝗮𝗽𝗮𝗯𝗹𝗲, 𝗺𝗼𝗿𝗲 𝗮𝘂𝘁𝗼𝗻𝗼𝗺𝗼𝘂𝘀, 𝗮𝗻𝗱 𝗺𝗼𝗿𝗲 𝗰𝗼𝗻𝗻𝗲𝗰𝘁𝗲𝗱 —𝘁𝗵𝗲𝘆 𝘀𝘁𝗼𝗽 𝗯𝗲𝗶𝗻𝗴 𝗲𝘅𝗽𝗲𝗿𝗶𝗺𝗲𝗻𝘁𝘀. 𝗧𝗵𝗲𝘆 𝘀𝘁𝗮𝗿𝘁 𝗯𝗲𝗰𝗼𝗺𝗶𝗻𝗴 𝗮𝘁𝘁𝗮𝗰𝗸 𝘀𝘂𝗿𝗳𝗮𝗰𝗲𝘀. More info in the comments!