Press "Enter" to skip to content

Category: Generative AI

Using the Azure Resiliency Agent

Reitse Eskens gives a copilot a spin:

And that isn’t limited to services like storage, web portals, user management, and data stuff. It’s also location, backups, and disaster recovery. But there’s a catch: you need to make sure this is configured. I always compare the cloud (Azure in my daily work) with a huge box of Lego. You have all the pieces and elements to make something cool, but you have to build it. Even when you automate it, you still need to think about what you want.

Now, before I continue my Azure Fundamentals training, let’s move on to what this post is about: resiliency. Or, how your environment is set up for disaster recovery.

Let’s use the Azure Copilot to guide the process, create the necessary resource and review the advice.

Click through to see how it works. Because it’s in preview right now, we don’t know how much it will cost later. But in the meantime, you can give it a try.

Leave a Comment

Building Daily Averages in DAX

Marco Russo and Alberto Ferrari take generative AI tooling for a spin:

Computing an average daily sales amount is straightforward: you should iterate over the dates, compute sales for each day, and average the results. An AI assistant can generate DAX code that works in just a few seconds; whether it computes the number you need is a different question.

In this article, we ask AI to generate every measure, function, and validation query. We start with a simple average and test it against more demanding scenarios. Our job is to explain the business requirements, challenge the proposed code, and verify the results. Each test reveals a missing detail from the original request.

The prompts below show a conversation with an AI agent. They describe how to get the DAX code from the AI. They are not a verbatim transcript: a different agent might produce different expressions.

This shows the duality of generative AI outcomes: you can end up with a good solution, but unless you know the ins and outs of what you’re doing, you can end up in a sub-optimal situation.

Leave a Comment

Managing AI Context

Eugene Meidinger has a pair of articles. The first one covers the use of Markdown for building AI context:

When performing agentic development, most of your time will be spent either writing prompts or context files in Markdown (.md) files. This is a simple format used for documentation and notetaking, but which is also easy to read or write for humans and agents. You have almost certainly encountered Markdown before, but you may not have known it. Markdown is used by AI agents, in code documentation, and in some chat programs. Even Microsoft Teams supports a subset of Markdown.

Markdown is extremely common in more than just AI development work, so it’s definitely worth knowing.

The other is a guide to understanding and managing AI agent context:

The most important task for you during agentic development is to create, gather, and curate context. Context is anytext (or images) that the model ingests to produce a more relevant and useful response. Providing the right context at the right time helps agents produce better results; it’s about more than just writing markdown files:

Leave a Comment

Excel Semantic Table Add-In

Teo Lachev has written a plugin:

It dawned on me that while waiting on Microsoft, I could fill these gaps myself by creating an Excel add-in. That is how the Semantic Table add-in was born. It picks up right where default connected tables leave off.

Others have already explored this path, such as Jörg Schmidt with his PBIXL add-in. However, I’ve taken a different implementation approach focused on these core features:

Click through for the approach, as well as an important warning that this is a very early beta. I think the GitHub repo is this one, as Teo didn’t include the link in his post as of the time my post went live.

Comments closed

Building a Mental Model of LLMs

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.

Comments closed

Visual Design and Generative AI

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.

Comments closed

Large Language Models for Data Professionals

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.

Comments closed

Conceptualizing the Agent2Agent Protocol

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

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

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