Understanding AI Tools and Message Flow in Glow

Chat as a State Machine

The Glow paradigm treats a chat like a state machine, where each node represents a state with its own tools and instructions. Transitions between states are handled by the AI using a special internal tool—not visible to the user—but controlled through instructions within each node. For example, you can guide the AI to move to specific nodes based on the user's input.

Tools in Glow

In general, Glow manages three types of tools:

1. Tools for managing the graph state - Navigate between different conversation nodes
2. Tools for interacting with APIs - Make external API calls to fetch data
3. Tools for interacting with the user - Display dedicated graphical widget UIs

The Glow paradigm is fundamentally built around messages and tool calls. So let's quickly recap what messages and tool calls are, and how they work together to shape the chat experience.

Understanding Messages and Tool Calls

Messages: In traditional AI chats like ChatGPT, interactions are handled as text messages—user messages go into the system, and the system responds with messages back to the user (Message-In-Message-Out).

sequenceDiagram
    participant User
    participant AI System

    User->>AI System: Sends text message
    AI System->>AI System: Processes input
    AI System->>User: Returns response message

Tool calls were introduced later and changed how AI interacts by adding a new entity—the API. While the user still sends and receives plain text messages, the AI can now communicate with APIs during processing. It sends requests to APIs, receives their responses, and then uses that information to craft its reply to the user.

sequenceDiagram
    participant User
    participant AI System
    participant API

    User->>AI System: Sends text message
    AI System->>AI System: Processes input
    AI System->>API: Sends API request (Tool call)
    API-->>AI System: Returns API response
    AI System->>User: Returns response message

The point here isn't just to explain how tools work, but also to highlight that tools were introduced as an afterthought, while maintaining the original Message-In-Message-Out interaction with the user. This can sometimes lead to odd behaviors, because the AI was originally trained to follow a simple pattern: receive a message, call an API, and produce a message. However, when using special GUI widgets, we might need a different kind of interaction that doesn't fit neatly into this flow.

Client-Side (GUI) Tools

Now let's look at how client-side GUI tools work in the Glow paradigm. Normally, tool calls are meant for interacting with APIs—not the user. But there's nothing stopping us from using a tool to display a widget to the user. For example, if a user uploads an image, the result of that upload can be sent back to the AI as a tool result, allowing the chat to continue based on the user's input—in this case, the uploaded image.

sequenceDiagram
    participant User
    participant AI System
    participant Widget

    User->>AI System: Sends text message
    AI System->>AI System: Processes input
    AI System->>Widget: Triggers GUI tool (e.g. image uploader)
    User->>Widget: Interacts with widget (e.g. uploads image)
    Widget-->>AI System: Sends tool result (e.g. image file)
    AI System->>User: Returns response message

The Blocking Problem

There's a key flaw with this type of interaction: it blocks the user. Take, for example, a tool that displays buttons for choosing a subscription plan—'Free', 'Pro'. While those buttons are shown, the chat is effectively paused. But what if the user wants to ask a question first, like what each plan includes or what "Pro" means? That's why we need a way for tool calls to be non-blocking—so the user can still interact freely without being forced to respond immediately to the widget.

Non-Blocking Widgets

Glow enables non-blocking widget calls using a kind of workaround. The tool call returns immediately without actually doing anything. Then, the system uses the tool result to render a component—like buttons—and instructs the AI to expect the user's input.

When the user clicks a button, the system submits a message on their behalf with their choice. Since the tool already returned, the chat remains unblocked. This means the user can ask questions, switch nodes, or explore further before making a selection. When ready, the user can either click a button or type their choice, and the chat can respond accordingly.

sequenceDiagram
    participant User
    participant AI System
    participant Widget

    User->>AI System: Sends text message
    AI System->>AI System: Processes input
    AI System->>Widget: Triggers widget (e.g. plan buttons)
    Widget-->>AI System: Returns immediate tool call response (placeholder)
    AI System->>User: Displays widget (e.g. subscription options)
    Note over AI System,User: Chat remains active—user can keep typing
    User->>AI System: Asks follow-up question (e.g. "What does Enterprise mean?")
    AI System->>AI System: Responds as usual
    User->>Widget: (Later) Selects a plan
    Widget-->>AI System: Sends tool result (e.g. selected plan)
    AI System->>User: Responds based on selection

So our diagram is now becoming a bit complicated, but it clearly demonstrates how we can have a non-blocking UI tool.

The Message Generation Challenge

Unfortunately, it's not that simple. As shown in the initial diagram, after a tool call, the AI expects to generate a message based on the tool's result—because tool calls were originally meant for APIs that return meaningful data the AI needs to process and respond to.

But in our case, the tool (like a button selector) returns nothing—it just triggers the UI to display options. There's no new data to react to, so there's no need for the AI to send another message.

However, if your prompt is structured like: "Greet the user and ask them to choose an option, then call the tool to show the options," the AI will first greet and ask the user to choose, then call the tool, which returns an empty result, and then the AI will generate another message—often just repeating the first one. This creates a weird, redundant effect where the chat feels awkward and repetitive.

The Solution: Reverse the Order

Since the AI always generates a message after a tool call, we can work around this by first calling the tool, then generating the message. For this specific type of tool, we simply flip the display order in the UI—so even though the tool was technically called before the message, the user sees the message first, followed by the button options.

While this is a simple and effective fix, it can be quite confusing for the prompt engineer. Intuitively, you'd expect to generate the message first and then call the tool—but in this case, you have to do the reverse: call the tool first, then generate the message.

Key Takeaways

Understanding AI Fundamentals

One needs to understand how the AI works to get the best results and behavior from your prompts. While AIs are incredibly smart and understand instructions well, they process them very differently from humans. This is because they're fundamentally language models with some reasoning ability—not reasoning models that use language like humans do.

Tools Are Powerful but Basic

Tools are powerful—they turn a language model from just a talker into a doer. But tools are also basic and opinionated, designed for specific use cases. So, to create advanced, flexible interactions that weren't originally envisioned, we often need to tweak how we use tools and carefully structure our prompts to support these behaviors.

Use Clear Structural Cues

Use clear structural cues in your prompts—especially words like ALWAYS and THEN. Capitalizing and surrounding them with asterisks helps the AI recognize their importance and better follow the intended flow.

For example, if the AI isn't following an instruction as expected, try adding ALWAYS before it. If you want to ensure the AI performs one step followed by another, use THEN to explicitly link the two. These emphasized cues can significantly improve prompt reliability and clarity.

Addressing the AI

Tip: When giving instructions to the AI, refer to it as "the assistance"—for example, "The assistance should tell the user…". Since the AI doesn't have a real sense of self, calling it "you" or "the AI" might confuse it. It's better to address the simulated assistance directly.

This post explores the technical foundations of how Glow manages AI interactions, tools, and widgets to create seamless conversational experiences. Understanding these patterns will help you build more effective and intuitive agentic interfaces.