Meetup talk: An advanced SI protocol ecosystem

Let’s try this on a business you know, maybe your own. Where does something cross from one side to the other: a form, a price list, a booking? And what checks it today? If the answer is nothing, that’s the join to look after first, and in a few minutes we’ll see how. And for the engineers: this join isn’t a database join. It’s the seam where two systems meet, what you might call an interface or a boundary.

Here’s a quick, plain word about the name, and then back to the fun part. The order is titled “Inaugurating the Era of Super Intelligence.” It applies to the departments and agencies of the executive branch, the part of government the President leads. The laws Congress has passed, regulations and earlier documents all stay just as they are. In the order, SI means whatever the law’s definition of AI covers. For anyone who likes to look things up, that’s title 15 of the U.S. Code, section 9401, paragraph 3. When researchers say superintelligence, they usually mean a hypothetical system that would far outdo people at nearly everything, and that’s a different idea. The new name makes no claim about what these systems can do. And the 60 days on the slide? That’s the order’s next step: proposed wording for a federal definition goes to the President within that time. So when a federal letter or web page says SI, you can read it as AI. From here on, we’ll say SI too.

Let’s unpack some names. There are quite a few, so please don’t try to keep them all; the three questions at the bottom of the slide matter more than any name. An agent, a bit like a travel agent, is an SI system that takes steps on someone’s behalf, like the assistant ordering from the coffee cart. MCP is the Model Context Protocol. It joins an assistant to tools, and a tool here isn’t a hammer: it’s something a program can do when asked, like adding a latte to an order. If you build with it, a friendly heads-up: its revision of July 28, 2026 dropped the opening hello, the handshake, where the two sides traded versions and said what each could do. An older tutorial might still teach it. A2A is the Agent2Agent protocol, now at version 1.0. It’s how agents talk with each other, like the cart’s app asking the bakery’s agent about tomorrow’s pastries. An API, short for application programming interface, is a program’s front counter, where other programs place their orders. And OpenAPI is a standard way to describe a web service’s counter in writing: what you can ask for and what comes back, so other programs, like the web client on the drawing, know how to order. WebMCP, still a draft, lets a web page offer its tools to an agent working in your browser. AGENTS.md is an open agreement too, and so is one that isn’t on the drawing, Agent Skills. Both are kinds of files an agent reads, not protocols that run over a connection. AGENTS.md is like house rules taped up inside a project for the coding agents that work on it. And a skill is know-how an agent picks up when a task calls for it. And llms.txt, still a proposal, is a short note a website leaves for any agent that stops by, summing up the site and pointing to plain copies of its pages.

Before we sort them, one small word to keep straight. Here, the app is the one you chat in, where the assistant lives. On the last drawing, the cart’s app sat on the other side of the join: it was the server, offering its tools. Same word, different seat. Now let’s sort a few together. Today’s menu is a resource. Adding an item to an order is a tool. And a template for the week’s special is a prompt: a ready-made starting point a person picks from a list. That’s a narrower meaning than the everyday one. Most of us say prompt for whatever words we hand a model, like anything typed to a chatbot, and later on we’ll use it that way too. And a refund? That’s a tool too, one a person approves every single time the model reaches for it. So when we say the model decides, we never mean nobody’s watching.

So far we’ve looked at the joins. Now let’s look at something that crosses them: an assistant’s answers. If you’ve ever wondered whether your assistant gets the facts right when it’s brief, and just as right when it’s chatty, this part is for you. To get there, we’ll lean on a phrase that sounds rather grand, geometric reasoning, and you’ll hear it used at least three ways. A neighboring field even has a name that starts the same way. So when it comes up, it’s kind to say which one you mean before anyone starts arguing. If the last three sound like a lot, that’s all right. They’re here so you’ll know them when you hear them. The first one is ours, and it’s a plain idea. Think of writing every size and flavor on the menu board first, then tasting each one in turn. We do the same: we write down ahead of time the ways an assistant’s answers may vary, and each kind of answer becomes a point we can measure. Those ways, written down first, are what the slide calls a declared design space. And why geometric? Once each kind of answer is a point, we can ask which points sit close together, the way you would with towns on a map. The next three slides build on that one.

