Press "Enter" to skip to content

Category: Generative AI

Building a Mental Model of LLMs

Published 2026-08-25 by Kevin Feasel

John Mount puts together an idea:

As of now (late 2026) LLM (large language model) technology providers, users, and work products flood the public commons. It therefore makes sense to have even a primitive mechanistic mental model of these technologies. You are forced to have an opinion. Without a mechanism or model one tends to fall into disempowering anthropomorphic language. Some clear thoughts on this can be found here and here.

In this note I would like to try and outline a (very) simplified mental model of LLM mechanics and mechanisms. By “mental model” I mean a cartoon to work through in your mind, not a model of the LLMs as having their own mind. I won’t be teaching the history of LLMs, how to build them, how to use them, or their moral or philosophic implications. I will only try to give a very rough outline how the current (2026) LLMs work.

Click through for an intuitive explanation of how they work.

Leave a Comment

Visual Design and Generative AI

Published 2026-08-21 by Kevin Feasel

Cole Nussbaumer Knaflic guides the non-thinking machine:

Now that we have the story planned, it’s time to start developing the content that will support our message and narrative. When data is part of that, a good first step is choosing a visual that aids in comprehension. The right graph makes your point immediately clear. The wrong one makes your audience spend their mental energy decoding the graph instead of understanding your message.

This is where people sometimes stumble. They use the first chart that comes to mind—or simply carry forward the one they used during exploratory analysis. But a graph that works for exploring data isn’t necessarily the best for communicating it. Your audience and takeaway should drive the choice. By this point, you’ve already done that work: you know your audience, you’ve planned your story, and you’ve written takeaway titles that tell you exactly what each graph needs to show. Let those sentences guide your design.

As you’d expect, there’s some good advice on choosing specific types of visuals. But the majority of this article is around nudging the language model to spit out the correct visual for the right reasons.

Leave a Comment

Large Language Models for Data Professionals

Published 2026-08-19 by Kevin Feasel

Eugene Meidinger has a primer:

It’s tempting to think that working with LLMs and AI agents doesn’t require understanding anything about how they work. These tools are often presented as autonomous, intelligent, and self-explanatory. They communicate through conversational text, making them feel natural and intuitive, and can often even seem like magic.

In practice, however, these intuitions about LLMs are often very wrong. LLMs are a strange technology. As we stack tools and agent interfaces (or harnesses) on top of them, more and more misunderstandings also stack up. Treating them as an easy button leads to layers of frustration, waste, and, in the worst-case scenario, mistakes.

This is a nice baseline to get someone started with understanding LLM output behavior. It’s not a how-to guide, but rather a “Here’s what’s going on” type of guide. Eugene brings less snark to the topic than I do, but that’s par for the course for anyone who remembers the good ol’ days of the SQL Data Partners podcast.

Leave a Comment

Conceptualizing the Agent2Agent Protocol

Published 2026-08-05 by Kevin Feasel

Paul Brebner continues a series on Apache Kafka and the Agent2Agent Protocol. Part 3 explains the details of the protocol:

In Part 2, we discovered that A2A’s object model centres on the “nouns” Agent Card, Task, Message, Part, and Artifact. A client sends messages; the remote agent responds with an immediate Message or a stateful Task. Artifacts — the durable outputs — live on the Task, not as a separate top-level response type.

This post covers the “verbs”: how agents find each other, how work flows at runtime, and the confusions that surfaced when I first read the specification (but are hopefully clarified by the end of this blog). These runtime patterns allow agents to discover each other, delegate work, track long-running operations, and exchange results across distributed systems. (Note: Part 4 will add sequence and state diagrams plus concrete request/response traces.)

By the end of this post, you’ll understand the core runtime flow behind the A2A protocol and how it supports scalable agent communication architectures that can be combined with technologies such as Apache Kafka.

Part 4 visualizes the different components:

In Parts 1-3, we treated the topic in prose: why multi-agent interoperability matters (Part 1), the core A2A objects (Part 2), and the operational patterns in (Part 3). Useful, but when I turned to implementation, I kept wanting sketches on the table: where modules sit, how objects connect, what the wire sequence looks like, which task states are legal.

The diagrams that follow are that layer. They provide a visual guide to the Agent2Agent protocol and help translate the specification into something easier to design, implement, test, and reason about.

Comments closed

Understanding the Agent2Agent Object Model

Published 2026-07-30 by Kevin Feasel

Paul Brebner digs into a protocol:

The Agent2Agent (A2A) object model defines the core building blocks that enable AI agents to discover one another, exchange messages, execute long-running work, and deliver durable outputs. The primary A2A objects are agent cards, messages, parts, tasks, and artifacts. Together, they provide a standardized foundation for AI agent interoperability across frameworks, platforms, and programming languages

