Category: Generative AI

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

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.

Leave a Comment

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

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