Think of three little switches for how the cart answers, each one either up or down. The key under the cube calls the traits by short names: length for brief or detailed, formality for formal or casual, and certainty for cautious or bold. Each trait is one axis of the space, one direction you can move in. And why do we call the drawing a cube? Picture a cube balanced on one corner. From top to bottom, its corners come in rows of one, three, three and one, just like the drawing. Its eight corners are our eight points, two choices three times over, and each edge joins two points one trait apart. Take 011 and 111: only the first switch differs, brief against detailed, so they’re one step apart. If you’ve met these ideas before, you may know them by other names: a statistician calls this a two-level full factorial, and a coder calls the distance Hamming distance. And a small thing the engineers will like: nobody writes the points or the distances out by hand. The program works them out from the three traits every time, so they can never fall out of step with the traits. The table beside the cube holds a made-up score for each point. It stands in for whatever we’d measure there, say, how often the answers at that point get the facts right. And for the owners here: your assistant’s voice is something you choose on purpose. Say you’d like the cart’s answers brief, casual and bold. That’s 011, the outlined point, and its score is the one you’d watch. In our made-up example, its 0.7 would mean seven answers in ten get the facts right.

Don’t let the funny words throw you; we made them up on purpose, and we’ll say why in a moment. A fact sheet is just a short list of facts we hand the assistant, along with one question about them. Let’s read the violet path from the top. We call it the proof, because it’s the chain of facts that leads to the answer: the brintepet is a lomkellet, every lomkellet is a kellbrinet, and every kellbrinet is dairy-free, so the answer is yes. The changed sheet says instead that no kellbrinet is dairy-free, and the answer turns to no. That’s what the little “was” and “now” on the last arrow mean. The grey chain on the right is made of side facts, the distractors: every zorquilet is a zorbrinet, and no zorbrinet is dairy-free. Flip one of those, and our answer has to stay put, because nothing links the brintepet to that chain. And here’s why we score pairs. Picture an assistant that says yes to everything. One question at a time, it looks right whenever the answer is yes. But every pair that flips has a no on one side, so it misses them all. So does any assistant that gives both sheets the same answer. Why made-up words? If we said oat milk, a model could answer from what it already knows about oat milk, without reading the facts in front of it. Made-up words leave it nothing to go on but the sheet. For the owners here, it’s the same check you’d want after you change your price list: did the assistant really read the new one, or answer from habit? Now a few names for the engineers, and everyone else can let them drift by. Researchers build pairs like these by hand and call them contrast sets, and you may hear the two sheets called canonical, the original, and perturbed, the changed one. Here one program writes the pairs, and another, which we call the oracle, is our answer key. It follows the facts to the right answer for both sheets, so nobody types an answer by hand.

It’s a bit like one recipe served eight ways: the ingredients never change, only the plating. Here, the question on our sheet is which dairy-free latte the cart can make. Its facts say oat milk is dairy-free and whole milk isn’t, so the right answer is a latte with oat milk. And yes, this time the words are real. That’s all right here, because this check asks something else: does changing the voice change the answer? Whatever the model already knows about oat milk, it knows just the same at all eight points. On the drawing, the little boxes t1 to t8 are the eight tones, one for each point, and no two alike. And here’s the thank-or-blame part. Say the assistant gets the latte right at 011 and wrong at 111. Only the length changed between them, so length is where we look. Every part of an answer, every field, is marked one of two ways: invariant, meaning it stays locked, or expressive, meaning it may change. If nobody marked a part, we count that as a fault, rather than quietly guessing which kind it is. And the program that checks a family lists every fault it finds at once, like a missing point or a changed answer, so one round of fixes can clear them all. It’s like a good teacher who marks the whole paper, instead of stopping at the first wrong answer.

Think of a harness on a horse: the horse brings the strength, and the harness guides where it goes. And by typed code we don’t mean code someone typed at a keyboard. We mean code in which every value has a declared kind, a time, say, or a booking, and the computer checks those kinds before the program ever runs. Now let’s follow the drawing down together. A turn is one message from the customer and the reply to it, and the frame around the two lanes is one time limit for that whole turn. On the left, the harness picks the facts, makes the list of open times and builds the schema from it, a form the answer has to fit. On the right, the model reads the prompt and sends back one answer: a choice and a reply. Both lanes meet at the contract box. That’s the checker: it holds the answer up against the offers and the facts. Three doors lead out of it, and only one, passed, holds a time for the customer. The short line off the frame’s right edge is for a turn that runs out of time: it goes straight to the salon’s fallback line. We’ll open the other two doors on the next slide. So one offer list, the open times, does two jobs. It reaches the model as the schema, which limits what the model can write. And it feeds the checker, which decides what the harness accepts. Now two names for the engineers, and everyone else can let these drift by. Researchers call this pairing LLM-Modulo, LLM being short for large language model. They argue that a language model can’t verify its own plans, so they pair it with checkers that sit outside it. And a property test tries many cases the computer makes up, to be sure the form and the checker keep agreeing.

