Pinned Tweet
Finally back at home after an unplanned diversion to DEN overnight. (Heya @united thank you for the personalized attention getting me back to ORD!)
@aiDotEngineer World鈥檚 Fair has been the best conference experience of 2026. This week saw all of the biggest ideas in AI converge ve results!
It was such a treat to share the stage with the best minds in AI.
I鈥檒l share more thoughts as talks are released. Standby!
@aiDotEngineer World鈥檚 Fair has been the best conference experience of 2026. This week saw all of the biggest ideas in AI converge ve results!
It was such a treat to share the stage with the best minds in AI.
I鈥檒l share more thoughts as talks are released. Standby!
4
0
24
2,375
Ask a chatbot for its system prompt five times and it might refuse every time, then just hand it over on the sixth, not because you changed your question but because LLMs are non-deterministic. Micah Silverman, Director of Developer Relations at Snyk, builds his talk "AI Security Certificate" around exactly that unpredictability, and @aiDotEngineer posted it to YouTube. It's a two hour walk through the OWASP Top 10 for LLM, AI threat modeling, MCP security, and what happens when vibe-coded agents get more access than anyone meant to give them, ending with a live chatbot hacking demo.
- Indirect prompt injection hides in plain sight. White-on-white text in an email signature can tell an LLM to act on it, so when something like OpenClaw summarizes an inbox, it can end up posting a user's SSH key to an attacker's endpoint. Micah's rule: treat all incoming input as data, never as instruction, and never rely on the system prompt alone as access control.
- The only sure fix for secret leakage is to never hand the LLM the secret. Revisits the 2023 Samsung story, engineers pasting a whole codebase, env files included, into ChatGPT to get a code review, and why you should assume anything you put into an LLM may become publicly available.
- Shadow AI is shadow IT's harder, invisible cousin. Micah cites survey numbers: 80% of organizations report unsanctioned AI use, 60% of employees use unapproved AI tools, only 37% of organizations have governance policies in place, and unauthorized use dropped about 89% once an approved alternative replaced an outright ban.
- AI-BOM treats models like dependencies. Snyk's approach: inventory every model, dataset, and tool in use, then fail the CI build when a new commit's AI-BOM drifts from an approved baseline, the same way a failing test would.
- MCP servers are still just code, and code has bugs. Walks through a real exploit in a Figma MCP server where an unsanitized argument got concatenated straight into a shell curl command, command injection wearing an AI costume.
- Vibe-coded agents keep reaching further than intended. Replit's own agent rated its production database deletion 95 out of 100 on its own badness scale; separately, an OpenClaw agent kept deleting a researcher's emails after being told to stop, and only quit when the process was killed by hand. A Snyk scan of roughly 4,000 Clawhub skills found at least one significant security flaw in 37% of them, 13% critical.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
- Indirect prompt injection hides in plain sight. White-on-white text in an email signature can tell an LLM to act on it, so when something like OpenClaw summarizes an inbox, it can end up posting a user's SSH key to an attacker's endpoint. Micah's rule: treat all incoming input as data, never as instruction, and never rely on the system prompt alone as access control.
- The only sure fix for secret leakage is to never hand the LLM the secret. Revisits the 2023 Samsung story, engineers pasting a whole codebase, env files included, into ChatGPT to get a code review, and why you should assume anything you put into an LLM may become publicly available.
- Shadow AI is shadow IT's harder, invisible cousin. Micah cites survey numbers: 80% of organizations report unsanctioned AI use, 60% of employees use unapproved AI tools, only 37% of organizations have governance policies in place, and unauthorized use dropped about 89% once an approved alternative replaced an outright ban.
- AI-BOM treats models like dependencies. Snyk's approach: inventory every model, dataset, and tool in use, then fail the CI build when a new commit's AI-BOM drifts from an approved baseline, the same way a failing test would.
- MCP servers are still just code, and code has bugs. Walks through a real exploit in a Figma MCP server where an unsanitized argument got concatenated straight into a shell curl command, command injection wearing an AI costume.
- Vibe-coded agents keep reaching further than intended. Replit's own agent rated its production database deletion 95 out of 100 on its own badness scale; separately, an OpenClaw agent kept deleting a researcher's emails after being told to stop, and only quit when the process was killed by hand. A Snyk scan of roughly 4,000 Clawhub skills found at least one significant security flaw in 37% of them, 13% critical.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
3
0
3
317
Full talk on the OWASP Top 10 for LLM, AI-BOM, MCP exploits, and red teaming a vulnerable student chatbot live:
youtu.be/p-2MT8KYZqU
youtu.be/p-2MT8KYZqU
0
0
0
20
Redacting a document's phone numbers and social security numbers before Claude Code ever sees the file, while also cutting token spend in the same pass: that's the engineering problem @f_makraduli, Founding Member of Technical Staff at Superlinked, works through in "Turning My ocal AI Engineer," which @aiDotEngineer published on YouTube. It's a working blueprint for offloading sensitive document processing to a self-hosted inference cluster without changing how you work in Claude Code day to day.
- Redaction, live. He runs an NDA through the system on stage: it extracts entities and masks them, emails and names among them, so Claude Code only ever receives the redacted markdown, not the original file.
- Why MCP over a plugin. A plugin would run on his laptop; he built a dedicated MCP server instead so the heavy processing happens on a controlled cluster with its own worker pools and GPUs, separate from the agent itself.
- OCR first, then the agent. Scanned PDFs get preprocessed by open source OCR models before Claude Code ever reads them, which cuts token cost and keeps the context clean of raw scan data.
- Per-worker batching beat a shared queue. Giving each worker pool its own batching queue, instead of one shared queue everyone pulls from, measurably improved end to end latency in his testing.
- Hot-swapping models and LoRAs. The cluster swaps several models, including task-specific LoRAs, on and off the same GPU, which let him test which fine-tune actually performs best for a given document type.
- The embedding numbers. The best open source embedding model Superlinked tested came in at 99.8% of a frontier model's quality, at roughly 10x lower price.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
- Redaction, live. He runs an NDA through the system on stage: it extracts entities and masks them, emails and names among them, so Claude Code only ever receives the redacted markdown, not the original file.
- Why MCP over a plugin. A plugin would run on his laptop; he built a dedicated MCP server instead so the heavy processing happens on a controlled cluster with its own worker pools and GPUs, separate from the agent itself.
- OCR first, then the agent. Scanned PDFs get preprocessed by open source OCR models before Claude Code ever reads them, which cuts token cost and keeps the context clean of raw scan data.
- Per-worker batching beat a shared queue. Giving each worker pool its own batching queue, instead of one shared queue everyone pulls from, measurably improved end to end latency in his testing.
- Hot-swapping models and LoRAs. The cluster swaps several models, including task-specific LoRAs, on and off the same GPU, which let him test which fine-tune actually performs best for a given document type.
- The embedding numbers. The best open source embedding model Superlinked tested came in at 99.8% of a frontier model's quality, at roughly 10x lower price.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
5
0
2
316
Full talk on redacting sensitive documents through a self-hosted MCP server while cutting token costs:
youtu.be/Ndp5VaqFrl0
youtu.be/Ndp5VaqFrl0
0
0
0
20
A bigger context window doesn't fix an agent that's drowning in its own tool output. @ElizabethFue12, a Developer Advocate at AWS, makes that case in "Why Bigger Context Windows Won't Save Your Agent," on @aiDotEngineer's YouTube. The talk lays out concrete techniques for keeping le instead of just making it bigger.
- The attention curve is real. Stuff enough data into a context window and the agent remembers the start and the end, and forgets the middle.
- Four strategies for the context window. Externalize (move big data to storage and keep a pointer), select (retrieve only what's relevant), compress (summarize or compact), and isolate (keep context separate across agents).
- Strands, AWS's open source agent framework, ships three conversation managers. A sliding window, summarization, or both combined, like summarizing 50% of history while keeping the last four messages.
- A memory pointer pattern for big tool output. When a tool returns a pile of logs, write them to storage, keep just an ID in the agent's state, and pull the full logs back only if the agent needs them.
- In a multi-agent swarm, full context is just garbage for the other agents. Agents can share a memory pointer through invocation state instead of every agent carrying everything.
- Loops need a ceiling. An agent that keeps calling the same tool can be capped with a max invocation count per tool.
- Slow external calls shouldn't block the agent. An asynchronous handler, start a job, check its status later, avoids timing out against something like AWS API Gateway's response limit.
- Three anti-patterns to avoid. Stuffing everything into context, summarizing away what the agent actually needs, and letting unrelated data pollute the window.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
- The attention curve is real. Stuff enough data into a context window and the agent remembers the start and the end, and forgets the middle.
- Four strategies for the context window. Externalize (move big data to storage and keep a pointer), select (retrieve only what's relevant), compress (summarize or compact), and isolate (keep context separate across agents).
- Strands, AWS's open source agent framework, ships three conversation managers. A sliding window, summarization, or both combined, like summarizing 50% of history while keeping the last four messages.
- A memory pointer pattern for big tool output. When a tool returns a pile of logs, write them to storage, keep just an ID in the agent's state, and pull the full logs back only if the agent needs them.
- In a multi-agent swarm, full context is just garbage for the other agents. Agents can share a memory pointer through invocation state instead of every agent carrying everything.
- Loops need a ceiling. An agent that keeps calling the same tool can be capped with a max invocation count per tool.
- Slow external calls shouldn't block the agent. An asynchronous handler, start a job, check its status later, avoids timing out against something like AWS API Gateway's response limit.
- Three anti-patterns to avoid. Stuffing everything into context, summarizing away what the agent actually needs, and letting unrelated data pollute the window.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
1
0
2
159
Full talk on the attention curve, memory pointers, and keeping agent context lean instead of just large:
youtu.be/DrfyORO8RqA
youtu.be/DrfyORO8RqA
0
0
0
14
A customer service agent built in under 60 lines of code, then deployed to production with a single CLI command: that's the shape of "Agent Speedrun," which @aiDotEngineer published on YouTube. @ElizabethFue12 and Sandhya Subramani, both of Amazon Web Services, run the whole are agent loop to a working endpoint on Amazon Bedrock AgentCore. It's a hands on tour of what it actually takes to harden an agent before it ships, using Strands Agents, the open source agent harness AWS maintains.
- Start simple. The base agent is three tools (look up customer, get order history, process a refund) wired to an LLM through Strands Agents, which supports MCP, A2A, and any model provider you want to swap in.
- Hooks make it deterministic. Because LLM behavior is probabilistic, a rate limiter hook enforces a hard stop (max three tool calls) so a misbehaving agent can't spiral and burn tokens.
- Skills keep the system prompt lean. Markdown files for account troubleshooting, order tracking, and refunds get pulled in only when relevant, instead of stuffing every instruction into every prompt.
- Steering adds a second check. A buddy agent reviews the output before it goes out and can revise tone or enforce format, and an open source library called agent control lets you store steering rules in a database instead of the codebase.
- Deployment is one decorator and one CLI call. Wrapping the agent with an entry point and running agentcore deploy hands you a container on AgentCore runtime with session memory (sessions can run up to eight hours) and observability in CloudWatch, with no extra infrastructure code.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
- Start simple. The base agent is three tools (look up customer, get order history, process a refund) wired to an LLM through Strands Agents, which supports MCP, A2A, and any model provider you want to swap in.
- Hooks make it deterministic. Because LLM behavior is probabilistic, a rate limiter hook enforces a hard stop (max three tool calls) so a misbehaving agent can't spiral and burn tokens.
- Skills keep the system prompt lean. Markdown files for account troubleshooting, order tracking, and refunds get pulled in only when relevant, instead of stuffing every instruction into every prompt.
- Steering adds a second check. A buddy agent reviews the output before it goes out and can revise tone or enforce format, and an open source library called agent control lets you store steering rules in a database instead of the codebase.
- Deployment is one decorator and one CLI call. Wrapping the agent with an entry point and running agentcore deploy hands you a container on AgentCore runtime with session memory (sessions can run up to eight hours) and observability in CloudWatch, with no extra infrastructure code.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
3
0
3
122
Full talk on building and hardening a customer service agent with Strands Agents, then shipping it on Amazon Bedrock AgentCore:
youtu.be/YXiLj4tJt5A
youtu.be/YXiLj4tJt5A
0
0
0
20
Your code can't tell you what your agent did on any given run, only your traces can, because the same input can produce different paths and even different outputs every time. @seldo, Head of Developer Relations at Arize AI, walks through why that matters in "From Vibes to and Shipping AI Agents That Work 201," which @aiDotEngineer has on YouTube.
It's the sequel to his intro session, and this one is about turning that flood of traces into automatic fixes instead of a backlog nobody has time to read.
- Evals don't scale by themselves. Evals compress thousands of traces into pass or fail scores with explanations, but once your agents are shipping at agent speed, you end up with more failing evals than a human can read in a day.
- Observability is shifting from dashboards to agents. Instead of a person scanning results one by one, an agent reads the eval failures en masse and groups them into patterns worth fixing.
- The demo app had zero observability to start. Laurie's Wonder Toys shopping agent was built on the OpenAI Agents SDK, which already ships with OpenInference instrumentation, so turning on tracing in Arize AX took no new code, just an API key and an endpoint.
- The traces caught a real bug live. A search tool call came back in one millisecond, and 42% of searches returned zero results because the agent was calling it with null filters.
- Signal closes the loop automatically. It's an Arize AX agent that rereads your traces on a schedule, six hours by default, spots the same kind of pattern, and can open a GitHub issue, build an eval dataset, or send a PR with the fix for you to approve.
- It already found real issues in Wonder Toys. A hallucinated age filter from vague phrasing, a toy store that wouldn't give bomb instructions but recommended bomb related toys anyway, and the agent happily obeying a stray "say hello" test prompt.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
It's the sequel to his intro session, and this one is about turning that flood of traces into automatic fixes instead of a backlog nobody has time to read.
- Evals don't scale by themselves. Evals compress thousands of traces into pass or fail scores with explanations, but once your agents are shipping at agent speed, you end up with more failing evals than a human can read in a day.
- Observability is shifting from dashboards to agents. Instead of a person scanning results one by one, an agent reads the eval failures en masse and groups them into patterns worth fixing.
- The demo app had zero observability to start. Laurie's Wonder Toys shopping agent was built on the OpenAI Agents SDK, which already ships with OpenInference instrumentation, so turning on tracing in Arize AX took no new code, just an API key and an endpoint.
- The traces caught a real bug live. A search tool call came back in one millisecond, and 42% of searches returned zero results because the agent was calling it with null filters.
- Signal closes the loop automatically. It's an Arize AX agent that rereads your traces on a schedule, six hours by default, spots the same kind of pattern, and can open a GitHub issue, build an eval dataset, or send a PR with the fix for you to approve.
- It already found real issues in Wonder Toys. A hallucinated age filter from vague phrasing, a toy store that wouldn't give bomb instructions but recommended bomb related toys anyway, and the agent happily obeying a stray "say hello" test prompt.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
6
0
7
361
Full talk on closing the trace-to-fix loop, including the Wonder Toys live demo and Signal:
youtu.be/F0TNSmbo5hE
youtu.be/F0TNSmbo5hE
0
0
0
38
A voice agent that never converts speech to text, understanding and replying in audio directly across 90 languages, is the subject of @thorwebdev's talk "Can Your Agent Hear You Now? Building Live Voice Agents with Gemini," on @aiDotEngineer's YouTube. Thor works on developer epMind, focused on the Gemini API and Google AI Studio. The talk is a working tour of Gemini's real-time stack, with live demos of voice, translation, and tool calling.
- The Live API is a stateful WebSocket. You open a session and stream text, audio, and video frames in, and the model answers back in audio chunks plus a transcript, with barge-in built in so you can interrupt it mid-response.
- Gemini 3.1 Flash Live is a native audio model, not a cascading pipeline. It understands speech directly and responds in any of the 90 languages currently supported, switching between them fluidly.
- Live Translate listens and translates in near real time. It auto-detects the language being spoken and translates it live for each listener, demoed to the room over a QR code and headphones.
- Tool calls bring other models into the conversation. A live "radio DJ" demo used a function call to Lyria 3 to generate a song on request, and a separate story-illustration demo chained calls to Nano Banana Lite through the Interactions API, using the previous interaction ID to keep characters and style consistent across images.
- Grounding with Google Search gives the model access to live information, like today's weather, instead of relying only on what it was trained on.
- LiveKit and PipeCat get a mention as partners for scaling real-time media once you're past the demo stage.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
- The Live API is a stateful WebSocket. You open a session and stream text, audio, and video frames in, and the model answers back in audio chunks plus a transcript, with barge-in built in so you can interrupt it mid-response.
- Gemini 3.1 Flash Live is a native audio model, not a cascading pipeline. It understands speech directly and responds in any of the 90 languages currently supported, switching between them fluidly.
- Live Translate listens and translates in near real time. It auto-detects the language being spoken and translates it live for each listener, demoed to the room over a QR code and headphones.
- Tool calls bring other models into the conversation. A live "radio DJ" demo used a function call to Lyria 3 to generate a song on request, and a separate story-illustration demo chained calls to Nano Banana Lite through the Interactions API, using the previous interaction ID to keep characters and style consistent across images.
- Grounding with Google Search gives the model access to live information, like today's weather, instead of relying only on what it was trained on.
- LiveKit and PipeCat get a mention as partners for scaling real-time media once you're past the demo stage.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
1
0
2
214
Full talk on building real-time multimodal voice agents with the Gemini Live API, from native audio to tool calls and live translation:
youtu.be/xfPVBzDYjH4
youtu.be/xfPVBzDYjH4
0
0
0
96
A voice agent can measure fast and still sound slow to the person on the phone. @codeSTACKr, Staff Developer Advocate at LiveKit, takes that gap apart in "Latency Is a Budget. Humanlike Is the Goal.," on @aiDotEngineer's YouTube. The talk argues that picking speech to text, LLM, ls off a leaderboard is the wrong move for real time agents, and lays out what to measure and build instead.
- Leaderboards score components, you ship a cascade. A speech to text model mishears "the 3rd" as "the 30th" and every layer downstream, including a smart LLM, confidently acts on the wrong input. Leaderboard scores also come from clean audio in a quiet room, not a caller on speakerphone in traffic.
- Measured latency isn't perceived latency. TTS providers report time to first byte, but some ship up to three quarters of a second of pure silence before the first audible sound. Time to first audio, not first byte, is what the caller actually hears.
- Tools don't have to freeze the conversation. A lookup can take anywhere from two seconds to forty or more. The fix in the talk: the agent hands the mic back to itself while the tool keeps running in the background, the same way a receptionist says "give me a sec" instead of going silent. The talk plays a demo of a hotel booking agent that handles an interruption and a changed date mid-call without breaking stride.
- Turn detection built on audio, not transcripts. Listening to pitch and intonation instead of waiting for a full transcript to land cuts callers off 4.5% of the time at a given latency budget, against 9.9% for the best alternative tested. The eval harness behind that number is open source.
- The budget has a shape. Staying within a second and a half end to end keeps a conversation working; getting closer to 600 milliseconds is where it starts to feel human.
- An open source benchmark for the whole stack, not the parts. A working hotel receptionist agent gets hit with simulated callers that interrupt and change their minds, then gets scored on outcomes like whether the right reservation landed, whether anyone got cut off, and whether the agent leaked data, not on vibes.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
- Leaderboards score components, you ship a cascade. A speech to text model mishears "the 3rd" as "the 30th" and every layer downstream, including a smart LLM, confidently acts on the wrong input. Leaderboard scores also come from clean audio in a quiet room, not a caller on speakerphone in traffic.
- Measured latency isn't perceived latency. TTS providers report time to first byte, but some ship up to three quarters of a second of pure silence before the first audible sound. Time to first audio, not first byte, is what the caller actually hears.
- Tools don't have to freeze the conversation. A lookup can take anywhere from two seconds to forty or more. The fix in the talk: the agent hands the mic back to itself while the tool keeps running in the background, the same way a receptionist says "give me a sec" instead of going silent. The talk plays a demo of a hotel booking agent that handles an interruption and a changed date mid-call without breaking stride.
- Turn detection built on audio, not transcripts. Listening to pitch and intonation instead of waiting for a full transcript to land cuts callers off 4.5% of the time at a given latency budget, against 9.9% for the best alternative tested. The eval harness behind that number is open source.
- The budget has a shape. Staying within a second and a half end to end keeps a conversation working; getting closer to 600 milliseconds is where it starts to feel human.
- An open source benchmark for the whole stack, not the parts. A working hotel receptionist agent gets hit with simulated callers that interrupt and change their minds, then gets scored on outcomes like whether the right reservation landed, whether anyone got cut off, and whether the agent leaked data, not on vibes.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
6
1
8
1,692
Full talk on measuring perceived latency instead of dashboard latency, and the async tool pattern that keeps a voice agent talking while it works:
youtu.be/j4AmIK6OvHc
youtu.be/j4AmIK6OvHc
0
0
0
45
A model can look like the clear winner on a leaderboard and still be the worse pick once you check the bill. @WolframRvnwlf, an AI Evangelist at Weights & Biases by CoreWeave, walks through exactly that trap in "From Zero to Leaderboard: Agent Evaluation," on @aiDotEngineer's YouTpractical build-your-own-benchmark guide: the choices you have to make before a leaderboard number means anything.
- One score hides the real picture. Wolfram's premise is that performance is a distribution, not a point, so WolfBench tracks separate numbers: the share of the benchmark a model solves in every run (consistency), the average across runs, and the ceiling, what it can solve at least once.
- Six swappable layers, and changing any one makes it a new benchmark. The benchmark data set, the evaluation harness, the sandbox, the agent, the model and service, and settings like temperature, thinking effort, and system prompt. Swap one and the comparison breaks.
- A single run is benchmark lottery. He runs five per configuration, because one run on its own is just a ballpark number.
- Cheaper and faster can still cost more. Gemini 3.5 Flash scored almost as well as GPT 5.5 but burned 1.65 billion tokens against GPT 5.5's 136 million, landing at $620 versus $497.
- More thinking made Opus 4.6 worse. Raising its thinking budget to max dropped its score, because it overthought simple fixes instead of just trying a command and reading the error.
- Fable refused 13 tasks, and turned into the most expensive benchmark Wolfram ran, at $11,000.
- A bar is a claim, a trace is evidence. Every score on wolfbench.ai links through to Weave so you can inspect the actual agent trajectory behind it.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
- One score hides the real picture. Wolfram's premise is that performance is a distribution, not a point, so WolfBench tracks separate numbers: the share of the benchmark a model solves in every run (consistency), the average across runs, and the ceiling, what it can solve at least once.
- Six swappable layers, and changing any one makes it a new benchmark. The benchmark data set, the evaluation harness, the sandbox, the agent, the model and service, and settings like temperature, thinking effort, and system prompt. Swap one and the comparison breaks.
- A single run is benchmark lottery. He runs five per configuration, because one run on its own is just a ballpark number.
- Cheaper and faster can still cost more. Gemini 3.5 Flash scored almost as well as GPT 5.5 but burned 1.65 billion tokens against GPT 5.5's 136 million, landing at $620 versus $497.
- More thinking made Opus 4.6 worse. Raising its thinking budget to max dropped its score, because it overthought simple fixes instead of just trying a command and reading the error.
- Fable refused 13 tasks, and turned into the most expensive benchmark Wolfram ran, at $11,000.
- A bar is a claim, a trace is evidence. Every score on wolfbench.ai links through to Weave so you can inspect the actual agent trajectory behind it.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
3
0
4
875
Full workshop on the six choices behind any agent benchmark score, and what Gemini 3.5 Flash, GPT 5.5, and Fable actually cost to run through it:
youtu.be/YIxzNZDDy1A
youtu.be/YIxzNZDDy1A
0
0
1
76
Vector search can answer anything a search engine could. It stalls once a question needs three or more hops across documents, things like tracing a supply chain or doing source code analysis. @NyahMacklinDev, Senior Developer Advocate for AI at Neo4j, takes on that gap in a talk : Using GraphRAG to Retrieve Connected Context," which @aiDotEngineer posted on YouTube.
It's a plain walkthrough of why folding a knowledge graph into retrieval fixes the multi-hop and aggregation questions vector-only RAG tends to get wrong, down to building one from scratch in Neo4j Aura.
- A graph is both machine and human readable. Nyah contrasts a vectorized "apple" (a string of floats nobody can read) with a graph view where the apple is a fruit, is round, is red, and comes from a tree. Same object, legible either way.
- Rows and joins don't scale the way a graph does. Structuring data in tables means complex joins to find relationships; a graph lets an agent hop from node to node along the relationship itself and trace how it got to an answer.
- That traceability matters most in regulated work. Nyah points to finance, medicine, and legal as the domains where being able to retrace an agent's path, not just its answer, is the actual requirement.
- GraphRAG isn't a separate pipeline, it's RAG with a graph in the retrieval path. The standard chunk-embed-retrieve-generate flow stays intact; the graph just gets folded into retrieval. Nyah's take: run graph and vector together rather than picking one.
- Building the graph is itself an LLM task. Chunk the text, embed it, send it to an LLM to extract entities and relationships as JSON, then generate the graph with Cypher, using Neo4j's open source GraphRAG Python package.
- The live demo puts an aggregation question to the agent. It gets asked "how many lessons are in this course," the kind of question Nyah notes most RAG pipelines handle badly.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
It's a plain walkthrough of why folding a knowledge graph into retrieval fixes the multi-hop and aggregation questions vector-only RAG tends to get wrong, down to building one from scratch in Neo4j Aura.
- A graph is both machine and human readable. Nyah contrasts a vectorized "apple" (a string of floats nobody can read) with a graph view where the apple is a fruit, is round, is red, and comes from a tree. Same object, legible either way.
- Rows and joins don't scale the way a graph does. Structuring data in tables means complex joins to find relationships; a graph lets an agent hop from node to node along the relationship itself and trace how it got to an answer.
- That traceability matters most in regulated work. Nyah points to finance, medicine, and legal as the domains where being able to retrace an agent's path, not just its answer, is the actual requirement.
- GraphRAG isn't a separate pipeline, it's RAG with a graph in the retrieval path. The standard chunk-embed-retrieve-generate flow stays intact; the graph just gets folded into retrieval. Nyah's take: run graph and vector together rather than picking one.
- Building the graph is itself an LLM task. Chunk the text, embed it, send it to an LLM to extract entities and relationships as JSON, then generate the graph with Cypher, using Neo4j's open source GraphRAG Python package.
- The live demo puts an aggregation question to the agent. It gets asked "how many lessons are in this course," the kind of question Nyah notes most RAG pipelines handle badly.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
1
0
0
80
Full talk on where vector RAG hits its limit and how a knowledge graph closes it, including a live build in Neo4j Aura:
youtu.be/LJ2a9nX3vlo
youtu.be/LJ2a9nX3vlo
0
0
0
32
Give an agent access to what a table's rows actually mean, and task success on complex data changes jumps almost 35 points over the same model without it. That's the number @Yoni_Michael and Brandon Callender of typedef land on in "The Data Context Layer for Agents," a talk ouTube. The throughline is that agents don't fail at writing SQL, they fail because they don't know what a row represents, what breaks downstream, or whether a join is safe.
- Grain. A table's grain is what one row means (customer by month versus customer by week). Change it without knowing and every downstream sum can go wrong while the SQL still compiles and runs fine.
- Join safety. The same join syntax can resolve four different ways depending on the underlying data, from preserving row counts to silently exploding them. Yoni's team verifies this against the actual data by profiling tables, not by reading the query text.
- Metrics hide inside SQL. A "cleanup" that drops a predicate can silently redefine a metric (like what counts as "paid") across every downstream dashboard, even though nothing looks wrong syntactically.
- Blast radius, before the change. Before an agent edits a model, it walks the dependency graph to see what breaks downstream, catching things like a metric that would quietly 4x once a grain shifts.
- Deterministic first, LLM second. Parse code down to the AST and compute grain and lineage directly from it; only hand the LLM the parts that need judgment, like naming or summarizing.
- The agent will grep anyway. Brandon built a working code graph for Rust and still watched agents default to search and grep over it. Renaming the tool "search" and matching ripgrep's response shape meets the model where its training already is.
- Consistency over single-shot accuracy. Grep and the graph tool scored about the same on any single try, but across five runs the graph-equipped agent was roughly twice as likely to get every run right, using about 3.1x fewer tokens.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
- Grain. A table's grain is what one row means (customer by month versus customer by week). Change it without knowing and every downstream sum can go wrong while the SQL still compiles and runs fine.
- Join safety. The same join syntax can resolve four different ways depending on the underlying data, from preserving row counts to silently exploding them. Yoni's team verifies this against the actual data by profiling tables, not by reading the query text.
- Metrics hide inside SQL. A "cleanup" that drops a predicate can silently redefine a metric (like what counts as "paid") across every downstream dashboard, even though nothing looks wrong syntactically.
- Blast radius, before the change. Before an agent edits a model, it walks the dependency graph to see what breaks downstream, catching things like a metric that would quietly 4x once a grain shifts.
- Deterministic first, LLM second. Parse code down to the AST and compute grain and lineage directly from it; only hand the LLM the parts that need judgment, like naming or summarizing.
- The agent will grep anyway. Brandon built a working code graph for Rust and still watched agents default to search and grep over it. Renaming the tool "search" and matching ripgrep's response shape meets the model where its training already is.
- Consistency over single-shot accuracy. Grep and the graph tool scored about the same on any single try, but across five runs the graph-equipped agent was roughly twice as likely to get every run right, using about 3.1x fewer tokens.
I'm working through the published talks from AI Engineer World's Fair sharing summaries and takeaways. Follow for more!
3
1
2
289
Full talk on why agents need a persistent graph of what data actually means, not just access to the data, plus a worked example of an agent reaching for grep over a purpose-built graph tool:
youtu.be/KhRjivBSwiw
youtu.be/KhRjivBSwiw
0
0
1
44