This post focuses on A2A — specifically the nouns of the protocol: who participates, and what data objects carry meaning. Part 3 will cover how agents discover each other, send work, and deliver updates.

Click through to learn a bit more about the A2A protocol, as well as the major object-level components that make up a solution.

Comments closed

Optimizing Power BI Data Agents

Published 2026-06-26 by Kevin Feasel

Paul Turley shares some advice:

Amid the AI frenzy, there is a lot of conversation about how business users will use agentic chat to answer business questions rather than interactive, dashboard-style reports. Is there truly a shift in the industry, and is agentic analytics going to change the way most business users consume data?

Just how viable is the whole “chat with your data” option, and is it really a replacement for conventional reporting? I recently heard a VP-level leader at a large consulting firm say something to the effect of “we need to stop investing in dashboard-building skills and focus on creating AI-driven data analysis solutions for our consulting customers.” I’m paraphrasing from memory, but that was the sentiment. Are all business leaders across the industry giving up their dashboards, interactive visual reports and scorecards in exchange for AI chat? No. Of course they aren’t — but conversational analysis is a new way to consume business data.

Much of the advice is very similar to what you’d get for standard dashboard creation, and it makes sense. The clearer your data model is and the tighter your semantic model is, the easier it is for processes to use that semantic model. But Paul also covers some things specific to Data Agents as well.

Comments closed

Trusting Outputs from Fabric Data Agents

Published 2026-06-25 by Kevin Feasel

Jens Vestergaard says don’t trust, do verify:

In two previous posts I went down the path of getting a semantic model ready for AI: descriptions on every measure, an instructions file, the schema tidied up enough that a Fabric data agent has something real to read. That work has a satisfying endpoint. The model looks ready.

Ready is not the same as right.

The kind of evaluation Jens is talking about is fundamental to good business intelligence practices, regardless of whether you throw language models into the mix. Where language models do add complexity is the arbitrary scope of questions, how ambiguous people tend to be when writing, and the stochastic nature of answers. All of that makes the problem harder, though at least it isn’t an entirely different class of problem to solve.

Comments closed

Major Announcements from Microsoft Build 2026

Published 2026-06-19 by Kevin Feasel

James Serra puts together a list:

Once again there were a number of Microsoft Build announcements related to data and AI, and some were very impressive. Below are my favorites. I am prioritizing the data announcements first, because that is where my brain naturally goes (and because AI without good data is just a very confident intern with access to a keyboard).

The biggest announcements across Microsoft Fabric and databases can be found in the Microsoft Build 2026: Building agentic apps with Microsoft Fabric and Microsoft Databases blog post.

This looks like another year of Fabric + AI as the (almost) entire data platform focus at Build.

Comments closed

Noise in CRAN Package Additions

Published 2026-06-15 by Kevin Feasel

Joseph Rickert shows a consequence of lowering the bar for application development:

If you are reading this post on R-bloggers, you will probably know that I have been publishing my selection of the “Top 40” new R packages on CRAN for quite some time. I did this first as part of my work at Revolution Analytics, then on R Views for RStudio and Posit, and now here on R Works. It used to take about a day’s worth of pleasurable work spread out over a month to select forty interesting packages. For a hundred or so packages, I could look at all of the package webpages, download and play with a small number of them. Now, the “Top 40” has become a real hamster-on-the-wheel project. The following plot shows my count of the number of new packages to make it to CRAN since I began publishing on R Works.

Click through to see what Joseph has laid out. The part that surprises me is, historically, CRAN was pretty difficult to get a package into and you typically needed to jump through a certain number of quality gates. I suppose that has to have changed given what Joseph notes around the lack of documentation in many of these new packages.. But it could be that my understanding of it was wrong H/T R-Bloggers.

Comments closed

Vibe Coding and Maintenance

Published 2026-06-15 by Kevin Feasel

Buck Woody has an essay:

Artificial Intelligence constructs, from Large Language Models answering questions to Agentic AI that runs various workflows are fantastic, amazing, helpful tools in getting a job done. They aren’t quite completely automating entire tasks (The best ones as of this writing are correctly implementing around one out of three tasks accurately: https://llm-stats.com/benchmarks/apex-agents) but they are still a very helpful tool. “Vibe Coding” which means explaining to a model that can write code (or a Codex) what you want the code to do, trying it out, then correcting it until it does the thing, is prevalent everywhere now. And it’s easy to do.

But the code a Codex creates meets a single need: to ship.

This matches pretty well with what I’ve seen. You can definitely build something, which may be good enough for single-person use. But maintenance is a separate story altogether and raises the old adage that you can only maintain code less sophisticated than your knowledge level. Between that and cognitive overload, you can easily end up with a code base that you can’t understand.

Comments closed