Let’s say the title plainly. When a whole turn fails, say the tries or the time run out, none of the model’s answer goes out, not even part of it. And when all goes well, nobody touches up the reply on its way out. It goes out just as the model wrote it, so nothing half-fixed ever reaches a customer. Think of a shop door that stays locked when the power goes out, rather than swinging open. Engineers call this failing closed. When a turn fails closed, the salon’s own words, written in advance, go out instead. That fallback is like a pre-printed card: there’s no blank on it for the model’s reply or a held time, so it can’t carry one by accident. What went wrong inside stays in the records, away from the customer. And every reply that did go out can be traced back through the records to what made it.

Let’s read the drawing from the top down: time runs down the page, and each arrow is one message. The customer asks for Saturday morning, and the app sends the booking. The server answers that it needs one thing first, which time, and hands back a signed note of what it offered. The app asks the customer, 10:30 or 11:30, and the customer picks 11:30. Then, in the violet round, the app sends the booking again with the answer and the note, and the server says it’s complete. Think of the signed note as a written quote, signed and dated by the shop. It spells out the times on offer, and the app holds on to it, so the server doesn’t have to keep a drawer of half-finished bookings in between. The server can tell if anyone has changed it, it’s good for only a short while, and it’s honored only once. For that last part, the server does remember one small thing: which quotes it has already honored. A time that was never offered is turned away before anything is booked. And the app is just as careful. It reads every reply against the agreed shape, the way you’d check a delivery against the order slip. Either every part it uses checks out, or it uses none of it. Now a few names for the engineers, and everyone else can let these drift by. In MCP’s own words, two rounds like these are a multi round-trip request, and the signed note is the request state. And MCP calls the app the client here: the program that sends the requests, not the customer.

This fork isn’t the one in your kitchen drawer. To fork is to copy the whole program and change the core in your own copy, and that’s what we steer away from. The core is the violet loop on the drawing: the model asks for a tool, the tool’s result comes back, and round it goes until the model has its answer. An instruction, in a skill or a standing instructions file, is a request; the model might not follow it every time. A hook is a small piece of code that runs at a set moment: before a tool call, after one or at the end. It runs every time, and one that runs before a call can stop the call outright, so it’s a rule, not a request. An instruction is a note on the fridge; a hook is the lock on the till. So a house habit, say, how you like things named, is a judgment call: it goes in the standing instructions, where the model reads it. A must, like a check every page edit has to pass, goes in a hook. A subagent is a helper the model hands one job to, and it works in a context of its own. One set up ahead of time for that job starts fresh: it begins with only what it’s handed, not the whole conversation so far. Think of a helper at a clean counter with one recipe card: they cook just that dish and bring back only the plate. When we build a harness into an app of our own, it grows the same way: at the places made for add-ons, never by changing the core. And every part we add comes with a scenario that tests it: a short written example of what it must do. For the owners here: when the harness updates, an add-on carries over by itself, while a patched core has to be patched again by hand.

A claims ledger is just a list: each claim, where it came from, how much proof is behind it, and what would show it false. Measured means someone tested it and showed how, like a scale the inspector has checked. Released means its code and data are out for anyone to check, like a recipe printed for anyone to bake. Asserted means someone only said so, like “best in town” on a jar’s label. For this promise, the source is the maker’s own page and the status is asserted, and two overlapping bookings in a test calendar would show it false. So we build on what’s been measured or released, and an assertion waits in the ledger until something checks it. And the second question is a fair one too. The names and version numbers keep moving, but a booking form still hands an appointment to a calendar, and something still has to check it.

Nobody can promise what the future holds, and we won’t pretend we can. Part of the work really did get cheap, and it’s honest to say so. The other part, standing behind the result, still takes a person. And if you’re just starting out, that’s good news: it’s the craft worth learning, and tonight’s three questions are a fine place to begin.

Thank you for staying with us through all of that. Here’s something small to take home. If you run a business, pick one join it runs on, a form, a price list or a booking, and ask what checks it today. If you’re a student or an engineer, try the same on any app you use or build: which two things does it join, what crosses, and what checks it? Wherever the answer is nothing, that’s the join to give an agreement first. And now it’s your turn: what would you like to ask?