On Notifications

Like many of you, I receive a variety of notifications by various means. Postal letters, email reminders, pop-ups on my laptop, audio signals on my mobile, highlighted chat application entries, text messages, phone calls, taps on the shoulder—the list is long! Thinking a bit more about this, one of the purposes of notification is to resynchronize otherwise asynchronous processes. You tell Google Assistant to set a timer for 15 minutes and go off to do something else. After 15 minutes, you get an audible reminder that the 15 minutes are up, and you should turn off the spaghetti before it turns to mush.

Sometimes, it is advantageous for notifications to be delivered in more than one way. Perhaps a chime sound, a text message, an email, flashing screen—especially if you happen to be multitasking and not in a position to receive a particular notification form at some moment. This notion of notification can be extended to imagining its use for many parallel operations. A computational process running in parallel on multiple (virtual?) machines may eventually need to resynchronize—a notification can be used to put all processes into a common state of awareness of the progress of the computation. One way to think about notification is that it is an act of synchronization to bring two or more asynchronous parallel processes back into synchronization.

Here’s another example. Suppose you purchase a product that has a warranty with an expiration date. Perhaps there is an option to renew the warranty, but if you fail to renew before expiration you cannot renew it or there might be a higher charge to do so. If you are like me, you might stash those paper warranties in a file somewhere sort of hoping you remember to renew before expiration. Most of the time, I don’t remember to do that. Some companies will actually notify you ahead of time because the renewal is revenue, and what company doesn’t want that? Imagine a service that scans the warranty card/document, notes the expiration date, and sets a CRON job (I added that to pretend I’m still an active techie) to remind you in advance of expiration. Or maybe, in this day and age, your resident bot agent is tasked with dealing with these piddly details.

Speaking of agents, that’s the big topic of today’s AI discussions. As agent concepts become more implementable, they will need more rigor in inter-agent interaction. Two new ideas are emerging to make these interactions more reliable: Model Context Protocol (MCP)^a and Agent2Agent Protocol (A2A).^b These mechanisms are intended to achieve more reliable and precise communication among interacting agents. Remember “Telephone,” the old parlor game (does anyone even use that term anymore?), where one person whispers in the ear of the person sitting next to them, that person repeats the whisper into the next person’s ear, and so on? The game ends when the last person announces what they heard; it is often quite different from the original whispered message.

One could easily imagine a chain of agents relaying instructions, making agreements and commitments on your behalf, only to discover that the last agent in the list ordered 35 pounds of coleslaw to be delivered on Monday morning when you were hoping for three pounds of potato salad on Saturday. What a startling notification that would be! A more serious problem might be engaging in commodities options trading only to discover 35 tons of pork bellies in your front yard because your agent didn’t trade away the contract in time!

I am persuaded that formalizing notifications within the context of A2A and MCP may be a fruitful line of development. Not being an expert in either A2A or MCP, of course, that concept might already be well established in those new protocols. Perhaps one of the readers of this column, if there are any, might take a moment to let me know!