When I need flexible message routing in Azure without duplicating infrastructure, Azure Service Bus Topics are usually my first choice.
They solve a very specific problem: letting multiple consumers react differently to the same message without forcing the publisher to care who’s listening, all on top of a First Class Queueing and Messaging platform.
Azure Service Bus itself is the core messaging backbone in Microsoft Azure, supporting reliable, FIFO-based messaging with retries, dead-lettering, and durability. Topics build on that foundation by adding true publish/subscribe behavior.
Why Topics Instead of Queues
Queues work well when a single consumer owns a message. Topics are better when multiple workflows need the same event. For example, a single “OrderReceived” message might trigger billing, inventory, and notifications—all independently.
Instead of copying messages into multiple queues, a Topic lets you publish once and fan out through subscriptions.
Creating a Topic and Subscriptions
In the Azure Portal, I start by creating a Service Bus namespace using the Standard tier. Topics aren’t available in Basic, but Standard is inexpensive and more than enough for most workloads. It comes in at a wopping $10 per month! Making it one of the best values in Azure!
Once the namespace exists, I create a Topic. This is the endpoint publishers send messages to. Subscriptions are then created under that Topic, each acting like its own virtual queue.
In my demo, I created:
-
A NewOrder subscription
-
An UpdateOrder subscription
At this point, both subscriptions would receive every message unless filters are applied.
Azure Topics and Subscriptions
Using Subscription Filters for Routing
Filters are what make Topics powerful. Instead of handling routing logic in code, I push it into the broker.
I typically use correlation filters for simple routing scenarios. They’re efficient and easy to reason about. In this case, I filtered on the Label broker property:
-
Label = NewOrderroutes to the NewOrder subscription -
Label = UpdateOrderroutes to the UpdateOrder subscription
Once a custom filter is applied, the default “match all” filter is removed automatically.
Subscription Filters in Service Bus
Testing with Service Bus Explorer
The Azure Portal includes Service Bus Explorer, which is perfect for testing without writing code.
I sent two messages:
-
One labeled NewOrder
-
One labeled UpdateOrder
Each message is routed exactly where expected. When I peek the subscriptions, each contains only the message that matched its filter.
This immediate feedback loop is invaluable when validating routing rules.
When I Use This Pattern
I rely on Topics and Filters when:
-
Multiple systems react to the same event
-
Routing logic changes over time
-
I want to avoid redeploying publishers
-
Integration workflows need isolation
This pattern pairs especially well with Azure Logic Apps, Functions, and downstream APIs.
Final Thoughts
Azure Service Bus Topics are simple to configure but incredibly powerful when used correctly. By pushing routing logic into the broker, you reduce coupling, simplify publishers, and gain a scalable, flexible solution.
If you’re already using queues, Topics are a natural next step—and one of the best values in Azure messaging today.
Agent Instructions for Heads-Up 5-Card Draw Poker
You are a poker dealer and opponent playing heads-up 5-card draw poker against the user. The user is Player 1 and you are Player 2.
Important: You can only respond to inputs related to playing 5-card draw poker. If the user asks about anything else or tries to have a conversation unrelated to the poker game, respond with "Sorry, I can only play Poker" and wait for game-related input.
Game Flow:
Start each game by dealing a new deck using the Deck of Cards API. Always include the deck ID in all communications so you can draw from the same deck throughout the game.
Deal 5 cards to Player 1 and display them using card images from https://deckofcardsapi.com/static/img/[CARD].png where [CARD] is the card code like 6H, AS, KD, etc. Show each card as a small image with a maximum width of 60 pixels.
Ask Player 1 which cards they want to discard. They can specify cards by position number 1 through 5, or they can keep all cards. Accept responses like "discard 2 and 4" or "keep all" or "throw away 1, 3, and 5". If the player asks for help, analyze their hand and suggest which cards to keep and which to throw away for the best chance to win. Base your suggestion on standard poker strategy such as keeping pairs, keeping cards that could form straights or flushes, and discarding low unmatched cards. Player 1 gets only one opportunity to discard and draw replacement cards.
Draw replacement cards for any discarded cards using the same deck ID. Show Player 1 their final hand with card images at 60 pixels wide. This is Player 1's final hand and no further card exchanges are allowed.
Now reveal your starting hand as Player 2 by dealing 5 cards from the same deck. Show your cards with images at 60 pixels wide.
Decide which cards to discard from your hand based on standard poker strategy. Draw replacement cards and show your final hand with images at 60 pixels wide. You also get only one opportunity to discard and draw replacement cards. This is your final hand.
Evaluate both final hands carefully and determine the winner using standard poker hand rankings: Royal Flush, Straight Flush, Four of a Kind, Full House, Flush, Straight, Three of a Kind, Two Pair, One Pair, High Card. Pay special attention to checking for Straights, Flushes, Full Houses, and Two Pair as these are commonly missed. For a Straight, verify that all five cards form a consecutive sequence. For a Flush, verify that all five cards are the same suit. For a Full House, verify there are exactly three cards of one rank and two cards of another rank. For Two Pair, verify there are exactly two cards of one rank and two cards of a different rank. Clearly state which hand type each player has and declare the winner.
Ask the user if they want to play again. If the user wants to play again, shuffle and get a new deck ID, then start a new game from the beginning with the fresh deck.
Technical Notes:
Card images are at https://deckofcardsapi.com/static/img/[CARD_CODE].png
Display all card images at 60 pixels wide
Always reference the same deck_id throughout a single game
Card codes are two characters: rank (A,2,3,4,5,6,7,8,9,0,J,Q,K) and suit (S,H,D,C)
Keep all communication friendly and conversational. Show enthusiasm when dealing cards and announcing winners. Make the game feel interactive and fun.Running and Observing the Agent
Once deployed, running the agent is as simple as opening the chat interface and typing “let’s play.”
Logic Apps provides full visibility into every step the agent takes. You can see:
-
Which tools were called
-
What inputs the agent sent
-
What outputs came back
-
The full conversation history
Even better, if someone else interacts with the agent, I still get that same execution trace. That level of insight makes debugging and iteration far easier than working with a black-box chat system.
Agent Loop Log
Offloading Reasoning to External Models
In a more advanced version of this agent, I removed winner evaluation entirely. Instead, I pass both hands to an external reasoning model and let that model determine the outcome.
This pattern is far more reliable than relying on the agent alone to reason correctly every time. It also keeps the agent instructions simpler and easier to maintain.
In my case, I used a DeepSeek reasoning model via a direct HTTP call, but the same approach works just as well with Azure AI Foundry models.
DeepSeek Double Check Tool
Cost and Final Thoughts
I ran this agent about 25 times and spent a total of $1.11. After that, the Logic App just sits there waiting for work—and I’m not charged anything until it runs again.
If you want to experiment with AI agents in Azure without committing to heavier infrastructure, Logic Apps Consumption with AgentLoop is an excellent place to start.
Build something small. Observe how the agent behaves. Push logic into tools where it makes sense. And when you need more flexibility, move the same patterns over to Logic Apps Standard.
Agent Loop Costs in Consumption
Recent Comments