My session at Internet Identity Workshop (IIW) next week will show a pico moving from one engine to another. A bike club sells Gravel Bike #7 to a new owner, and the pico that represents the bike, along with the child pico for its bike computer, moves from the club’s mesh to the new owner’s mesh. Its identity comes along, and so do its relationships. I described the mechanics (with a video) in Moving Picos from Mesh to Mesh; here I want to explain why I think it matters.

It’s easy to see a demo like this as a migration feature, the kind of thing an operations team uses to shuffle workloads between data centers. That is not my primary goal. My aim is loftier: portability is how people keep control of their online lives without having to run the infrastructure themselves, and identity is what makes portability work. In other words, identity enables autonomy.

Freedom Requires Portability

Personal freedom online requires that we control our apps and our data. I’ve been making some version of that argument for decades. For example, in The CompuServe of Things, I worried that the Internet of Things was being built as a collection of walled gardens, each with its own servers, accounts, and terms of service. If the company running the server decides your thermostat is no longer supported, the thermostat stops being yours in any meaningful sense. The same is true of the apps and data that run the rest of our lives.

The obvious answer is to run your own servers, but realistically, most people never will. That isn’t a failure of will or education; it’s the same reason most people don’t generate their own electricity. Hosting is a service, and people should be able to buy it the way they buy other services, so long as they can freely move to another service. A renter doesn’t own the apartment, but they own the furniture, and when they move, the furniture goes with them. Apps and data should be the same: hosted by someone, but not owned by them.

Spheres of Control

Every hosting arrangement comes down to a simple question: whose rules apply? In the physical world, we answer it without thinking. The things in your house are yours to use, lend, or rearrange; the things in a store belong to the store until you buy them, and the store sets the rules for handling them. Each of us has a sphere of control, the set of things we get to make decisions about, and we move through other people’s spheres all day long without confusing them with our own.

Online, those boundaries are much harder to discern. An app on your phone feels like yours, but in most cases the app’s logic and the data it collects live on someone else’s servers and follow someone else’s rules. You’re a visitor in the provider’s sphere of control, even when the subject is your own health, your car, or your bike. The important question isn’t who hosts the app; it’s whose sphere of control the app and its data belong to.

Figure 1 shows how most apps work today. The app and the data about you sit inside the provider’s sphere of control, and you reach both through the provider. You use the app, but the provider decides what it does, what happens to your data, and how long either one exists.

Figure 2 shows a better model. The app and the data sit inside your sphere of control, and the company that used to be the provider becomes a partner that works with your data on terms you set, labeled “my terms“ in the figure. The components in the two figures are nearly identical. What changes is who’s in charge.

I first imagined the arrangement in Figure 2 in the area of IoT, where every connected thing could have its own app under its owner’s control rather than its manufacturer’s. That was hard to realize when every app had to be built and maintained by someone with a business reason to do it. AI changes the calculation. As I wrote in There’s a Personal App for That, building a custom app for a single person or organization is now a morning’s work. When apps are that cheap to make, software stops looking like a few products with millions of users and starts looking like a billion small markets. Those apps need somewhere to live that the person controls, and they need to be able to move.

Identity Is the Foundation

Portability sounds like a storage problem: export the data and import it somewhere else. The hard part is everything that points at the thing you moved. A pico does its work through relationships with other picos, and if moving it breaks every relationship that refers to its old address, the pico hasn’t really moved; it has been orphaned. Identity is what lets the rest of the world still recognize something that has moved.

That’s why some of the recent pico engine work focused on pico-to-pico identity. Each pico carries two kinds of DIDs, and they do different jobs in a move. The did:webvh is the pico’s public identity, the passport it hands to strangers. Its self-certifying identifier (SCID) survives a move; only the host and path change, and anyone who resolves the DID finds the pico at its new location.

Relationships ride on something else. Each relationship is based on a pair of did:peeridentifiers, private, point-to-point names with no engine address baked into them. The picos use them to exchange messages using DIDComm. After a move, the pico sends a rotation message to each of its peers, and each peer updates where it sends traffic for that relationship. Nothing has to be reintroduced; the did:webvh keeps the pico findable, and the peer DIDs keep its relationships intact. In the demo, four things move together:

• The subtree — the bike pico and its children export as a portable blob and import on the new engine. This isn’t federation of whole engines; it’s one subtree changing hands.

• The identity — the SCID stays the same while the DID’s host and path follow the engine.

• The relationships — they’re kept whole, even when that means converting a local ECI-based relationship into a DID-based one.

• The app — the application and all its data move from one sphere of control to another.

The last item is the point the demo is trying to make. The new owner doesn’t get a data export from the club’s system; they get the bike’s pico, with its functionality, history, and relationships, running in their own mesh.

Identity Enables Autonomy

A personal app needs more than code; it needs a place to keep its state, a way to talk with the people, devices, and services it works with, and an identity those parties can rely on. Picos package all of that together. The name itself is short for “persistent compute object” and that’s been the goal for as long as picos have existed.

Each pico persists its own logic and data, responds to events from anywhere on the internet, and carries its relationships with it. Because the whole package travels as a unit, moving a personal app from one host to another becomes an operation rather than a rewrite. The host provides a place to run; the pico is the app.

Selling a bike is one reason to move a pico, but there are many others:

• Resilience — leave a host that fails, turns hostile, or censors.

• Economics — find cheaper compute or storage.

• Latency — get closer to the people, devices, and other picos it works with.

• Bandwidth — move toward the data instead of hauling it across the network.

• Jurisdiction — live on infrastructure with the right governance and data-handling rules.

• Ownership — follow a sale, or simply avoid lock-in.

Today, a person or a program acting for them decides when a pico moves. And does the exporting and importing by hand. What I ultimately want is for a pico to move itself on command and, eventually, on its own judgment, weighing cost, latency, reliability, and trust to decide where it should live. Getting there takes more work. Moves need to be atomic, with rollback when something fails halfway and forwarding from the old location; the engine needs to transfer exports and clean up the donor rather than leaving those jobs to the operator; and we need far more testing against relationships that cross subtree boundaries and external systems that remember old addresses. I expect the sharp edges to show up as soon as people use this for something other than my demo.

Picos are persistent objects with their own identities and relationships, not session tokens issued by whatever app happens to host them. That distinction is what makes everything else possible. An app whose identity belongs to its host can only live where it’s told. A pico with its own identity can choose where it lives, just like the person it works for. Identity enables autonomy.

Photo Credit: A pico comes home to its owner from ChatGPT (public domain)

When I was in grad school, Smalltalk was all the rage. Commercial Smalltalk systems were expensive, so we didn’t get much time with them, but the experience of sitting at the console and building something by interacting with a live system has always stuck with me. You didn’t write a program and then run it. You worked inside a running world of objects, poked at them, changed them, and watched what happened.

In time, the software industry settled on the C model of edit, compile, and run because it offered reproducible, reasonably portable code on standard operating systems. Java arrived in the 1990s and stole the object-oriented limelight with a C-style syntax and a familiar build model. Smalltalk slowly faded into relative obscurity. Still, I never forgot the joy of working with a live system or the convenience of debugging from a console against a real image. So when we built the pico engine, Bruce Conrad built a developer UI that lets you see a pico mesh, send events and queries to any pico in it, and examine the results.

The latest release of the pico engine, version 1.8, doubles down on that idea and makes the developer experience better than it has ever been. And since developers now often include AI agents, we’ve made it better for them as well. An accompanying Manifold 1.8 release brings the Manifold rulesets along. This post describes the changes and why I think they matter beyond the developers who write KRL.

Smalltalk’s Vision for Developers

A Smalltalk system wasn’t a program you compiled. It was an image: a saved snapshot of a whole world of live objects, including the classes, the windows, the compiler, and the development tools themselves. You started the image and picked up where you left off, with every object still holding its state. Everything in that world was an object, and objects talked by sending messages. Alan Kay later said that calling it “object-oriented” was a mistake because the big idea was messaging; what mattered was what happened between objects, not what was inside them. That idea runs through actors and, eventually, to picos, as I described in Closures, Objects, Actors, and Picos.

The tools were where Smalltalk put developers first. Each was a live view into running objects:

• Browser: every class and method in the system, including the system’s own source, open for editing, with changes taking effect immediately.

• Workspace: a scratch pad where you could select any expression and do it, print it, or inspect it against real objects before committing it to a method.

• Inspector: open any object, see its instance variables, and change them in place.

• Debugger: stop on an error with the live stack intact, fix the method right there, and resume.

Together these collapsed the edit, compile, run, and debug cycle into one continuous conversation with a running system. You didn’t reproduce a bug; you were already standing in it. And Kay had a bigger goal than developer convenience. His Dynabookwork at Xerox PARC imagined a world where children and other non-specialists would use Smalltalk to build their own tools. Users would be builders, not just consumers of software. Both of those ideas, the continuous conversation and users as builders, sit at the center of this release.

Changes to the Testing Tab

The Testing tab in the pico engine UI has always been the closest thing we had to a Smalltalk workspace. You pick a pico, choose an event or query, fill in some attributes, and send it. Until now, though, the forms came from a hidden __testing structure that the compiler guessed at exposing a cacophony of confusing choices in the Testing tab without much quidance.

In 1.8, the Testing tab is built from the ruleset’s schema, which I’ll describe in a moment. That brings several improvements:

• KRL console: evaluate a KRL expression in the context of an installed ruleset on a pico, with access to its global functions, its modules, and its entity variables. This was something that Classic Pico Engine had that I’ve missed since we rewrote it in Node many years ago.

• Typed forms and presets: each operation shows its attributes with types and descriptions, and any @example in the ruleset becomes a pre-filled form.

• Rule outcomes: when you send an event, the response tells you, for each annotated rule, whether it fired, was selected but didn’t fire because its condition was false, or wasn’t selected at all because an attribute pattern didn’t match.

• History and saved requests: every request you send is kept with its outcome, and you can name and save the ones that work. These live in the pico, so they move with it when the pico moves to another engine.

• Copy as @example: a request that works on a live pico can be copied into the ruleset as an example, promoting something you discovered by experiment into the source to guide others using that ruleset.

The console is the piece that feels most like Smalltalk. Want to know how many relationships a pico has? Evaluate ent:established.length() in the subscription ruleset and see the answer from the running pico rather than reasoning about what it ought to be. The console is read-only by construction; it compiles your input as an expression and runs it the way a query runs, so it can’t assign entity variables or take actions. It’s also owner-only, available on the UI channel and to the local developer tools, never on discovery or app channels. The Rulesets tab gets a companion Docs view that renders each ruleset’s documentation from the same schema, with a “Try it” button next to every example.

Changes for Agents

Coding agents like Claude Code and Cursor work best in exactly the loop Smalltalk made famous: try something, observe the result, and adjust. A person can stare at code for a long time before running it. An agent learns by running it, many times, and anything that makes the loop slow or silent hurts an agent more than it hurts a human.

Version 1.8 attacks the loop from both ends. On the checking side, krl-check parses and compiles a ruleset, lints its annotations, and reports errors with line and column. Installing or flushing a ruleset now validates it first, and a failure raises wrangler:ruleset_install_failed or wrangler:ruleset_flush_failed with the errors so they can be handled programmatically.

On the live side, rule outcomes and the console give an agent the same answers they give a person in the Testing tab. Each of the repositories now carries a CLAUDE.md and AGENTS.md explaining layering, conventions, and commands, and the engine serves its documentation as llms.txt along with an OpenAPI description of its HTTP API.

The engine also has a built-in MCP server with two faces. The first is for agents acting as developers. Running pico-engine mcp --stdio connects an agent to a local engine with tools to validate and install rulesets, create and delete picos, raise events, run queries, evaluate expressions in the console, and tail the event log. Our bar for the release was simple: a fresh Claude Code session with only CLAUDE.md and the MCP server should be able to start an engine, write a ruleset that passes krl-check, install it, raise an event, and query the result without ever opening the wiki. That’s the Smalltalk loop, carried out by an agent. I’ve already used this multiple times, telling Cursor to update a live mesh rather than doing it myself.

The second face is for agents acting as operators of a running mesh. Any channel can be reached over Streamable HTTP at /mcp/<eci>, where <eci> is the channel’s ECI, using an OAuth bearer token scoped to that channel. The tools aren’t written by hand; they’re generated from what the channel allows, one tool for each event and query the channel’s policy permits. When we built a conversational interface for Manifold, my students hand-wrote MCP wrappers for Manifold’s events and queries. The mesh MCP server generalizes that work to any pico, and it can do so because of the schema.

Schema as a Foundation for It All

The change that makes everything above possible is that a pico can now describe itself. Ruleset authors add structured doc comments, /** ... */, directly before the rules and shared functions they want callers to see.

We considered declaring events and queries in a block inside the ruleset’s meta section and rejected it for three reasons:

1. A declaration in meta is a second copy of every event and function, far from the code, and it will drift.

2. It describes events, but functionality lives in rules, so it needed extra machinery to say what a rule’s select when already says.

3. It would have had to absorb shares, forcing every existing ruleset to change.

Comments on the rules themselves avoid all three problems. Here’s an annotated rule from Manifold:

/**
 * Create a thing pico as a child and subscribe it as a manifold_thing.
 * Only fires while Manifold has fewer than max_picos children. When the thing is
 * fully initialized, community:thing_created is sent to callback_eci with the
 * caller’s rcn.
 * @attr name String “display name of the new thing”
 * @attr callback_eci String optional “channel to receive community:thing_created”
 * @attr rcn String optional “caller’s correlation id, echoed in the callback”
 */
rule create_thing {
  select when manifold create_thing
  ...
}

The author writes only what the code can’t say: a description, the attributes the rule cares about, and their types. Everything else is derived by the compiler: the entry event from select when, any constraints in its where clause, the rule’s condition, the shared functions a caller can check in advance, and the events the rule may raise or send. Annotations are opt-in. A rule without one still runs; it just isn’t advertised. Annotations also decide only what is advertised, never what is permitted; shares still decides what is queryable and channel policy still decides who may do what.

From those annotations the engine builds two schemas. The ruleset schema describes what one ruleset offers, rule by rule, with all the derived detail a developer wants. That’s what the Testing tab and the Docs view use. The pico schema merges the ruleset schemas of every ruleset installed on a pico into one aggregate, grouped by event, because a caller doesn’t care which ruleset handles an event, only what it can send and query. Filter the pico schema by a channel’s policy and you get a channel schema: what someone using this particular can do.

That chain, from ruleset schemas to pico schema to channel schema, is what the rest of the release consumes. The Testing tab, the Docs view, discovery bindings for integrators, and the generated mesh MCP tools all read from it, so they can’t disagree with each other or with the code. The surface that a developer sees in the UI is the same surface an agent sees through MCP.

The schema also turns reference documentation into a build step rather than a writing task. The engine repository includes a krl-schema tool that reads a ruleset’s annotations and derived data and writes a reference page in Markdown: each operation with its entry event, attributes, condition, and the events it may emit, and each query with its arguments and return type. Because the page is generated from the same schema the engine uses, it can’t fall out of date the way hand-written ruleset documentation always has. A project can feed the same output into its llms.txt, so the reference an agent reads matches the one a person reads.

Why the Pico Engine Is Different

If live systems were so good, why did edit, lint, and compile win? Mostly because of the image. Code lived inside it alongside the objects, which made Smalltalk hard to version, diff, and merge in a world that standardized on text files and version control. Images accumulated state in addition to the run context, so “it works in my image” was a harder problem than “it works on my machine.” And Smalltalk was a world of its own that didn’t integrate well with other operating system or languages.

Liveness didn’t die, though. It survived as a layer on top of files: REPLs, Jupyter notebooks, the browser’s developer console, hot reload, and things like Erlang’s hot code loading. Files won as the source of truth. Liveness stayed as the way you explore. But several things have changed since Smalltalk lost that argument:

Many of today’s systems are long-lived and stateful. A pico or a cloud service runs for months, accumulating state, and new code changes what that running thing does rather than starting a fresh program. That’s the world Smalltalk assumed, and it’s the world picos live in.

But picos don’t have to choose between Smalltalk’s model and the file-based one. Smalltalk merged code and state in one image, and that’s what made it hard to version and reproduce. Picos separate the two. Code lives in rulesets, which are text files at URLs, versioned in git and checked by krl-check. State lives in picos, which are persistent, always on, and live; you talk to them through the Testing tab, the console, events, and queries.

Version 1.8 strengthens both sides at once. Validation on install, install-failure events, and krl-check make the file side better. The console, rule outcomes, and schemas make the live side better. The developer MCP server gives an agent both in one loop: write a file, check it, install it, and then have a conversation with the running pico. Smalltalk was right about the live conversation, and the industry was right about files. Now that agants can be builders too, you need both.

Other Changes

Two other changes deserve mention. The first is a fix to channel policy. As of 1.8, denyoverrides permit, so a narrow deny can’t be widened by a broader permit. Parents can set a policy ceiling when they create a child so that the child can’t create channels more permissive than its parent allows, operators can configure engine-wide deny lists, and wildcard channels can optionally require a validated caller identity. This might look like an operator concern in a release for builders, but it’s what makes the mesh MCP server safe to use. Tools generated from a channel’s schema are only as safe as the channel that scopes them, and a leaked ECI shouldn’t be a key to more than it was meant to open. We published an audit of the engine’s channel policies alongside the release.

The second is an engine configuration file. Engine settings can now live in ~/.config/pico-engine/config.json, or in another file named with pico-engine -cor PICO_ENGINE_CONFIG, which makes running several engines on one machine much less fiddly. Environment variables still work, but the config file wins when both are set. Here’s the example config that ships with the engine:

{
  “home”: “~/.pico-engine”,
  “port”: 3000,
  “baseUrl”: “http://localhost:3000”,
  “allowSelfSignup”: false,
  “allowLocalhostChannelBypass”: true,
  “wildcardSkyRequireBearer”: false,
  “logToStdout”: false,
  “webauthn”: {
    “rpId”: “localhost”,
    “origin”: “http://localhost:3000”,
    “rpName”: “Pico Engine”
  }
}

The complete list of configuration options, along with the environment variables they replace, is in the operator guide. The guide also covers running several engines on one host and the new policy settings, such as defaultRootPolicyCeiling and the global deny lists.

Annotations are only useful if people know how to write them, so we annotated the rulesets that every pico engine developer already depends on. The main Wrangler ruleset, along with its companion subscription, PDS, OAuth, and other rulesets now carry annotations in place of the hand-maintained __testing maps they used before. That makes them the first place you’ll see the new Testing tab and Docs view at work, and the place to look when you want to see how a rule with forwarded attributes or several @example presets is described. If you’re annotating your own rulesets, start by reading Wrangler’s.

The Manifold 1.8 release does the same for a framework built on top of Wrangler. Manifold’s rulesets are annotated throughout, including the delegation rules, like create_thing above, that take a callback_eci and correlation ID and finish their work asynchronously. Its ruleset reference pages and llms.txt are generated with krl-schema, which makes Manifold the first full example of documentation built from annotations. SafeAndMine and the Journal ruleset build their discovery bindings with wrangler:schemaBindings rather than hand-written maps. The release also adds a Home Assistant notification channel and retires the old skills registry in favor of the engine’s MCP server.

Builders

In Smalltalk, the conversation with a running system was a metaphor. You typed an expression, chose Do It, and the system answered. With an agent on the developer MCP server, the conversation is literal. Imagine telling an agent, “make a pico that watches my freezer sensor and tells me when it gets warm.” The agent creates the pico, writes the KRL, validates it, installs it, raises test events, reads the rule outcomes, and reports back. That’s the same live loop, carried out in plain language, and the 1.8 features are what make it work: errors the agent can act on, outcomes that say why a rule didn’t fire, and a console that shows real state instead of a guess.

Kay’s second idea, users as builders, is the one I find most interesting, partly because it mostly didn’t happen. Smalltalk became a tool for professionals. The real successes in end-user building were spreadsheets and HyperCard, and both succeeded by narrowing what you could build. The barrier was never just the tools; building required learning a formal language. Agents lower that barrier in a way Smalltalk couldn’t. A builder now needs to know what they want and be able to judge whether they got it, not how to write KRL. That changes who gets to shape the software that acts on their behalf. A builder who isn’t a developer, working through an agent, needs a few things from the system, and the MCP surface is where 1.8 provides them:

Smalltalk trusted everyone inside the image, and that was fine when the image belonged to one programmer at one workstation. A world where systems interact and people build through agents can’t make that assumption. Picos have always had channel policies; what 1.8 adds is tightening them and tying the schema to them, so what a builder’s agent can see is exactly what it’s allowed to do. None of this finishes Kay’s project; plenty of hard problems remain between “tell an agent what you want” and software you can rely on. But it moves the line. Version 1.8 gives the people who build with picos a live conversation with the running system, and it opens that conversation to builders who don’t have to be programmers. That’s who this release is for.

Photo Credit: Building in conversation with a pico from ChatGPT (public domain)

I’ve been intrigued by closures ever since I taught an introductory computer science course from Structure and Interpretation of Computer Programs (SICP) at UC Davis in 1988. Watching students realize that a function plus the environment it was born in was enough to build objects, with no classes and no special syntax, was one of the great pleasures of teaching that course. I’ve followed the idea around ever since and used it wherever I could. When I built picos, I described each one as a closure over services and data. I’ve also described picos as implementing the actor model of distributed computing. But as this week’s post on moving picos between engines shows, they’re something more than that.

Closures in SICP

A closure is a procedure bundled with the environment in which it was created. When you call it, the body runs against bindings that were captured at creation time and that nothing outside the closure can see. Chapter 3 of SICP uses this to build a bank account:

(define (make-account balance)
  (define (withdraw amount)
    (if (>= balance amount)
        (begin (set! balance (- balance amount))
               balance)
        “Insufficient funds”))
  (define (deposit amount)
    (set! balance (+ balance amount))
    balance)
  (define (dispatch m)
    (cond ((eq? m ‘withdraw) withdraw)
          ((eq? m ‘deposit) deposit)
          (else (error “Unknown request” m))))
  dispatch)

(define acc (make-account 100))
((acc ‘withdraw) 50)   ; => 50

The variable balance lives in the environment that make-account created, and the only way to reach it is through dispatch. Each call to make-account produces a new environment, so every account has its own private balance. SICP calls this style message passing: you don’t operate on the account’s data; you send the account a message and it decides what to do.

SICP is also careful about what this costs. Once a closure holds mutable state, two accounts that start with the same balance are no longer interchangeable, and the book spends a section on sameness and change to work through what that means. With state comes identity. That observation turns out to be the thread that runs all the way to picos.

Closures and Objects

The account above is an object in every way that matters: encapsulated state, behavior bound to that state, and an interface defined by the messages it accepts. make-accountplays the role of a class, and dispatch is a hand-built method table. There’s an old programming koan that captures the equivalence: closures are a poor man’s objects, and objects are a poor man’s closures. Each can be built from the other.

What object-oriented languages add is vocabulary and machinery. Classes give the constructor a name and a place to live; inheritance lets one dispatch table extend another; method syntax spares you from writing the cond yourself. Those are real conveniences, but they don’t change the underlying model. An object, like a closure, lives in one address space, is named by a pointer that means nothing outside that heap, and is invoked by a synchronous call that runs on the caller’s thread. When the process ends, so does the object.

Actors

The actor model, introduced by Carl Hewitt in 1973 and formalized by Gul Agha in the 1980s, takes message passing literally. An actor has private state and a mailbox. It processes messages one at a time, and in response to a message it can do three things: send messages to actors it knows about, create new actors, and decide how it will handle the next message. Messages are asynchronous; the sender doesn’t wait, and there is no shared memory between actors.

Agha’s framing of an actor as a closure with a mailbox is the halfway point between the SICP account and a pico. The dispatch is still there, but the call has become a message in a queue, and the one-at-a-time rule replaces locks as the way an actor protects its state. Actors also introduce something closures and objects lack: an address that is useful only to those who have been given it. Knowing an actor’s address is the capability to talk to it. That’s a short step from a reference to a relationship.

Picos

A pico is an actor, and you can easily translate the SICP account to KRL. Here’s the withdraw written as a KRL rule:

rule withdraw {
  select when account withdrawal
  pre {
    amount = event:attrs{”amount”}
  }
  if ent:balance >= amount then noop()
  fired {
    ent:balance := ent:balance - amount
    raise account event “balance_updated” attributes {
      “balance” : ent:balance
    }
  } else {
    raise account event “insufficient_funds” attributes {
      “balance” : ent:balance,
      “amount” : amount
    }
  }
}

The entity variable ent:balance is the captured environment, the select when clause is the dispatch, and an account:withdrawal event is the message. Each pico has its own event queue and retrieves events from it one at a time, just as an actor drains its mailbox. A pico usually has several rulesets installed, each with its own entity variables, so it’s more precisely a set of closures over separate environments that share one identity and one event queue.

Where picos depart from closures, objects, and most actor systems is that they insist on surviving. A pico’s state is persistent by default, so it outlives the process that happens to be running it. Picos are internet-first; its identity is a DID that anyone on the network can resolve, not a pointer or a runtime address. Its references to other picos are channels and peer DIDs, each named, governed by policy, and revocable, rather than raw pointers with unlimited authority. And its code can change over its lifetime as rulesets are installed and removed. Each of those properties follows from the first: once state has to outlive the process, it has to be persistent; once a persistent entity can be reached from anywhere, its identity has to be a name; once that name can be handed to strangers, the reference has to carry policy.

Those same choices are what make a pico movable. Nobody moves closures between machines, because the captured environment is opaque and full of pointers into the local heap; the mobile-code systems that tried, like Emerald, Obliq, and Telescript, had to invent restrictions to make it work. A pico never captures anything that can’t follow it. Entity variables are plain data, rulesets are fetched by URL, and every reference to another pico is a name. Exporting a pico is closure serialization, importing it is rehydration, and the ECI remapping on import is pointer swizzling under a different name.

Side by Side

The table lines up the four models on the properties that change as you move from one to the next. Every cell could be argued at length, and particular languages and actor systems blur some of these lines, but the rows are the properties that matter when you want software to last longer than the process running it.

Read left to right, each column keeps what the one before it had and adds something. Objects give closures a vocabulary. Actors give objects asynchrony and isolation. Picos give actors persistence, a durable identity, and relationships they can carry with them. SICP’s lesson about sameness and change was that state brings identity with it; picos take that seriously enough to make the identity cryptographic and the state portable.

A closure in 1988 was a beautiful way to think about computation. A pico is a closure that has been made to answer for itself in the world, one that can belong to a person rather than being tied to the machine it runs on.

Photo Credit: Closure to Pico from ChatGPT (public domain)

In one of my favorite books, Vernor Vinge’s Rainbows End, Juan Orozco and a pair of troublesome twins play in a public park where the physical world is overlaid with a constantly shifting digital one. Creatures, games, and other virtual constructs inhabit the park, interacting with people and with the networked infrastructure around them. What caught my attention in that scene is that these software entities have an identity independent of any particular piece of infrastructure while still maintaining a relationship with the physical and network environment they inhabit. They exist in the world without belonging to a particular computer.

I think the scene sticks with me because that idea has long been my dream for picos. A pico has an identity, persistent state, rules, and relationships, but none of those things inherently require it to remain on the machine where it was created. If we separate the identity of a pico from its execution location, a pico could move from one host to another while remaining the same computational entity. Other picos and applications could keep interacting with it without needing to know where it’s running.

Why would we want a pico to move? There are plenty of reasons:

• Resilience and censorship: Move away from a host that becomes unavailable, hostile, or filtered.

• Economics: Migrate to cheaper compute or storage when there’s no reason to stay put.

• Latency: Move computation closer to the people, devices, or other picos it interacts with.

• Bandwidth: Move toward a data source rather than continually hauling data across the network.

• Privacy and jurisdiction: Keep a pico on infrastructure with appropriate governance or data-handling rules.

Underneath all of those is a more powerful reason. If your picos can only live on one engine, you don’t own them in any meaningful sense; you’re renting a seat from whoever runs that engine. Portability is how we avoid lock-in, and avoiding lock-in is a precondition for personal agency in a system built from software that acts on your behalf. Version 1.7 of the pico engine, released a few days ago, takes the first real step: a pico and its subtree can move from one mesh to another, on a different engine, while the relationships it has with other picos keep working.

A Bike Changes Hands

The easiest way to see what this means is to watch it happen. The scenario in the demo video shown below imagines a bike club that owns gravel bikes for members to borrow and runs a community pico to coordinate rides. Each bike has a pico that serves as its digital twin: the pico holds the bike’s state and history, has a child pico for the bike’s computer, and has relationships with the club’s Manifold app and with the Trail Ride Community. A ride coordinator with his own mesh has formed a relationship with Gravel Bike #7 so it can take part in the rides he organizes. Then the club sells bike #7, and the bike’s pico needs to move to the new owner’s mesh on a different engine.

The bike club and Alice, the new owner, use Manifold, the framework for managing things and communities that I’ve written about before and recently moved my own sensor network onto. Manifold matters here for a reason I’ll come back to: a thing pico assumes certain services exist above it in the tree, and the destination has to provide them. What you see in the video is the engine’s developer interface rather than anything a bike owner would use; it lets us observe and manipulate the picos directly, which is what a demo of the plumbing needs. Three meshes run on two engines, the club’s and the coordinator’s on one and the new owner’s on the other.

The bike’s pico and its bike-computer child are exported from the club’s mesh as an encrypted blob and imported under the new owner’s Manifold. After the import, the bike has the same did:webvh identity it had before, the ride coordinator’s relationship with it still works, and the Trail Ride Community back on the club’s engine still has a link to it. The new owner’s Manifold forms a fresh relationship with the bike, since that one belongs to the new context rather than the old. Nothing had to be reintroduced.

A pico that stands in for a physical thing grows more valuable the longer it lives, because it accumulates the thing’s history, relationships, and state over years. I made this argument in August using an example from Fuse, where selling a car meant handing its pico to the new owner with the maintenance history intact. The bike is the same idea. Its identity is bound to the bike, not to the club, and it has to be able to outlive any particular owner or engine because the bike will.

What Makes a Pico Portable?

Making a pico portable requires separating what the pico is from where the pico runs. A pico isn’t a process, container, or virtual machine; those are execution mechanisms tied to particular infrastructure. A pico is an enduring computational entity with an identity, state, rules, and relationships. The host pico engine is simply the place where that entity happens to execute.

That distinction defines what has to move. A portable pico needs all the information necessary to recreate itself on a new engine: its rulesets, persistent state, configuration, keys, and information about its relationships with other picos and services. Some of that information needs special handling. Private keys, for example, shouldn’t be copied around indiscriminately. But conceptually the goal is clear: capture the pico’s computational state, transfer it to another compatible host, resume execution there, and retire the old instance.

Identity continuity poses the hard problem. If a pico moves, everyone it interacts with shouldn’t have to get reacquainted with it; its identity must remain stable even when its location changes. That means addressing and routing have to be indirect: send an event to the pico, not to the server currently running it. Some discovery mechanism maps the pico’s enduring identity to its current network location, and moving becomes a routing update rather than an identity change.

Relationships create a similar requirement. A pico might have channels to dozens of other picos in different meshes and even on different engines, and those relationships should survive migration without being recreated. Ideally, the endpoints of a relationship identify the participating picos rather than their hosts, so that after a move messages simply begin flowing to the pico’s new location. Webhooks don’t enjoy this property; each one holds a URL, and every one of them has to be updated by hand when the thing it points at moves. This is the difference between having a protocol and merely having a convention.

One thing I learned building this is that the unit of portability isn’t a single pico and it isn’t a whole mesh either. Exporting an entire mesh is the wrong granularity; the bike club isn’t moving, only the bike is. But a pico rarely travels alone. Bike #7 has a bike-computer child, and parent-child relationships are part of how a pico behaves: children rely on their parent for rulesets, shared relationships, and policy. So what moves is a subtree, the pico and its descendants, and the importer attaches it under a new parent in the destination mesh.

That subtree boundary creates a dependency the design has to take into account. A thing pico inside the Manifold framework assumes Manifold’s services exist above it; importing it under a bare root on another engine would leave it running but functionally broken. The export carries the subtree only, not its ancestors, so the importer is responsible for supplying the platform the subtree expects. In the demo that means adopting the bike under the new owner’s Manifold app pico, which is exactly where a thing pico belongs.

Those pieces are what 1.7 puts in place, and they’re the foundation for the capability imagined in the scene from Rainbow’s End I mentioned earlier. With a stable identity, relationships that follow it, and an export that captures what it is, migration could become part of a pico’s own behavior in a future release. A pico could monitor the environment in which it runs, discover alternative hosts, evaluate them against its own policies, and decide whether moving is advantageous, weighing cost, latency, bandwidth, reliability, jurisdiction, trust, or the availability of particular services. None of that exists today, but nothing in the architecture stands in its way now. At that point portability stops being a deployment feature; just as a pico can react to an event by updating state or sending a message, it could react by moving itself. The infrastructure provides places to run; the pico decides where it wants to live.

Why DIDs Make the Difference

When I added pico-to-pico identity in version 1.6, I said it was the foundation portability was waiting on. That wasn’t a side benefit; I built the layer for this express purpose. Before 1.6, a pico’s only identifiers were its channel identifiers (ECIs), and an ECI is both a local routing address and, in practice, a capability. Change the ECI and you break every peer, UI link, and webhook that holds the old value. Moving a pico while keeping its ECIs is fraught from both a security and an operability standpoint, and moving it without them meant starting over.

Giving every pico two kinds of DIDs splits those concerns apart. The did:webvh is the pico’s stable, long-term address, the passport it hands to strangers. Its self-certifying identifier (SCID) is fixed for the life of the DID, while the host and path in the DID’s log can change; a move appends an entry to the log saying where the pico now lives, and anyone who resolves the DID finds the new location. The did:peer pairs that each relationship uses are private, point-to-point identifiers with no engine address baked into them. Peers follow the DID, and the engine mints fresh ECIs on the new host as nothing more than routing handles.

Relationships survive because DIDComm already knows how to handle a party whose endpoint or keys change. After an import, the moved pico sends a rotation message to each of its peers, and each peer updates where it sends traffic for that relationship. The ride coordinator’s mesh never learned the bike’s new ECI and never needed to; it learned that the DID it already trusted now resolves somewhere else. That’s an example of what it means for identity to be a protocol rather than a convention: the update is a message the relationship was designed to carry, not a chore for the operator.

What Actually Happens in a Move

The export walks the subtree and packages everything needed to reconstitute it: installed rulesets, entity state for each ruleset, channels with their tags and policies, scheduled events, and an identity snapshot for each pico that includes its did:webvh log and keys and its peer relationships. Rulesets with a canonical remote URL are carried by reference and fetched again on import; only rulesets that can’t be retrieved on the destination get embedded inline. The whole package is encrypted with a secret the exporter chooses, because a blob that contains keys and relationship state is a capability-bearing secret and has to be handled like one. Transferring the blob is up to you; nothing in Wrangler moves it for you yet.

The import creates the picos under the recipent parent, mints new ECIs for every channel, and hydrates entity state, remapping any old ECIs that rulesets had stored in their own state. Then it raises wrangler:pico_imported so rulesets can run their own migration logic. With the picos in place, the identity service relocates each did:webvhby appending the new location to its log and notifies every peer of the move over DIDComm. Picos on the destination engine that had relationships with the subtree before it arrived get reconciled locally, so a relationship formed before the move keeps working after it.

What 1.7 implements is more accurately a copy than a move. The import does nothing to the source; the donor subtree is left behind in a vestigial state, still holding the same DID, and has to be deleted once peers have cut over. Leaving it there is worse than untidy, since an engine that still has a local pico with that DID will route to the stale copy rather than the real one. Atomicity, rollback when a move half-completes, and forwarding from the old location are all open problems. The design notes in the repository lay out what’s done and what isn’t.

Release 1.7

Version 1.7.0 of the pico engine ships two things. The first is the portable move described above. Underneath are engine primitives: ctx:exportRulesetState and ctx:importRulesetState for a single ruleset’s state, and ctx:exportSubtree and ctx:importSubtree for a whole subtree. The developer’s interface to that functionality is io.picolabs.portable_subtree, part of Wrangler, which wraps the full pipeline, including DID relocation and peer notification, in a single query to export and a single event to import. On the Manifold side, io.picolabs.manifold_portable_thing in the manifold-api repository builds on that interface to export a thing from one Manifold and import it, with registration, into another. The repository includes a docker-compose file that stands up two engines so you can run the cross-engine demo yourself.

The second is an upgrade to the peer DIDs themselves. Relationships formed on 1.7 use did:peer:4, the variant on DIF’s standardization path, in place of the hand-rolled did:peer:2 identifiers 1.6 used. No npm package existed, so the engine carries a TypeScript port of DIF’s reference implementation that I intend to contribute upstream. Existing relationships keep their did:peer:2 identifiers and keep working; nothing converts automatically, and I’d rather let old relationships age out than rewrite identifiers that other picos already hold.

Just a Start

What I ultimately want is for a pico to move itself on command, and eventually on its own judgment, with the old instance retired as part of the same operation. This release gives us the export, the import, and the identity machinery that lets relationships follow the pico, but the transfer and cleanup have to be handled ad hoc, either manually using the developer console or programmatically in KRL. Those are the pieces that turn a copy into a move.

I also want to be careful about what one working demo proves. We implemented and tested this against a scenario we designed. A scenario you design will contain the cases you thought of. There are almost certainly dependencies between picos, relationships that cross subtree boundaries, and external systems holding old addresses that the bike club demo didn’t exercise. The only way to find them is to move real picos between real meshes, which is why I expect the next few releases to be shaped by what breaks.

The important lesson is that supporting personal agency in a technical system is a choice, and it’s almost always the harder one. Pinning a pico to the engine where it was born is easy; making its identity survive a move took an identity layer, a messaging protocol, and a careful accounting of what a pico actually is. We can build systems that people own or systems they merely rent. The choice is ours, and this release is my vote.

Photo Credit: A pico packs up and moves to a new engine from ChatGPT (public domain)

This post is part of a series on using dynamic authorization to control and coordinate AI agents. See the series recap to find other posts in this series.

I’ve been writing about how we can use Cedar to control agent actions and releasing demos showing Cedar as the authorization step in OpenClaw. One of the constant worries with agents is that a sufficiently motivated agent will find creative ways around controls. For example, I might think to limit access to a specific directory, but not think to keep the agent from creating a link to it so that the policy allows what it would otherwise deny. Policies are written by people who can’t anticipate everything; agents are very good at finding the thing we didn’t anticipate.

One way to protect high-impact actions is by putting a human in the loop (HItL). Some actions, like sending email on my behalf, moving money, or deleting data, carry consequences that are hard to undo. For those, I don’t want to rely solely on having written the perfect policy. I want the agent to stop and wait until I’ve looked at exactly what it’s about to do and said yes. This post describes a new OpenClaw demo that does that using Cedar and a Yubikey.

Controls, Not Prompts

The easy way to get a human in the loop is to tell the agent to ask. You put “always check with me before sending email” in the system prompt and hope for the best. That instruction is a suggestion to a language model. It competes with everything else in the context window, including the content of a web page or document that might have been written specifically to talk the agent out of asking. A prompt is guidance; it isn’t a control.

The theme running through this series is that authorization belongs in the harness, not the prompt. In the policy-aware agent loop, every tool invocation passes through a policy enforcement point (PEP) that asks Cedar whether the action is allowed. The model doesn’t get a vote. It can reason about the denial and replan, but it can’t skip the check, because the check isn’t something the model does. It’s something the harness does to the model’s proposed actions.

Human approval works the same way in this demo. The PEP, not the agent, decides when a human must approve, and the PEP, not the agent, supplies the evidence that a human did. The agent can’t forge that evidence because it never touches it. That’s the difference between asking an agent to behave and building a system where misbehaving doesn’t work.

What the Demo Does

Earlier demos answered the question “may the agent do this?” This one answers a different question: “may the agent send this email now that a human has cryptographically attested to it?” The demo adds a simulated send_email tool to OpenClaw. Gathering information and drafting the message are ungated; the agent can read files and write a scratch draft just as before. Sending is different. The following diagram shows the agent loop from the earlier posts with the HItL modifications added.

When the agent calls send_email, the PEP asks Cedar for a decision and gets a deny, because no human has approved the message. Cedar doesn’t know anything about approval workflows; it just says no. The PEP intercepts that deny and interprets it. Because the tool is send_email, the PEP treats the deny as “not yet” rather than “no,” and instead of returning it to the agent, it parks the request and waits for a human.

The human opens an approver page, reviews the recipient, subject, and body, and taps a Yubikey. The PEP then retries the Cedar request with the human’s approval injected into the context. This time Cedar returns permit, and the email is “sent,” which in the demo means a JSON file lands in a mailbox directory.

If nobody taps the key before the timeout (three minutes by default), the PEP returns a hard deny to the agent and doesn’t wait again. You can see this in the diagram as the timeout path that runs from the /authorize box back to the agent’s evaluation step. The agent learns that the send didn’t happen and can replan or report back, but it can’t try again and hope the human is more agreeable the second time.

The Cedar policies that enforce this are short. One permits SendEmail when a verified WebAuthn approval is present and matches the request; the other forbids it otherwise:

@id(”hitl-1-allow-send-with-approval”)
permit(
  principal,
  action == OpenClaw::Action::”ToolExec::SendEmail”,
  resource
)
when {
  context has humanApproval &&
  context.humanApproval.verified == true &&
  context.humanApproval.method == “webauthn” &&
  context has requestHash &&
  context.humanApproval.requestHash == context.requestHash
};

The forbid policy is the same test negated. Since Cedar’s forbid always overrides permit, the explicit forbid means that no other permit policy, now or added later, can accidentally open up email sending without a human. The timeout lives in the PEP rather than the policy because Cedar has no notion of the current time; it evaluates the context it’s given, which is exactly what makes its decisions predictable.

Notice what the policies don’t say. Nothing in them tells anyone to go find a human; Cedar just returns deny, the same answer it gives for any other forbidden action. The PEP is what turns that deny into a request for approval. It intercepts the decision before the agent sees it and interprets a deny on send_email as “waiting for a human” rather than “no.” In other words, Cedar decides whether the action is allowed, and the PEP decides what a denial means. That division keeps the policy engine simple and deterministic, but it also means the rule about which denials a human can override lives in code, a point I’ll come back to below.

A Passkey for Each Approval

The approval isn’t a generic “the human said OK.” The demo uses ordinary WebAuthn, the protocol behind passkeys, and binds the challenge to a hash of the specific request. When I tap the Yubikey, I’m signing a statement about this recipient, this subject, and this body. The requestHash check in the policy makes sure the approval Cedar sees matches the action the agent is actually trying to take. If the agent changes a word in the body after I approve, the hashes don’t match and the send is denied.

Think about the difference between signing a check and signing a blank check. A blank check says “I trust whoever holds this”; a signed check for a specific amount to a specific payee says “I approve this.” Most approval flows for agents are closer to the blank check: the human clicks “allow” once and the agent carries that authority forward. Binding each approval to a single request keeps the human’s authority attached to the human’s decision. The approval can’t be replayed for a different message or stretched to cover the next ten sends.

The “human” part of human in the loop is only as strong as where the passkey lives. On a Yubikey or other roaming hardware key, the credential stays on the device and approval requires someone to physically present the key and touch it. In a software authenticator, like a browser’s passkey store or a password manager, the WebAuthn ceremony succeeds just the same, but anything that can unlock that store can approve. The demo asks the browser for a cross-platform authenticator so you’ll be prompted for the security key rather than Touch ID. For a while, at least, we don’t expect software agents to physically insert and tap Yubikeys. That’s the point.

Try It Yourself

The code is in the openclaw-cedar-policy-demo repository on GitHub, and the HItL README walks through running it. Clone the repo, but don’t start with the HItL demo. It builds on the earlier ones, so work through the basic Cedar demo first to get the PDP, the PEP, and your OpenClaw configuration in place. The README also includes commands to verify that the earlier demos still pass once the HItL changes are added.

The README covers starting the PDP (which also serves the approver page), registering your Yubikey, and running a set of policy tests that don’t need a key at all. The live walkthrough asks the agent to send a simulated email, and then you approve it on the approver page. If you let it time out instead, you’ll see the agent receive the denial and no mailbox file appear. I’d recommend trying both; watching the agent handle the timeout says as much about the design as watching the approval succeed.

Shortcuts and the Road to Production

Like the other demos in this series, this one is built to show an architecture, not to run in production. It takes several shortcuts:

• Simulated delivery—No email leaves the machine. An approved send writes a JSON file to demo/mailbox/sent/, named with a UTC timestamp.

• No notification—Nothing tells you a request is waiting. You have to open the approver page yourself and watch for it.

• One gated action, chosen in code—The policies name SendEmail directly, and the PEP is hard-coded to park any deny on send_email. Only that one tool requires a human, and the PEP, not policy, decides that a deny there should wait for approval. It will even park a send that some other policy forbids, asking for a tap that can’t change the outcome.

• One approver on localhost—The PDP serves the approver page, there’s a single registered credential, and it has to run on localhost so the WebAuthn origin matches.

• Trust in the authenticator—The demo asks for a roaming authenticator, but nothing verifies that the credential actually lives on hardware.

None of these change the architecture, and each points toward how you’d generalize it into a production system:

• Policy-selected actions—Policy rather than code would decide which actions need a human, perhaps based on resource attributes like sensitivity or on the scope of a delegation. The PEP still interprets the deny, but it would take its cue from policy. For example, it could park only when every policy behind the denycarries an annotation like @hitl("required"), or use partial evaluation to confirm that human approval is the only thing standing between the request and a permit.

• Approvers as principals—The approver would be a principal in the policy model, so Cedar could say who is allowed to approve what; approving a wire transfer and approving a calendar invite shouldn’t require the same person.

• An approval service—A dedicated service would replace the page served by the PDP and push requests to the approver’s phone or other device.

• Durable state and audit—The pending store would be durable and every approval would be logged, giving you an audit trail that ties each consequential action to a specific human decision.

• Authenticator attestation—Checking the authenticator’s attestation would let policy require hardware keys for the actions that matter most.

• Multiple approvers—Requiring more than one approval is a natural extension of the multi-signature patterns I discussed in It’s Not Just What Agents Can Do...It’s When They Can Do It!

One more thing matters that no amount of cryptography fixes: the human has to see what they’re approving. The Yubikey tap attests to the request hash, but the human decides based on what the approver page shows. If the display summarizes or hides part of the action, the attestation covers something the human never saw. A production approval UI needs to present the action faithfully, which is an old lesson from digital signatures that applies to agents just as well.

Humans Where They Matter

Putting a human in the loop for everything would defeat the purpose of having an agent. People who are asked to approve every action stop reading and start tapping, and a tap without attention is just a slower way of saying yes. The value of this design is that policy decides where the human belongs. Most actions flow through Cedar and never interrupt anyone. The few that carry real consequences stop and wait for a person who can see exactly what’s about to happen.

Agents act on our behalf, and the authority they carry is ours. When the stakes are high, the agent shouldn’t be able to decide on its own that we would have approved, and it shouldn’t be able to argue its way past a prompt that says to ask. Placing the control in the harness, bound to a specific action and a physical key, keeps that decision where it belongs. We can build agents that treat our approval as a formality, or we can build ones where our approval is a real control. The second is harder, but it’s the one that keeps people in charge of what’s done in their name.

Photo Credit: Human in the Loop from ChatGPT (public domain)

I have been working to make Manifold a good framework for building pico meshes, the kind I use for my network of LoRaWAN sensors. The new Manifold API doesn’t have a UI like the old Manifold did. I want to use Home Assistant (HA) for that and recently created a custom HA integration. With the groundwork laid, it was time to move my actual sensor network onto the new framework running on the updated pico engine. This post describes that move and the problems I ran into, and fixed, along the way.

Manifold as a Framework for Pico Meshes

Manifold began as an application for managing your things and creating communities to group them together. The primary application was Safe and Mine, a QR-code-based tagging system to identify your keys, bags, and mugs. Manifold was expandable with custom applications (written in KRL) that could be added to each thing.

When I rebuilt it as the Manifold API, I stopped treating it as a finished app and started treating it as a framework, a set of domain rulesets other people can extend to build their own meshes. A pico mesh is a small network of independent, addressable computational things, each with its own state, its own rules, and its own relationships. It still supports Safe and Mine, but I wanted it to be more than that—a personal space to manage both inactive (like your mug) and active (like a temperature sensor) things. The reason to build on Manifold is ownership; the mesh belongs to the person who runs it, not to me and not to a platform, and they decide what connects to it and what it exposes.

That distinction is the whole point. I’ve been working for years to build alternatives to what I call the CompuServe of Things. A sensor network you rent from a vendor is legible to the vendor first and to you second. A sensor network that runs as your own pico mesh answers to you, and the framework underneath it exists to keep that relationship intact as the network grows.

The Network I Was Moving

The network I wanted to move is not a demo. It is a working LoRaWAN deployment I have written about before, starting with easier IoT deployments on Helium and then the temperature sensors in a remote pumphouse. I have temperature probes in the crawl space of my cabin, on the north side deck, and in my beehive in addition to the pumphouse. Those sensors report over Helium, and until now they ran on the old sensor-network code, essentially recreating the features of the Manifold framework in addition to their specific duties interpreting and managing the payloads received over LoRaWAN.

Rebuilding the network on top of Manifold simplifies the code and gives the sensors additional capabilities. Each sensor becomes a thing in a community, with an owner pico above the Manifold pico that ties the whole mesh together. The structure is easier to see than to describe, so here is the mesh as it stands after the move.

Everything below the Manifold pico is a sensor or a community. The pumphouse, cabin crawl space, cabin north side deck, triple-temperature probe, and beehive are sensors. The Sensors pico is a Manifold community pico for the sensors. It handles things like notifications, sensor initiation, and reading aggregation. Moving to Manifold didn’t change what the sensors measure, but it makes them more capable and manageable. And having them in a standard mesh means I can write HA integrations that work for lots of different meshes.

Home Assistant as the Interface

Because the new Manifold API has no interface of its own, I spent some time making Home Assistant fill that role. In Using Home Assistant with Manifold I described the integration: Home Assistant runs the pico engine’s OAuth flow, comes away with a scoped token, and reads the mesh through it. That gives me dashboards, history, and alerts on software many people already run at home, without my having to write a UI of my own. The sensor network ships a companion Home Assistant component so its sensor things show up as real temperature and humidity entities, not just generic mesh objects. The code serves as an example of how to write HA companion components that work with the Manifold integration.

Where It Broke: OAuth Meets Webhooks

The initial port looked good. Every sensor came across, the communities lined up, and the readings flowed into the mesh the way they had before. The trouble started when I wired the mesh to Home Assistant, because that connection depends on the OAuth protection I added to the engine in Identity for the Pico Engine. Turning on OAuth secured the mesh against outside access, which is exactly what I wanted for Home Assistant; it also secured the mesh against webhook calls from Helium, which is not what I wanted at all.

Helium delivers sensor readings by calling a webhook defined on the pico for a specific sensor. The Helium console is software sitting outside my mesh that needs to POST data in, on its own schedule, with no human present to complete a login. The same protection that made Home Assistant’s access deliberate and revocable made the inbound webhook fail with an authorization error. That is the tension at the center of this move: authentication that assumes a person in the loop breaks the moment a machine needs to knock on the door.

Two Ways Through

There are two reasonable ways to let a machine through without tearing down the protection around everything else. Picos define webhooks by creating channels. Each channel has a policy saying what events and queries are allowed on that channel.

• Client-credentials channels. The engine already supports OAuth client credentials for a channel. I described this feature in Identity for the Pico Engine. A channel configured this way lets the caller authenticate as itself, against that one channel, rather than as a person against the whole mesh. You configure the bearer token in Helium as part of defining the webhook and Helium includes it on each POST.

• Owner-declared exempt channels. Alternately, the mesh owner can mark a channel as exempt from the OAuth protection. This is only safe when the channel’s policy is tight enough to keep the exemption from becoming an open door, and in this case it is, because the channel accepts one narrow shape of sensor data and nothing else.

Both of these approaches rely on the owner being careful about scoping the authority of the webhook so that it doesn’t represent a security threat. Neither one weakens the mesh as a whole, and neither one hands a machine the standing of a person. I updated the pico engine to support the owner-declared exemption, so the choice now belongs where it should, with the person who runs the mesh, decided channel by channel rather than for the network all at once.

The Window onto the Mesh

With data flowing again, Home Assistant does exactly what I hoped. The dashboard at the top of this post is my cabin: the pumphouse, the crawl space, the north side deck, each updating every few minutes from the sensor network now running on Manifold. I get history, thresholds, and a picture of the current temperatures at a glance, all from software I run.

Home Assistant also makes alerting easier. I already had notifications on the old setup, but each one was its own bit of wiring off to the side; Home Assistant keeps the readings, the history, and the rules that act on them together in one place. I can build an automation directly on a reading, so a low temperature in the pumphouse sends me a notification while there is still time to act, rather than after a freeze has cracked a pipe and left the cabin without water. Having that alongside everything else I watch, instead of bolted on separately, is exactly what I want an interface for the mesh to do.

None of this is a new capability so much as a boundary drawn in the right place. The reading Helium sends and the reading Home Assistant shows are the same as they were a year ago. What changed is the software and systems are less creaky and easier to manage and update. The mesh belongs to the person who runs it, and Home Assistant is just a window onto it.

A remodel left me with lights over two fireplace benches wired to separate switches, so turning them on meant a walk to both ends of the room. Rather than tear open the wall, I let Home Assistant and a pair of Inovelli switches make the two behave as one. The wiring doesn’t have to change if software controls the switches.

As part of our remodel, Lynne wanted lights over the built-in benches on either side of our fireplace. The fireplace itself made it hard to run both fixtures back to a single switch, so the easy path left us with one switch at each end of the hearth. That works, but it means anyone who wants the benches lit has to cross the room and flip two switches. It’s a small annoyance, the first-world that the physical world imposes from time to time. Fortunately, software can fix it.

Both switches are Inovelli Blue Series 2-1 dimmers, Zigbee devices that report their state and take commands over the network as readily as a person flips them by hand. That makes them programmable in a way an ordinary switch is not; the paddle still does the obvious thing, but the switch is also something software can watch and control. I’ve leaned on that elsewhere in the house. One of them runs the bathroom fan, turning it on by itself when the humidity spikes and off again once the room dries out, so nobody has to remember.

The fix for the benches uses the same idea. Each light keeps its own switch, and a pair of Home Assistant automations wires the two together in software: when one switch turns on, it turns on the other, and the same for off. Flip either paddle and both fixtures respond, which is exactly how a three-way switch behaves when it controls a single light. Here there are two lights and two circuits that never meet in the wall, made to act as one from the automation layer instead.

And nothing about this arrangement is fixed, either. The same two switches could join a scene that dims the whole room for a movie, answer a voice command, or turn themselves off when the house goes to bed, none of which requires a visit from an electrician. Because the coordination lives in software rather than in the wiring, teaching the switches a new behavior simply requires writing another automation, not running another wire. The pairing I set up today is just the first thing I have asked them to do.

The wires in the wall didn’t change; the behavior did. That’s the beauty of adding a little software to a physical control: the constraints of the wiring are no longer the constraints of the room. When the layout fights you, you don’t always have to open the wall. Sometimes you can just change what the switches do.

Photo Credit: Lights over the fireplace benches from Phil Windley (CC BY 4.0)

Over twenty-five years ago, I bought an Intel Play QX3 microscope for my kids to play with. It came with a CD-ROM holding the control software, which, as I recall, ran only on Windows. The microscope then spent the better part of two decades in the back of a cabinet in my office, gathering dust.

I pulled it out recently for my grandkids, hoping the Mac might simply recognize it as a camera. It didn’t. I couldn’t find any software that would run on a modern machine, and I was about ready to send the whole thing to the thrift store. Then I had an idea: what if I used Claude to write an app for it?

A morning later I had one, and my grandkids were watching the ridges of a seashell fill the screen. The interesting part of this story isn’t the microscope; it’s that building a custom app for a single obsolete device is now a morning’s work instead of a project. That change is going to reshape what we expect software to be.

A Microscope With No Software

The QX3 is a small USB microscope that Intel and Mattel sold around the turn of the century. It magnifies at 10x, 60x, and 200x (using physcial lenses, not software); it has a camera in the head, a light on top and another in the stage, and a focus wheel. For a toy, it is genuinely good, and it still works exactly as well as it did in 2000. The problem is not the hardware; it is everything the hardware expects to talk to.

The QX3 predates USB Video Class, the standard that lets a modern operating system treat any conforming camera as a webcam with no driver at all. To macOS, the QX3 is not a camera; it is an unknown vendor-specific USB device, and the system has no idea what to do with it. Over the years, hobbyists filled that gap with their own drivers and apps for Linux and the Mac. Those projects are mostly dead now.

They died for an ordinary reason. Each one depended on the operating-system internals of its moment, and macOS kept moving: it went 64-bit, it tightened what kernel extensions could do, and it reworked its USB and camera frameworks more than once. Keeping a driver alive for a discontinued children’s toy is a lot of unpaid work for an audience of a few, so the maintainers moved on and the code stopped building. The hardware still worked; the software around it rotted away.

Building It With Claude

I opened Claude in Cursor and worked in stages. I didn’t begin with a plan for an app; I began by trying to talk to the device at all. Each stage did one small thing and proved it worked before I asked for the next.

1. Identify the device. I gave Claude the handful of facts the macOS “About This Mac” USB panel showed for the microscope: a vendor ID, a product ID, and not much else.

2. Blink the lights. I had Claude write a small command-line program that turned the microscope’s LEDs on and off. That was the entire test: could code I control make something physical happen across the USB cable? It could.

3. See through it. Next came a command-line tool that pulled the image the microscope was seeing and saved a snapshot to a file.

4. Give it a face. Then a real Mac app with a window: switches for the two lights, a brightness slider, a live preview, and a button to take a picture.

5. Record. After that, movie capture and time-lapse, so my grandkids could watch an ant walk or a drop of water evaporate.

6. Clean it up. Finally the work that separates a demo from a tool: an app icon, a proper Quit item in the menu, and the usual round of small bug fixes.

The result is a few hundred lines of Swift that talk to the microscope directly over USB. I called it Windley Microscope, which is the kind of name you give something built for exactly one household. It does what the original Windows software did, and only what my grandkids and I actually want it to do.

Why This Works

The QX3 is easy to bring back precisely because it is old. A modern webcam sits behind several layers: USB Video Class, the camera framework, the operating system’s device and privacy management. Those layers are what make a new camera “just work,” and they are also what you cannot reach around when it doesn’t. The QX3 has none of them.

It sits right on the USB wire, speaking a simple protocol, with nothing between my code and the device. The same plainness that made it invisible to macOS made it straightforward to control myself; there was no abstraction to defeat, only a device to address. Simple architecture wins. When the platform declines to capture a device, you are not locked out of it; you are left free to talk to it on your own terms.

An App for an Audience of One

Here is the part that reaches past one microscope. A few years ago I would not have spent two weeks building a custom app to run a discontinued toy for my grandkids; the effort was far larger than the result was worth. I was happy to spend a morning. That shift changes the cost dynamics of software in a profound way.

An app no longer has to be a product. It does not need a market, a store listing, or a user base large enough to justify the build. It can be personal¹: written for exactly what one person needs, and for no one else. The world is full of a backlog of small software that never get written because the audience is one (or small) and the price was two weeks (or two years). That backlog has quietly become approachable. Imagine all the things that will be built because of this profound change in cost.

An important point: This is easy on a laptop because computers still let their owners run whatever code they write and talk to whatever hardware they plug in. It is not easy on iOS, where the platform, not the owner, decides what is allowed to run. The model that let me revive the QX3 in a morning barely exists on the devices most people actually use; that is a decision about how those platforms are built, not a fact of nature. As personal software becomes ordinary, it will press on that decision.

The microscope works again, and that is a small, good thing. The larger thing I got back is the ability to make the computer do the specific thing I want, without waiting for a company to decide enough people want it too. That capability used to belong to firms with a market to serve. It is starting to belong to the rest of us.

Notes

1. Personal is not personalized. In 2026, a personalized system is one a company tunes to you from the data it collects about you; the tuning serves the company, and the surveillance that feeds it is the point. A personal app is the reverse: you build or commission it, it runs on your own machine, and it answers only to you. I mean personal in its older, plainer sense: software that belongs to you, not software aimed at you.

Photo Credit: The QX3 microscope beside my laptop running Windley Microscope from Phil Windley (CC BY 4.0)

My new book, Authorization in Action, is now available from Manning. It’s a book about the question that comes after we know who you are: what are you allowed to do? Knowing who someone is doesn’t tell you what they should be able to touch, change, or spend. For most of the last two decades I’ve worked on the first question, proving who someone is; this book is about why the second one is now the one that matters, and how to build systems that answer it well.

The short version of the argument is one I didn’t expect to be making a few years ago. Authentication, the act of proving who someone is, has become about as good as we can reasonably ask; passkeys and FIDO have quietly closed most of the gap that kept me up at night in 2005. Authorization, the act of deciding what someone can actually do, is still mostly improvised, buried in application code, and reinvented badly on every team. That imbalance is the reason the book exists.

How I Got Here

When I was CIO for the State of Utah in 2001, I noticed that nearly every problem that reached my desk had an identity component hiding inside it. Consolidating directories so every employee could have a utah.gov address, moving the state’s website to a new domain, sorting out who could touch which system: none of these looked like identity problems on the surface, yet all of them turned on knowing who someone was and what they were permitted to do. I didn’t have language for it then, but that observation set the direction for everything I’ve worked on since.

A few years later Doc Searls, Kaliya Young, and I started the Internet Identity Workshop(IIW), and it has now met 42 times. IIW has become the place where the identity community works on its hardest problems together. Along the way I wrote three books; Digital Identity helped enterprises build identity strategies, The Live Web moved the focus from organizations to individuals with their own data and APIs, and Learning Digital Identity finally named the thing I’d been circling for years: identity is fundamentally about relationships, not identifiers. Each book was really an attempt to answer a question the previous one had raised.

While I was finishing Learning Digital Identity, the next question came into focus, and conversations at IIW confirmed it. Knowing who someone is tells you almost nothing about what they should be able to do; the interesting, unsolved work all lives on the far side of authentication. That’s the work my new book takes on.

The Second Question

The reason the second question is harder is that it’s not one question but several, and they’re the ones that actually govern what happens inside a system. What can this person do; under what conditions; on whose behalf; and in which context? Miss any one of them and the rest stop meaning much; the same request can be right for a manager at noon from the office and wrong for a contractor at midnight from an unknown device. A login gets you through the door, but it says nothing about which rooms you can enter, what you can carry out, or whether the person who sent you had the standing to send you at all.

In late 2022 I joined AWS Identity, and one of the teams we worked closely with was building Amazon Verified Permissions and the Cedar policy language. Working at that scale showed me something the theory hadn’t: fine-grained authorization doesn’t only make a system safer, it makes it more usable. When the rules about who can do what are explicit and external to the code, you can hand people exactly the access they need without either drowning them in prompts or handing over the keys to everything. Getting authorization right is how a system stays both safe and pleasant to use, and those goals stop fighting each other.

Then Came the Agents

What finally convinced me the world needed this book was AI. As agents begin acting on people’s behalf, “what is this thing allowed to do, and on whose authority?” stops being a background concern and becomes the whole game. An agent that can read your calendar, spend your money, or send mail as you is only as trustworthy as the boundaries around it, and those boundaries are authorization. I’ve argued before that authorization is the hard problem in agentic AI, and nothing since has changed my mind.

This is where the technical question turns into a human one. If we can’t say precisely what an agent may do on our behalf, we’re left choosing between agents that can’t do anything useful and agents we have to trust blindly; neither of those is a world I want to live in. Authorization is the infrastructure that lets us delegate real authority to software while keeping it bounded, accountable, and revocable. That’s not a convenience feature. It’s what makes it possible to act through machines without surrendering to them.

What’s in the Book

Authorization in Action follows a fictional company, ACME, as it works its way from the tangled access-control code most teams start with toward policy-based authorization it can actually reason about. The book uses that story to get concrete about the models and mechanics—relationships, roles, attributes, policy languages, and the architecture that separates deciding from enforcing—rather than leaving them as abstractions. This is the book I needed on my own shelf while I was solving these problems as an enterprise architect at BYU, so it’s aimed at the developers and architects who have to make these decisions everyday

Identity tells us who is involved. Authorization determines what happens next. I’ve come to believe that second question is quietly becoming the heart of security, governance, and trust online, and I hope the book makes the case as clearly to you as the last few years have made it to me. You can find Authorization in Action at Manning and coming soon to Amazon.

When I wrote about pico-to-pico identity arriving in version 1.6, I explained why I reached for DIDs rather than KERI. The other obvious question is “Why not SPIFFE, the workload-identity stack that Kubernetes shops already run?” It’s a fair question, because a pico is, from one angle, just a workload; it’s a running process that needs to prove which process it is before another one will talk to it. So why give it a DID instead of a SPIFFE ID?

The answer comes down to a single property: whether the identity travels with the thing it names. SPIFFE and picos give opposite answers to that, and the opposition isn’t an accident. It falls out of what each one is built to identify.

What SPIFFE Gets Right

SPIFFE is a genuinely good design for the problem it takes on. A workload asks the local agent for its identity, and instead of holding a secret it proves who it is by what it is and where it runs; the platform attests to the process, and the workload gets back a short-lived credential called an SVID. There’s no long-lived key to leak, because the credential expires in minutes and renews on its own. For a datacenter full of ephemeral, interchangeable containers, that’s exactly right; you don’t want a Kubernetes pod hoarding a private key that outlives it.

The trust anchor for all of this is a server that runs the trust domain. That server decides which workloads exist, attests to them, and signs their SVIDs, and every workload in the domain trusts it by construction. Inside one administrative boundary, that centralization is a feature, not a flaw; someone runs the cluster, and that someone is exactly who should be minting identities in it. SPIFFE fits the shape of the place it lives.

Identity that’s Derived versus Identity that Lasts

That fit is also the reason SPIFFE isn’t what a pico needs. A SPIFFE identity is derived: it comes from what the workload is and where it runs, and the domain’s server mints it fresh in whatever environment the workload happens to land in. Move the workload to a different cluster and it gets a different identity from a different authority, because the identity was never the workload’s to carry; it was a fact about the environment. That is a badge the building prints for you at the door. It works beautifully inside the building and means nothing the moment you step outside.

A pico’s identity is long-lived by design. Every pico holds its own keys and carries a did:webvh that stays the same identifier no matter which engine it runs on or how long it runs; the identity is a property of the pico, not of the host underneath it. When a pico moves between engines, its identity moves with it, because the pico is the one holding the keys that prove it. That is a passport rather than a printed badge; you carry it across borders, and it still says who you are on the other side. For a system whose whole point is picos and meshes that are portable between engines, an identity that gets re-minted per environment just isn’t the right choice.

Durable identity is a property that makes picos useful for tasks that ephemeral workloads can’t do easily.

• Persistent relationships. A subscription links two identifiers; if they reset on every restart, the relationship can’t outlive the move. Durable identity is what lets a mesh of relationships accumulate and survive.

• Reputation and history. Because a pico keeps the same identifier over time, the parties it deals with can remember their history with it and decide how far to trust it. An identifier that resets each session gives them nothing to base that judgment on.

• Credentials. A verifiable credential is a claim about a subject, and the subject has to persist for the claim to keep meaning anything. Without a durable identity there is nothing to hold or present a credential.

• Delegation. An actor operating on your behalf needs a stable identity so the authority you grant persists and stays revocable. Ephemeral identity means re-authorizing constantly and having nothing durable to take back.

• Continuity across infrastructure. Because the keys belong to the pico, the actor is decoupled from the host; you can move engines, change providers, or recover from a crash without losing who the pico is.

• Longevity beyond any vendor. The identity outlives the company that built the device, so a pico doesn’t die when someone’s cloud is switched off. This is the Internet of My Things rather than the CompuServe of Things.

• A lifecycle that follows the thing. For something with a long life that changes hands, identity and history span custodians instead of resetting with each one.

A digital twin is a good example of where durable identity matters. A pico that stands in for an IoT device grows more valuable the longer it lives, because it accumulates the device’s history, relationships, and state over years rather than minutes. When I built Fuse, each car had its own pico, and selling the car meant handing that pico to the new owner with the maintenance history and important relationships intact; the identity was bound to the vehicle, not to me. That is the case ownership language gets wrong. The pico’s identity outlives any particular owner, and it has to, because the car it represents might too.

Trust Domains and Strangers

The same split shows up when two identities from different places need to trust each other. SPIFFE can federate across trust domains, but it does it the administrative way: the operators of two domains exchange trust bundles ahead of time, and only then can workloads on one side verify workloads on the other. That’s reasonable when both domains belong to the same company, or to two companies that signed a contract; someone with authority on each side sets the relationship up in advance. It assumes the parties already have a reason, and a person, to arrange the introduction.

Picos owned by two different people, on two different engines, don’t have that person in the middle, and I don’t want to require one. A pico resolves another pico’s DID and the two form a relationship directly, with no administrator on either side pre-arranging a federation. This is the same first-person idea I keep pushing for human identity, now applied to software actors: identity you present yourself, not identity an authority vouches for on your behalf. Trust between strangers shouldn’t require a treaty negotiated by their landlords.

An Actor, Not a Process

None of this makes SPIFFE wrong; it’s just built for a different kind of thing. SPIFFE names a process: a unit of execution that runs, does its work, and can be killed and restarted at will, where you care that some process is handling the request rather than which one. A pico is an actor: something that persists, holds state and relationships, and acts for someone or something over time. A process has an identity so the system can manage it; an actor has an identity that it uses over time.

Systems engineers have a mantra for this divide: treat your servers as cattle, not pets. Cattle are numbered and interchangeable, and when one gets sick you replace it instead of nursing it back to health; that is exactly the right way to run a fleet of workloads, and it’s the world SPIFFE is built for. A pico is a pet. It has a name and a history, and relationships that make it worth keeping this one rather than swapping in another that would do the same job.

That distinction is the thread running through everything above. Persistent relationships, reputation, credentials, delegation, history, continuity, and longevity are not affordances a process needs; they are what it takes to be an actor rather than a process, and every one of them presupposes an identity that lasts. So a durable identity isn’t a feature bolted onto a workload. It’s foundational.

The choice between SPIFFE and DIDs, then, isn’t really a choice between two identity technologies; it’s a question about what you’re naming. If you are naming a replaceable process inside one administrator’s domain then SPIFFE is the right tool, and I’d use it. But a pico is an actor that persists over time, not a process that happens to carry an identity, and the identity model has to reflect that. Give the thing that’s meant to persist and travel an identity that persists and travels with it.

Photo Credit: A printed visitor badge and a passport from ChatGPT (public domain)

Last month I released version 1.5 of the Pico Engine and argued that identity inside the engine is really three problems, not one. A human needs to prove who they are to a pico mesh; an outside app or webhook needs a scoped way into the mesh; and one pico needs to know which pico is calling it and whether to trust it. I shipped the human and third-party layers then and left the harder one for later. Today I’m releasing version 1.6, and that third layer, pico-to-pico identity, is here.

The short version is that every pico now has its own cryptographic identity, and that identity can travel. This is the piece I’ve wanted for a long time, because it’s the foundation for a goal I keep circling back to: picos and whole meshes that are portable between engines rather than pinned to the machine where they happened to be born. Let me describe the shape of it, because the design turns on a distinction that took me a while to get right.

The Layer I Was Waiting to Build

I shipped the first and third layers in 1.5 and held this one back on purpose. Passkeys and OAuth sit on machinery the engine already had: channels, ECIs, and channel policy. Pico-to-pico identity required something a bit more complex. It meant moving DID keys into the engine as a core primitive, pulling a lot of KRL into wrangler, and running pico-to-pico traffic over DIDComm instead of plain HTTP. That’s a large change, and it touches much of the engine, so I wanted to handle it separately.

This layer is what makes a pico an actor with a real online presence. A channel identifier tells you how to reach a pico on one engine right now; it says nothing durable about the pico’s identity. For introductions between strangers, for encrypted traffic, and eventually for verifiable credentials, a pico needs a stable answer to “which pico is this?” that is portable across engines. That answer is a DID, and in 1.6 every pico has one from the moment it’s created.

Two DIDs, Two Jobs

The design I landed on gives each pico two types of DIDs, each with different jobs. The first is a did:webvh, the pico’s portable identity. Every pico gets one when it’s created, and the engine serves its DID document at a stable URL so anyone can resolve it. Think of it as the pico’s passport: it’s how a pico introduces itself, and it’s what you hand a stranger who needs to know who you are before they’ll talk to you.

The second is a did:peer, and there’s one of them for every relationship, called a subscription, a pico forms. It isn’t provisioned up front; the two engines mint a fresh pair during the introduction handshake. There is a separate pair of peer DIDs for each relationship. Think of it as an email you give to exactly one person. The passport says who you are to everyone; the email is the private line for a single connection, and it means nothing to anyone else.

The developer UI makes the split concrete. The Identity panel at the top of a pico’s Subscriptions tab shows its one did:webvh, the passport it hands out, next to the switch that decides whether it accepts unsolicited introductions to that DID. Each established subscription below carries a different pair: the remote party’s peer DID and this pico’s own peer DID, minted for that one relationship. The subscription’s Rx channel is where policy still lives; the DIDs name who the two parties are, and the ECI decides what this one is allowed to do here.

That split matters more than you might think. A single, universal identifier is a mistake I’ve watched newcomers to identity make for years. Correlatability is a factor, but the bigger payoff is practical: because every relationship has its own identifier, each one can be managed on its own. You can rotate the keys on a single connection, or tear it down and rebuild it, without disturbing any of the others; if a peer DID is ever compromised, the damage stops there and you recover that one relationship in isolation. It’s the email analogy again, where changing the address you gave one contact doesn’t impact the rest.

How Picos Actually Talk

Two picos that aren’t parent and child talk to each other through a subscription, which is just a pairwise relationship with a record on each side. In 1.6 you form one by handing the initiator the recipient’s did:webvh as the target; the two picos run the introduction, agree, and store each other’s peer DIDs. After that, queries and events flow over the peer relationship. On the same mesh, the engine keeps that traffic local; across meshes or across engines, it runs encrypted over DIDComm to the peer’s address.

DIDs didn’t need a new authorization mechanism; they slot into the channel model the engine already had. A subscription’s peer DID is its channel, and channel policy governs it exactly as it governs any other channel, so authorization is enforced right where it always was. The DID names who is on the other end of the relationship, and the policy on that channel decides what they are allowed to do. Legacy ECIs haven’t gone anywhere either; parent and child picos still talk over family channels named by ECIs, where a full DID would be overkill.

The consequence I care about is what this does for trust between strangers. A pico can choose to accept unsolicited introductions to its public identity, which lets a community pico or a registry take subscriptions from picos it has never met. Two meshes owned by two different people, on two different engines, can form a relationship because one resolved the other’s DID and both agreed; no one had to stand up a federation agreement or register with a common broker first. The relationship is the unit of trust, and these changes make it cryptographic and portable.

Why These Methods, Not KERI

Anyone who has spent time at IIW will ask why I reached for did:webvh and did:peerrather than KERI, which answers the same “who is this actor” question with self-certifying identifiers and a key event log that needs no web host at all. KERI has a great design, and on the narrow point of surviving a move it’s arguably stronger than did:webvh; a KERI identifier carries no URL that has to stay reachable, which is exactly the loose end I admitted above. So this wasn’t a judgment that one approach is right and the other wrong. It came down to what picos already need to do the moment two of them are connected.

That need is messaging, and picos exchange events and queries over DIDComm. Peer dids were built for precisely that job: a pairwise, private relationship identity that DIDComm tooling already knows how to carry encrypted traffic over. Pairing it with did:webvh for the public introduction let me use a messaging philosophy the pico world has used for years since it parallels the DIDComm model. KERI’s strengths live mostly in the identifier and its key history; picos needed the identifier and the encrypted conversation that follows it, and the DIDComm path gave me both with the least new machinery. If the day comes when the portability tradeoff bites hard enough, I’d happily revisit that choice.

A Step Toward Portable Meshes

I won’t pretend a pico can pick up and move to a new engine today with no loose ends; the engine base URL is still baked into a pico’s did:webvh, and making that survive a move is work still ahead. But the hard part, giving each pico a real cryptographic identity and a way to carry its relationships, is now in the engine rather than wrapped around it. That’s the foundation portability was waiting on, and everything above it, from moving a mesh between engines to carrying credentials between them, builds on this.

Full portability is the largest gap, but it isn’t the only one. The identifiers are in place; the verifiable credentials that ride on them are not, so a pico can prove who it is but can’t yet hand another pico a signed claim about what it is or may do. Key management is thin across the board: the private keys behind a pico’s DIDs sit in the engine’s own store today, when they belong in the operating system’s key vault or hardware-backed storage, and rotation and recovery need more work now that a pico’s identity is the thing others rely on. Losing the keys shouldn’t mean losing the pico. Authorization also still keys off the channel a caller holds rather than the identity behind it, so the natural next step is to let a receiving pico decide based on who is actually calling using a proper authorization engine. Each of these builds on the identity that landed in 1.6 rather than replacing it.

I’ve spent a long time arguing that people deserve software that acts for them and that they own outright, not a rented seat on someone else’s platform. A mesh you can pick up and move provides infrastructure to realize that idea. If your picos can only live on one engine, you don’t really own them unless everyone is running their own engines (not likely). Version 1.6 doesn’t finish that story, but it lays down the identity it depends on. The next thing I want to do is exercise it in Manifold and find the rough edges by using it. If you want the details, the DID and Subscriptions pages walk through each piece.

Photo Credit: Two kinds of identity for a pico from ChatGPT (public domain)

Eve Maler recently unpacked a statistic that is easy to misread. In her post she reports on an IANS Research finding that identity and access management was the only security category with negative economies of scale; IAM takes 8% of the security budget at organizations under $400M in revenue but 14% at organizations over $10B. The obvious reading is that identity gets more expensive, per dollar, the bigger you get. Eve’s better reading is that “gnarliness,” her word for the tangle that makes identity hard, is multi-factorial, and that company size is a poor proxy for it.

She lists the real drivers: how many jurisdictions you operate in, how large your partner ecosystem is, how many apps you are wiring to an identity provider, how loosely coupled your lines of business are, and whether anyone owns identity strategically. What predicts gnarliness, she argues, is not any single factor but the unique combination your organization lives with. Reading her post, I recognized a shape I had drawn for chapter 19 of my forthcoming book, Authorization in Action. I give the tangle she describes has a name and a diagram.

Gnarliness Has a Shape

In the book, I distinguish two things that grow at different rates as a system expands. The first is the decision surface: the total set of situations in which access has to be evaluated. The second is the decision infrastructure: the shared policy, consistent enforcement, contextual signals, governance, and delegation models that let those decisions be made well. The surface expands with more actors, more actions, more contexts, more delegation, and more automation. The infrastructure only expands when someone deliberately builds it.

The gap between the decision surface and the decision infrastructure is authorization pressure.

When the surface outruns the infrastructure, the gap between them shows up as authorization pressure: the growing difficulty of making decisions consistently, explaining why they came out the way they did, and keeping control as the system scales. Pressure is not a failure of effort; ACME, the company I follow through the book, was improving access control the whole time. Pressure is what you feel when access decisions are being made everywhere and governed nowhere. Eve’s drivers of gnarliness map almost one to one onto the things that expand the decision surface; more jurisdictions maps to more context, a bigger partner ecosystem is more delegation, and more apps across more brands is more actors taking more actions.

Why Size Was Never the Predictor

Once you see identity’s difficulty as pressure rather than size, Eve’s objection to size as a predictor is easy to explain. Revenue and headcount tell you almost nothing about the decision surface. A small, acquisitive fintech operating in a dozen regulatory regimes, wiring together the identity systems of the companies it just bought, can carry far more surface than a giant consumer brand running one simple app for five hundred million users. The first organization is under enormous authorization pressure; the second is barely under any. Size isn’t what matters in either case.

That is also why IAM shows up as the category with negative economies of scale while other security categories get cheaper per dollar. The IANS number is not measuring the cost of being big. It is measuring the pressure that accumulates when the decision surface expands faster than the infrastructure meant to govern it, and large organizations have simply had more time and more room to let that gap grow. In other words, the diseconomies of scale are a symptom of authorization pressure, and the pressure itself is what you get when the decision infrastructure falls behind the decision surface. The underlying cause is an infrastructure that never grew to match the surface, not size.

Relieving the Pressure

You cannot relieve the pressure by shrinking the decision surface, because the business is the thing expanding it. Every new partner, every new market, every agent you deploy is simply the company doing what it exists to do. The only durable move is to strengthen the infrastructure so decisions stay consistent, explainable, and bounded even as the surface grows. That means externalizing policy out of application code, evaluating decisions at runtime against relationships and attributes and context, governing the signals those decisions depend on, and making delegation explicit rather than implicit.

This is where Eve’s diagnosis and mine reinforce each other most usefully. She notes that the organizations doing well with identity treat it strategically, often under someone she calls an Identity Product Owner, and that unified identity has started pushing downmarket wherever identity turns out to be a revenue multiplier rather than a cost. In the language of my book, those organizations have built decision infrastructure ahead of their decision surface, so the pressure never gets too high. Identity stops being the category that gets gnarlier with size and becomes a capability that lets a company expand the surface on purpose. A gap closed early is the difference between complexity that compounds and complexity you can manage.

The Surface Won’t Stop Expanding

Here’s the bad news: the decision surface is about to grow faster than it ever has. More interactions are crossing organizational boundaries; more actions are taken by services and agents instead of people; more decisions depend on real-time context that no static role can capture. I have argued in my series on agentic AI and authorization that agents expand the surface precisely because they act over time, under changing conditions, and often on someone else’s behalf. The pressure Eve measured in enterprise IAM budgets is the same pressure that will decide whether agentic systems are governable at all.

That is the human stake underneath the budget line. Authorization is how we govern the ways authority gets exercised, by our people, by our partners, and increasingly by the software acting for them. When the pressure is high, people confront a digital world of inconsistent permissions and unexplainable denials, a world where no one can say why the door opened or stayed shut. When the infrastructure keeps pace, authority is legible and bounded, and people can act with confidence inside clear limits. Eve is right: gnarliness is multi-factorial and size is the wrong thing to measure. What we should measure instead is the pressure between the decisions we now have to make and the infrastructure we have built to make them well. That pressure is something we can manage.

Photo Credits: Under Pressure from ChatGPT (public domain) and Decision Surface and Decision Infrastructure, from Chapter 19 of Authorization in Action (Manning)

Emil Sotirov wrote after my last few posts with a good request:

Would you, please, do a map/diagram of the whole environment you’re describing, giving an idea about the functional capabilities?

That’s a fair thing to ask. I have described this environment across three posts now, a piece at a time, and never in a single picture: the platform rebuild in Manifold API and Sensor Network, the engine’s new identity layer in Identity for the Pico Engine, and the interface in Using Home Assistant with Manifold.

The figure above puts the whole thing in one place and labels what each layer does:

• Pico engine—hosts the picos and supplies, among other things, identity: passkeys for the owner and OAuth for outside software. One engine can run several independent meshes at once, as shown in the figure.

• Pico—the actor. Each pico is an independent, addressable entity with its own state, its own rules, and its own channels, and it interacts with other picos only by exchanging events. Everything above this layer in the diagram is running on picos.

• Wrangler—the pico operating system. It gives each pico its channels, children, and subscriptions, and it is the machinery every higher layer calls to create picos and wire them together.

• Manifold—the framework layer, responsible for mesh lifecycle and notifications. It controls a mesh comprising a root pico, a Manifold pico that creates and tracks things and communities, all the things and communities, and tag and skills registries. It fans alerts out to various channels. Everything above delegates that work to Manifold rather than building it again.

• Sensor network—a domain layer that specializes the generic platform. It treats communities as sensor groups and things as LoRaWAN devices, decodes their payloads, and raises threshold alerts back through Manifold’s notifications.

• Home Assistant—the interface, where a person actually sees and drives everything: devices, dashboards, and automations. The Manifold hub integration authenticates over OAuth and renders things and communities as Home Assistant devices, and a companion integration adds sensor entities for the domain layer beneath it.

The figure shows a classic delegation stack: each layer leans on the one beneath it and adds capabilities the layer below does not have. The one thing the figure hints at but does not yet deliver is the pair of light links between meshes, marked x and y. Those cross-mesh relationships are waiting on the pico-to-pico identity layer that is still ahead, which I will cover in its own post. That aside, this is the whole environment in a single picture.

The original Manifold (which was a replacement for the old SquareTag) gave a person a place to gather their connected things under their own control, but it needed its own web application to provide the UI and manage accounts. Rebuilding Manifold on version 1.5 of the pico engine turned it into a framework for building meshes of picos. But that mesh is only useful if outside software can reach it, if the owner has an interface that is easy to use, and if specialized domains can extend it without forking the platform. Those are three separate problems, and a Home Assistant integration was how I proved I had an answer to each one.

This work sits directly on top of the last two things I wrote about. In Manifold API and Sensor Network: Two New Repos I rebuilt Manifold as a framework and rewrote the sensor network as an example that runs on it, and I flagged a Home Assistant integration as the obvious next step. Then in Identity for the Pico Engine I added OAuth to the engine and said the Home Assistant layer would be the first real exercise of that identity work. This post is where those two threads meet.

I’ll take them in the order they build on one another: an OAuth workflow that lets an outside application into the mesh, Home Assistant replacing the custom Manifold interface, and a pattern that lets a domain like a sensor network add its own behavior on top. Each of the three are working now. One thing still doesn’t, and I’ll come to that.

Letting an Application In

Version 1.5 of the pico engine finally moved identity into the engine itself, including OAuth for external applications and webhooks; I described that design earlier in Identity for the Pico Engine. Home Assistant was the first real client I pointed at it. When someone adds the Manifold integration, Home Assistant runs the OAuth flow and comes away with a token it can use to access the mesh. This allows each mesh owner to grants access deliberately using a token that is scoped to what the application should see, and that the owner can revoke later.

An Interface I Didn’t Have to Build

The old Manifold answered the interface question by building a web application: accounts, dashboards, notification screens, all of it written and maintained as custom code. Home Assistant already solves that problem for a large community of users, and its open source. So rather than ask owners to learn another dashboard, Manifold now appears inside one that many of them already run.

Things and communities show up as Home Assistant devices, and Manifold’s notifications reach the owner through a dedicated channel that the homeassistant ruleset creates on install and forwards enabled alerts to. Home Assistant is already where many people run their home automation and sensors, and a Manifold mesh drops into that same surface, adding picos to HA, each with its own logic and its own relationships. Reusing a mature system beats maintaining a thinner copy of it. The time I would have spent on yet another dashboard goes to other projects.

Room for Specialized Communities

A platform is only generative if other people can build on it without asking permission, and the third component demonstrated that idea. The sensor network I rebuilt as a Manifold example needed sensor-specific behavior in Home Assistant, not just the generic view of things and communities. So it ships a companion integration, pico_mesh_sensor_network, that declares the Manifold hub as a dependency and attaches sensor entities to the thing devices Manifold already created. The pattern is small: domain rulesets in the repo root, a companion component beside them that depends on the hub, and a stable surface to import from. Any Manifold community can follow it, which is exactly what I wanted to demonstrate.

What Still Doesn’t Work

One piece of the old Manifold has not made the trip yet. SafeAndMine, the application that started this line of work, depended on physical tags: an NFC sticker or a QR code on an object that resolves through a tag registry to the pico that represents that thing. The registry is in place and things can register against it, but scanning a tag and following it to the right pico does not yet work end to end. Until that path is solid, Manifold can model your things but it cannot let a stranger scan the tag on your lost backpack and reach you. That is the next thing to finish.

Manifold has evolved from a product with its own screens to maintain into a foundation for building meshes of picos that can sit at the network edge. What makes that real is the architecture holding together: identity that lets outside software in on the owner’s terms, an interface in a system people already trust, and an extension pattern that invites other domains to build. The tag path still has to land before I would call the old Manifold fully replaced. But the important parts are working now.

Photo Credit: A Home for Your Pico Mesh from ChatGPT (public domain)

Today I’m releasing version 1.5 of the Pico Engine. The primary features in this release are support for accounts, authentication to the UI via passkeys, OAuth client credentials for channels used as webhooks, and optional OAuth Authorization Code Grant credentials for any given pico mesh. If you know me, you might be thinking “wait you’ve been working on picos and identity for 25 years and you’re just getting around to bringing them together?!?” There’s a story there.

The original pico engine (what we call the “classic” pico engine) was begun in 2008. In that era of Infrastructure and Platform as a Service models, we’d have been silly to build a product that didn’t support identity and accounts. And we did. The classic pico engine, written in over 400,000 lines of Perl as an Apache module, has a full-blown identity system with passwords, accounts, and OAuth support. When we rewrote it (after the demise of Fuse) we were looking for something less of a platform and more personal. The new engine was implemented in Node and mainly used locally or in small experiments. Even as it grew and we started using it for more significant efforts like Manifold, we just wrapped it in an identity layer written separately.

But I’ve got some projects in mind that need proper identity to work and so the time has come to bite the bullet and add identity to the pico engine itself. Let me tell you about the architecture and what I’m releasing today.

Three Kinds of Identity

The first thing to get straight is that identity here isn’t one problem. It’s three. They are easy to lump together, but they ask different questions and want different answers. When I open the engine’s UI, the engine needs to know it’s talking to me. When one pico calls another, the pico on the receiving end needs to know which pico is calling and whether it’s allowed to do what it’s asking. And when something outside the engine, like Home Assistant or an inbound webhook, hits the public API, the engine needs to know who that caller is and what it can do. Keeping these three apart is what keeps the whole thing from turning into a tangle.

Each one has a natural answer:

• Human to pico mesh. You sign in to your root pico with a passkey. Each root pico is its own WebAuthn relying party, so there’s no shared password and no central table of users. Once you’re signed in, that root pico acts as the controller for the entire mesh.

• Pico to pico. This is the layer that gives a pico its own portable, cryptographic identity using DIDs and DIDComm to provide mutual authentication. That identity can survive a move from engine to engine, and it lets two picos from different meshes trust each other without anyone setting up a federation agreement first.

• Third-party access. A webhook or an app can’t use my passkey session, and I don’t want it holding a bare URL that works forever. So it gets an OAuth token instead, one it has to ask for and one I can take back.

I’m building these as three layers, and I shipped the first and third in 1.5. That order probably looks backwards, so let me explain it. The pico-to-pico layer is the most interesting of the three, but it’s also the most work. It means moving DID keys into the engine as a core primitive, pulling a lot of KRL into wrangler, and eventually running pico-to-pico traffic over DIDComm instead of plain HTTP. That’s a big change, and it touches a lot of the engine. The other two layers don’t need any of that. Passkeys and OAuth sit on top of machinery the engine already has: channels, ECIs, and channel policy. So I could add human sign-in and third-party access now, and leave the deeper identity work for when I can give it the attention it deserves.

No Usernames, No Passwords

One decision inside the human-to-mesh layer is worth pointing out: there are no usernames and no passwords anywhere in the engine. You register with a passkey and you sign in with a passkey, and that’s the whole story. There’s no email-and-password form to fall back on, no step where you make up a username, and no password database sitting on the engine waiting to be leaked. When you register, the engine creates your account and your root pico and ties them to a passkey your device holds. That is the account.

Part of the reason is that passwords carry problems I didn’t want to inherit. They get reused, phished, and stolen in bulk, and every system that stores them becomes a target. Passkeys sidestep all of that: the secret never leaves your device, there’s nothing shared for an attacker to steal, and signing in is a touch or a PIN rather than something you have to remember. But the bigger reason is that I think passwordless authentication is where things are headed, and I wanted to build something with no passwords at all and explore how that works. It’s easy to bolt passkeys on next to a password form as one more option; it’s more interesting to commit to them as the only way in. The cost is that the engine leans entirely on the passkey, which is part of why recovery is such a sharp edge, and I’ll come back to that below.

As an initial experiment, I’m pretty happy with it. Logging into different meshes is quick and easy. My password manager (1Password) lets me easily choose between different meshes, and not having to type in a username is great. A passwordless user experience is definitely a better user experience.

Webhooks: Client Credentials

The simplest kind of outside access is one machine talking to another: a webhook that posts an event to a single channel. This is a common pattern that I use frequently. For example, the sensor network that monitors the temperatures in the pumphouse at my cabin gets an event via a webhook from a Helium console.

Since a webhook only ever hits one channel, its credential should be scoped to one channel too. That’s a good fit for the OAuth Client Credentials grant. You create a channel for the webhook and tag it oauth-webhook. The channel’s ECI becomes its OAuth client id, and you create a secret for it from the Channels tab in the UI. The secret is shown once and stored hashed. The sender trades that secret for a bearer token at /oauth/token, then includes the token on every post to the channel’s /sky/ URL.

Two small decisions are worth noting. The first is that the access token is a real token, not the ECI itself. The old server used to hand back the ECI as a shared secret, which mixed up the pico’s address with the secret you need to reach it. Now the ECI stays in the URL, where routing needs it, and the token is a separate secret you can revoke on its own. The second is that tagging a channel oauth-webhook locks it right away. Any request without a valid token for that exact channel is turned away before channel policy even runs. Both decisions are about limiting the damage if something leaks. A webhook URL on its own is now useless, and even a stolen token only opens one channel.

Real webhook senders make this less tidy. Helium and Stripe, for instance, post to a fixed URL and will never call /oauth/token to get a token. For them, the bearer requirement still protects against someone discovering the URL, but it doesn’t verify that the payload actually came from Helium. That job usually falls to an HMAC signature, and I haven’t built that in here. Client Credentials is aimed at senders that can send an Authorizationheader. The fixed-URL senders are a separate problem for another day.

Whole-Mesh Apps: Authorization Code

The other kind of outside access is an app acting for a person across a whole mesh. The example driving the design is Home Assistant sitting in front of a pico mesh. A single channel is the wrong unit here, because the app needs to read and drive many picos under my root, not just one. So this uses the Authorization Code grant with PKCE, scoped to a root pico and everything under it. The flow is the ordinary OAuth dance. I register the app, which gets its own opaque id. The app sends me to /oauth/authorize, I sign in with my passkey and approve a consent screen, and the app trades the resulting code for a token it uses on any /sky/ event or query channel. Refresh tokens allow for rotation, and the access tokens are the same opaque bearers as the webhook case. The only difference is that they’re checked against the whole mesh instead of one channel.

OAuth isn’t required on every mesh and an engine-wide switch would be wrong, because one engine can now host several independent roots that belong to different people. So the switch is per mesh instead. You install an optional Wrangler ruleset, io.picolabs.oauth, on the root pico. Once it’s there, every outside call to that mesh’s /sky/ endpoints has to carry a token. Leave it off and the mesh works the way it always has, under channel policy, with the one exception that oauth-webhook channels are always locked. That means one engine can run a locked-down mesh and an open one right next to each other. The engine still does the real work, holding the tokens, running the ceremony, and serving the routes. The ruleset just marks the mesh and carries its OAuth settings.

Both grant types can live in the same mesh without getting in each other’s way. They share one token store and one check, which just looks at what kind of token it is. A Client Credentials token is tied to the ECI in the URL. An Authorization Code token is checked against everything under its app’s root. Because the two are separate, revoking Home Assistant’s access leaves the webhook credentials alone, and revoking a webhook leaves the app alone. This lets a pico grant access to different services for different reasons.

Tradeoffs and What’s Next

This release makes a few deliberate choices that limit what the engine will do, and they’re worth being explicit about rather than leaving for you to trip over. The first is that there’s no admin. Each mesh has a single owner, and that owner is simply whoever holds the passkey. If you lose track of your passkey, there’s no recovery and no back door that lets you in anyway. That’s a hard edge, but it keeps the model simple, and it fits the pico ethos, where a pico is something you own outright rather than an account someone else grants you. It may not be enough for someone who wants to use the engine as the root of a user-facing system, where ordinary users expect a way to recover a lost login. That’s a fair worry, and one I’ll come back to.

For now the engine also assumes one owner per mesh. That owner can register more than one passkey, so a laptop, a phone, and a hardware key can all open the same mesh; “one owner” doesn’t have to mean “one device.” I expect to relax the single-owner rule down the road, but I wanted to start simple. And while the engine is multi-tenanted now, meaning one engine can host meshes belonging to different people, it doesn’t let just anyone sign up and create one. By default, new meshes come through an invitation from an existing owner. You can turn self-signup on if you want an open system, but off is the default.

Using the root pico as the entry point for all of its descendants is powerful. Signing in once gives you a handle on a whole tree of picos, and everything under the root inherits from that single point of control. But I want to be careful about what that does and doesn’t buy you. None of these changes automatically makes an engine or a pico mesh secure. Passkeys, OAuth, and channel policy are tools, not guarantees. A builder can still open a channel too wide, hand out a token that never expires, or run the engine on a host that isn’t locked down. What I’ve tried to do is give builders the pieces they need to move in a secure direction, with defaults that don’t fight them along the way.

All of this passes the tests I’ve written, but I’ll be honest that I haven’t put it in front of a real use case yet. Tests tell you the machinery works; they don’t tell you the design holds up when someone actually leans on it. The next thing I want to build is a Home Assistant layer for Manifold-based pico meshes, and that will be the first real exercise of this identity work. I expect to find the rough spots that way, and I’d rather learn them by using the thing than by guessing at them now.

Who Gets In

I’ve spent a long time arguing that people should have a personal cloud (to use an antiquated term). By that I mean software that acts for you, that you control, and that isn’t just a rented seat on someone else’s platform. The pieces in this release line up with that idea. A passkey proves you’re you. Your root pico gives you a mesh of your own out in the world. And OAuth lets you lend that mesh’s capabilities to the tools you choose, on terms you can revoke whenever you like. The piece still missing is the pico-to-pico layer, the one that will let a pico move between meshes and let two meshes trust each other without anyone in the middle. That work is still ahead. What I’m releasing today is the part that lets you walk up to a pico engine, prove who you are, and start working in a mesh that is unmistakably yours. If you want the nuts and bolts, the Identity System documentation walks through each piece.

This post is part of a series on using dynamic authorization to control and coordinate AI agents. See the series recap to find other posts in this series.

Agentic AI is still early, and the architectures, protocols, trust models, and operational patterns for agent-based systems will almost certainly change as organizations gain experience with them. The details of MCP, tool invocation, delegation, agent-to-agent interaction, and runtime governance are still being worked out. But the broad authorization problem is already visible: agents need a way to decide what they are allowed to do, what context matters, whose authority they are exercising, and when a requested action must be refused. Most of the difficulty in answering those questions lives in one word from the PARC model: context. A reviewer of a draft of my upcoming book on authorization pushed on exactly that point, arguing that I had underplayed how complicated context becomes once agents are talking to agents, and he was right; this post is my attempt to think through that complication.

Agentic systems change the shape of authorization context. In a conventional application, the policy decision often begins with a familiar question: can this employee, application, or service perform this action on this resource? The principal, action, and resource are usually known to the system in advance, and the relevant context can be collected from a small number of well-understood sources. The decision is nearly self-contained, and an engineer can reason about it by reading a small number of policies.

The signals multiply

Agentic systems are different. An agent may act on behalf of a person, another agent, an organization, or some combination of delegated authorities. It may call tools, consult other agents, transform data, and produce intermediate results before it ever touches the resource that ultimately matters. The principal, action, and resource are no longer fixed at the start; they emerge as the agent plans, and the context that governs each step arrives as a flood of signals rather than a tidy record.

Those signals come in many kinds, and they come from many places. A single decision might have to weigh the initiating principal’s intent, the scope of delegation, consent constraints, personal preferences, organizational policy, data sensitivity, tool capabilities, resource state, risk signals, provenance, and the guardrails imposed by the agent platform or the enterprise. Some of these are stable and institutional, such as a company’s data-handling rules. Others are ephemeral and task-specific, such as the fact that this particular request is two hops removed from a human who only asked for a summary.

It helps to sort these signals by what they actually constrain. Some describe who is really asking and under what authority, such as delegation scope, initiating principal, and consent. Some describe what is at stake, such as data sensitivity, resource state, and tenant boundaries. Some describe how much to trust the request itself, such as provenance, risk scores, and the guardrails the platform is already enforcing. Naming the categories does not make the decision simple, but it keeps the flood from looking like undifferentiated noise.

Signals move through a mesh

Listing the signals is the easy part. The harder question is where each one is consumed, because a request rarely travels in a straight line from a person to a resource. It passes through a mesh of agents, each of which may plan, delegate, and call the next agent in turn. A signal that is decisive at one hop may be irrelevant at the next, and a signal that no intermediate agent cares about may be exactly what the resource needs to see.

Consider a person who asks a coordinating agent to reconcile an invoice, which calls a data-gathering agent, which in turn calls a tool that reads from the finance system. The person’s intent to “reconcile, not pay” has to shape what the coordinating agent is even willing to plan, but it cannot stop there; it has to travel all the way to the last hop so the finance system itself refuses a payment even if some agent in the chain proposes one. The delegation scope has to make the same journey, arriving intact so the finance system can confirm the request stays inside it. A freshly computed risk score on the intermediate data, by contrast, may matter only to the agent that produced it, and never needs to leave that hop at all.

So signals have distinct audiences. Some are steering signals that constrain the behavior of the next agent in the chain, and they need to be carried forward, narrowed, and re-evaluated at each hop. Others are enforcement signals that matter only at the point where authority finally lands on a resource, and they need to survive the whole journey without being flattened or forged along the way. And some are both: the intent in the example steers the coordinating agent’s early planning and still has to be enforced at the finance system, so it must be narrowed as it travels and honored when it arrives. Treating every signal as if it belonged everywhere produces both over-sharing and under-enforcement. Deciding, per signal, who consumes it and where is a large part of designing an agentic authorization system.

There is also a limit to how much of this the calling mesh gets to decide. The system behind an API or MCP server almost always has its own authorization, and it may be governed by a different organization entirely. The MCP server is a way to reach that system, not the place where authority finally lands; the finance system, the database, or the file server enforces its own policy no matter what the agents upstream concluded. Authorization here is layered rather than singular, and no single decision point speaks for all of them.

This is where policy constraints that can be queried along the way earn their keep. If a downstream resource can advertise what it will and will not permit, or answer a “would this be allowed?” question before an agent commits to a plan, the agents upstream can shape their behavior to fit instead of discovering the boundary only when an action is refused. It also raises the bar for the signals a request carries, because the delegation and context have to stay legible to a policy engine the initiating organization does not control.

A non-directed world

There is a deeper shift underneath all of this. Traditional access control is directed and largely static: the system knows that Alice has access to the finance application, the finance application knows Alice, and the relationship is established before either of them does any work. The set of principals is small and enumerable, and the resource can hold a model of who is allowed to knock on its door.

Agentic systems are non-directed. A resource backend has no reliable way to know, in advance, which agent will arrive in the next minute or on whose behalf it will be acting. The requester may be an agent that did not exist 5 minutes ago, spun up to handle one task and then discarded. In that world, identity established ahead of time cannot carry the weight it used to, and the resource has to decide what to allow based on the authority and context presented at the moment of the request.

This is exactly where dynamic authorization earns its place. When the resource cannot pre-enroll every principal, the decision has to move to request time and rest on portable evidence: who initiated this, what were they trying to do, what delegation connects them to the agent now asking, and what constraints ride along with it. The point of the signals is to reconstruct, at the moment of the request, the accountability that a directed system used to establish in advance.

Complexity doesn’t change who decides

Faced with dozens or hundreds of signals in a single request, it is tempting to conclude that the decision itself has outgrown human-authored policy, and that we should let a model weigh the signals and decide. I think that conclusion mistakes a hard engineering problem for a change in who should be in charge. The volume of context is real, but it is an argument about how we gather, normalize, and route signals, not an argument for moving the judgment about what is allowed into a system whose reasoning we cannot inspect or reproduce.

The work that genuinely is hard belongs on the input side of the decision. Assembling the signals, resolving them into a consistent shape, summarizing evidence, and scoring risk are all tasks where models and other tooling can help enormously, and where an agent’s flexibility is an asset rather than a hazard. What should stay deterministic is the final question: given this principal, action, resource, and assembled context, is the action permitted? A policy that answers that question can be read, tested, and explained after the fact, which is precisely what the people whose data and money are at stake are entitled to.

Keeping that line clear does not make the policies simple. Deciding which signals a policy consults, and trusting that they were gathered honestly, is a substantial design problem, and it will pull more structure and more tooling into the space around the decision. But the decision stays somewhere a human can point to and understand. Complexity in the context is a reason to build better machinery for handling signals; it is not a reason to hand the judgment itself to a system that cannot tell us why it said yes.

Agentic AI will reshape almost everything about how context is gathered and carried, and much of what I have described here will look primitive in a few years. What I do not expect to change is the shape of the obligation. When authority lands on a real resource on behalf of a real person, someone has to be able to say why the action was allowed, in terms that person could check. Getting the context right is how we make that answer possible; keeping the decision inspectable is how we make sure it stays true.

Photo Credit: The Shape of Context from ChatGPT (public domain)

When I wrote about the BYU capstone project that built a conversational interface for Manifold, I glossed over something that had to happen first: the platform itself needed to be in shape before students could build a natural language layer on top of it. There were still some loose ends that needed to be cleaned up. That work is now complete, and I am releasing it as manifold-api on GitHub.

This update is the culmination of a pattern I have been refining across several projects. Fuse, the connected-car application I built years ago, organized its picos into communities that we called fleets. The temperature-network that monitors my pump house did the same thing with sensor devices and location groups. Manifold itself is built around that pattern. But each of these systems managed its own notifications, maintained its own pico hierarchy, and reinvented the same community lifecycle logic. The insight behind this update is that the community-of-picos pattern is general enough to be a framework; the domain-specific parts can be layered on top of the basic community logic. By giving Manifold’s community pico a delegation interface and centralizing notifications on the Manifold pico, any domain repo can build its network of picos on a stable platform without duplicating the plumbing.

The biggest architectural change in this update is the notification platform. Previously, domain-specific rulesets called Twilio or Prowl directly. Each network managed its own credentials and delivery logic, which meant the same plumbing was duplicated across repos. The new approach centralizes everything on the Manifold pico: any thing or community can raise a manifold:add_notification event with a subject, message, and identifying attributes, and Manifold handles the fan-out to whichever channels are enabled for that pico (inbox, SMS via Twilio, push via Prowl). Notification channels are opt-in per subject, so a sensor community can enable SMS alerts without every other pico in the network generating noise. This is a cleaner separation of concerns, and it means domain repos no longer need to know anything about how the owner gets notified.

The other major addition is automated bootstrap. The old manual three-step initialization—create tag registry, create owner pico, register tag server—is now handled by a single bootstrap ruleset installed on the root pico. In practice this means spinning up a fresh Manifold instance goes from a sequence of API calls that had to be executed in the right order to a single ruleset install. The test harness depends on this; it would not be practical to run a clean Docker container for every test run if setup were manual.

Testing Against a Real Engine

The test harness in manifold-api is a TypeScript NPM package that spins up a standard pico-engine in Docker, mounts the repo’s KRL files directly, runs bootstrap and lifecycle scenarios, then tears the container down. Because the engine mounts the KRL as file:// URLs, you can edit a ruleset and re-run without rebuilding the image; the iteration loop is fast. The npm test command runs the full suite: KRL syntax parse gate, Docker startup, bootstrap (tag registry, owner, Manifold pico), and thing/community create/add/remove/delete flows. The current scenarios give you a regression baseline before touching any of the core rulesets.

Sensor Network Moves Inside Manifold

Once the platform was solid, I looked at my old temperature-network repo—the one behind the Dragino LoRaWAN sensor network I put in place at a remote pump house—and saw an obvious refactoring opportunity. The original approach managed its own pico hierarchy independently of Manifold. That is no longer true. The new sensor-network repo replaces temperature-network entirely, rewriting all its rulesets to treat sensor communities and devices as ordinary Manifold community and thing picos.

The design is a clean layering. Manifold handles the pico hierarchy, subscription management, thing and community lifecycle, and notifications. The sensor network adds sensor-specific behavior on top. Installing io.picolabs.sensor.network_bootstrap on the Manifold pico is the only requirement to get started. From there, raising a sensor:create_community event delegates to Manifold’s generic community machinery to create a sensor network community pico.

To create a new sensor, raising the sensor:initiation event on a community’s sensor channel delegates to Manifold’s thing creation with a callback. The community receives community:thing_created and finishes sensor-specific setup, installing the appropriate router ruleset for the sensor type, setting up threshold monitoring, and enabling the requested notification channels. Threshold alerts are routed using manifold:add_notification rather than calling Twilio or Prowl directly. The sensor-network rulesets do not know the details of how the owner gets notified.

Supported hardware today is Dragino LoRaWAN sensors: LHT65 (temperature/humidity), LSE01 (soil), LSN50 (multi-purpose), and WL03A-LB (water leak). Each sensor type gets a router ruleset that decodes payloads and raises sensor domain events. Adding a new sensor type requires registering it in io.picolabs.sensor.community and providing a router ruleset—the rest of the stack does not change.

Shared Test Infrastructure

The sensor-network test harness reuses manifold-api‘s infrastructure directly via dependsOn. When npm test runs in the sensor-network repo, it mounts both repos into a single pico-engine Docker container: manifold-api provides the platform rulesets, sensor-network provides the sensor-specific ones. The test suite bootstraps a full Manifold installation, creates a sensor community, initiates sensors for LHT65, LSE01, and LSN50, and tears everything down. Because the platform and the domain layer share a test container, integration failures between them surface immediately rather than waiting for production. A stable Manifold API means sensor-network‘s tests can focus on sensor behavior instead of re-testing platform primitives.

Future Work

Three areas are on the near-term roadmap. The first is bringing over the Personal Data Store (PDS) ruleset from Fuse and updating it for the Manifold model. The original PDS was more than a profile; it was a structured data contract for every pico, organizing state into a profile slice, a namespaced elements store for app and domain data, and a per-ruleset settings store. Apps wrote their configuration data using PDS events rather than touching entity vars directly, which meant the PDS owned the data and could enforce schemas, react to changes, and clean up on uninstall. The shared schema part is what made this useful: when a ruleset declared its data shape through the PDS, other rulesets and the platform could discover what that pico knew how to do and what data it held without hard-coding assumptions about what was installed where.

Right now Manifold has none of that. Profile and configuration data is scattered: wrangler stores a pico name in myself(), the Manifold pico stores names in its thing and community registries, and individual rulesets like SafeAndMine maintain their own contact info. Each domain repo works around the absence of a shared data contract by stitching together entity vars and event attributes on its own. A proper PDS ruleset installed on every pico would replace that sprawl with a single queryable API, give sensor-network a reliable way to describe its things, and, more importantly, give any future domain repo a foundation it can build on without reinventing storage conventions from scratch.

The second item is a Home Assistant integration. I have been running Home Assistant alongside this sensor network and the obvious next step is an API layer that lets Home Assistant read sensor state and trigger automations based on it. Home Assistant has a well-documented REST API model, and the Manifold thing and community queries map cleanly onto it; it is more a matter of building the bridge than solving a hard architectural problem. Longer term, I think we could recreate much of what the original Manifold web app provided—dashboards, thing management, notification configuration—directly inside Home Assistant, which already has a capable UI and a large ecosystem of integrations.

Further out, Manifold needs to support multi-tenancy and proper authentication. The current model assumes a single owner per engine instance, which works fine for a personal deployment but limits how broadly Manifold can be used. Proper authentication and richer authorization—controlling who can raise events and query state on which picos—is the deeper requirement. That is not something Manifold can solve on its own; it requires support from the pico engine itself. The engine would need to enforce identity and access control at the channel level before Manifold could reliably build multi-tenant behavior on top of it.

The pattern here—a domain repo that treats Manifold as a dependency and shares its test infrastructure—is intentional. Any pico-based application that needs communities, notifications, and thing management should be able to build on manifold-api without forking its bootstrap logic or reimplementing its notification plumbing. The goal is to make Manifold a framework that domain repos build on, not a collection of utilities that each repo copies. These two repos are the first concrete demonstration of that working end-to-end.

Photo Credit: Sensor network on Manifold from the sensor-network repository documentation (public domain)

Summary: Picos already have persistent identity, owned state, and an event-driven architecture—exactly the properties that make a good substrate for AI agents. The integration path starts with a simple webhook and leads somewhere much more interesting: a world where AI works for you, reasoning over data that is stored in your picos rather than on someone else’s platform.

When I think about integrating AI into pico-based systems, the temptation is to imagine some deep architectural rework—a new runtime, a new protocol, some fundamental change to how rulesets execute. But I think the right starting point is already there in the architecture: events. Picos already send and receive events. Claude routines already listen for triggers and respond with actions. Connecting them is not a research problem; it is an integration problem, and a shallow one at that.

The simplest version looks like this: a pico fires an event, a Claude routine receives it via webhook, does some reasoning, and posts a response event back to the pico’s event channel. The pico’s ruleset handles the response the same way it handles any other event: routing it, acting on it, updating state. Nothing in this picture requires changes to the pico engine or the Claude API. Both sides speak events; the webhook is just the seam between them.

I saw this pattern clearly when I was building Fuse, the connected-car application built on picos. Fuse picos held the car’s data and fired events when interesting things happened: location changes, diagnostic codes, ignition on and off. The missing piece, looking back, was anything that could reason over those events rather than just route them. An AI routine that receives a pico event carrying a diagnostic code and responds with an interpretation—or a question—is exactly the kind of capability Fuse needed and couldn’t easily have in 2014. Fuse sent notifications, but bare notifications are not very useful to most people. An AI layer that enriches a location event with context (“you’re near the dealership where your recall service is overdue”) or translates a diagnostic code into plain language and a recommendation would have made Fuse dramatically more useful to drivers.

Project Neck Pain showed something similar from a different angle. That project used picos to hold personal health data: appointments, sensor readings, notes. The pico owned the data; it didn’t live in some third-party health app’s database. But ownership without intelligence is just storage. The interesting question was always: what should happen next? We built rules that would automate some of the drudgery of dealing with the healthcare system. But, it proved to be too brittle. AI changes that completely. An AI routine that receives an event—a symptom log, a missed appointment, a change in a sensor trend—and responds with an inference is not replacing the pico’s role. It is extending it. The pico remains the locus of identity and state; the AI contributes reasoning that the ruleset alone can’t do.

This suggests a natural progression for AI integration in pico systems.

1. The first step is the webhook pattern I described: AI as an external actor that exchanges events with the pico. This just uses the http:post() to call a URL.

2. The second step is tighter: rather than an external routine, a KRL action sends a request to Claude with a callback event URL, and a separate rule handles the response when it arrives asynchronously. This fits how picos actually work—rules fire in response to events, and Claude’s processing times make a synchronous call inside a rule impractical. The callback event is the right model; Claude becomes a capability the ruleset can invoke, not a separate system to coordinate with by hand.

3. The third step is the one I find most architecturally interesting. At this stage, Claude uses pico query endpoints as tools to read and write persistent state across sessions. The pico is the memory. This matters because most AI memory schemes are ad hoc, using a database or even a Markdown file for memory. Picos already have the right structure: they are named, persistent, and owned by a specific identity.

4. The fourth step follows from the third. If Claude holds a longer-running task and the pico holds the relevant state, then Claude can fire events into the pico graph to make things happen—not just to return data to the ruleset, but to orchestrate behavior using the pico’s event channels the way a person would.

What makes this progression coherent is that picos already have the properties that make for an interesting AI integration.

• They have persistent identity—each pico is a specific thing with a stable address.

• They have owned state—the data inside a pico belongs to the pico, not to a platform that might revoke access or change terms.

• And they are event-driven—which is exactly the interface AI systems are designed to plug into.

I’ve argued for years that picos are the right substrate for building systems where people and things control their own data. Adding AI reasoning to that substrate doesn’t change the argument; it strengthens it. An AI that reasons on your behalf, over your data, stored in your picos, is a fundamentally different thing from an AI that reasons on your behalf using data held by someone else. The first is an agent working for you. The second is an administrative intermediary with a language model grafted on.

Picos form natural hierarchies. A car pico holds what the car knows; the household pico that owns it can query across all its children—car, health devices, calendar—and give an AI a cross-domain view that no flat memory store provides naturally. Each pico in the hierarchy can have its own AI context and reasoning scope, and parent picos can aggregate across children. That hierarchy also encodes privacy boundaries: an AI reasoning on behalf of the household can traverse the graph with appropriate permissions, but no external system can simply reach in. The ownership structure is not metadata bolted on; it is the architecture.

The webhook integration is worth building right now because it establishes the semantics that the deeper integrations depend on. Which events are meaningful enough to route to an AI? What does a useful response event look like? How does the ruleset act on it? Answering those questions with a simple prototype clarifies the architecture far better than designing it on paper. That is how picos got to where they are today, through real use cases that forced the design into focus. The AI integration will be no different.

Photo Credit: Owned AI Agents via Picos from DALL-E (public domain)

The Internet Identity Workshop met for the 42nd time at the Computer History Museum in Mountain View, California, April 28–30, 2026. As always, the Open Space unconference format let the agenda emerge from the people in the room. And, as always, the room delivered. Over three days and fifteen slots, participants convened 158 sessions spanning identity architecture, agentic systems, legal frameworks, cryptographic foundations, and the human stakes that tie all of it together.

We also held the second Agentic Internet Workshop (AIW2) on Friday, May 1, immediately following IIW. Like the first AIW last October, it used the same unconference format, this time with a sharper focus on how identity infrastructure supports autonomous agents operating on behalf of people.

Attendance

IIW 42 brought together 287 participants, matching last fall’s IIW 41 exactly. That consistency is worth noting. There are lots of identity conferences now and the hype cycle pulls attention in every direction, but the identity community keeps showing up. The number reflects sustained interest in solving real problems. Because that’s what IIW offers: space to solve problems. It’s a workshop in thr true sense of the word.

The hallway track was as rich as always. Some of the best conversations at IIW happen between sessions, at lunch, or during the demo hour, where people pull out laptops and show working code rather than slides. One of the reasons that meals are included at IIW is to keep the energy high and the conversations flowing.

Geographic Diversity

The geographic picture at IIW 42 was familiar in its broad strokes. The United States accounted for 229 of 287 attendees, with California leading the way at 119. San Francisco (19), San Jose (14), and Oakland (8) anchored the Bay Area contingent, while Seattle (7) and Los Angeles (7) rounded out the West Coast presence. Utah contributed 14 attendees, Texas 12, and Massachusetts 12, reflecting the distributed geography of the identity community within the U.S.

Internationally, Japan continued its strong showing with 12 attendees, primarily from Tokyo (9). The United Kingdom sent 7, Canada 5, Switzerland 4 (all from Zurich), Poland 3, and Germany 3. We saw participation from South Korea and several other countries as well. The attendee map tells the story visually: clusters in North America and Europe, with welcome pins in Asia, South America, Africa, and Australia.

I am glad to see the map filling in beyond the usual corridors, but there is still work to do. Identity challenges are global, and the solutions we build at IIW benefit from hearing voices that face different regulatory environments, infrastructure constraints, and cultural expectations. We continue to support IIW-Inspired^TM regional events like DID:UNCONF Africa and DICE to extend the conversation. If you know identity builders in underrepresented regions, point them our way.

One concrete way to help is through the IIW Global Participation Scholarship, which funds travel and registration for attendees from regions that are underrepresented. The scholarship makes a real difference; it brings perspectives into the room that change the quality of the conversation for everyone. If your organization benefits from the work that comes out of IIW, consider sponsoring a scholarship for IIW 43. The identity infrastructure we are building is meant to serve people everywhere; the people building it should reflect that.

Topics and Themes

The agenda at IIW is built fresh each morning. Participants write their session titles on index cards, announce them to the room, and place them on the agenda wall. That emergent structure is one of the things that makes IIW work; the topics reflect what people are actually building, struggling with, and thinking about right now. Here’s a recap of what the community brought to the table this time.

SEDI and the duty of loyalty were prominent throughout the workshop. Sam Smith led sessions on KERI/ACDC bulk issuance for SEDI privacy and on cryptographic foundations, while separate conversations explored SEDI’s legal framework, its duty of loyalty provision, and how it connects to protocols like MyTerms. As I wrote in Data Protection Missed the Point; Loyalty Gets It Right, the duty of loyalty shifts the basis for regulation from data to the relationship. That idea had real traction in the room, with people working through what it means for implementation, not just theory.

Agentic identity was everywhere. Sessions covered agent taxonomy (what counts as an agent? ephemeral versus persistent?), OAuth for sub-agents, AI agents and open banking, agent storyboarding, and agentic identity credentials. Drummond Reed introduced the Decentralized Trust Graph and First Person Project. Dick Hardt led an AAuth deep dive, exploring his open protocol that gives agents their own cryptographic identity without pre-registration or shared secrets. The question running through all of these was not whether agents need identity; it was how we build identity systems that let agents act on behalf of people without becoming another layer of administrative intermediation. A Dilithium demo showed server-side user-agents operating at speed, and multiple sessions explored how authorization models need to adapt when the entity presenting a credential is not a human but a piece of software acting with delegated authority.

MyTerms, the newly published IEEE 7012 standard, had a strong showing across all three days. Doc Searls led MyTerms 101 and 101.5 sessions, and Iain Henderson ran a session connecting VRM, MyTerms, and fiduciary agents. MyTerms gives individuals a protocol for proposing terms to websites as first parties rather than clicking through adhesion contracts. The connection to SEDI’s duty of loyalty—which I explored in a post from VRM Day—was a recurring thread. Together, they start to look like operational infrastructure for digital relationships where people have standing as participants, not just data subjects.

The standards and protocol track was robust. OpenID4VC had sessions covering updates and implementation details, including server-to-server issuance via OpenID4VCI. Aaron Parecki ran OAuth 101 and John Bradley covered FIDO and WebAuthn. The W3C Verifiable Credentials Working Group held a session on its new charter and current work. Frederik Krogsdal Jacobsen ran sessions on formal security verification of specs and on interaction endpoint authorization via first-party apps. Content authenticity also had a visible presence, with sessions on the C2PA standard and the Content Authenticity Working Group (CAWG), plus an originator profile session; as AI-generated content proliferates, provenance is becoming an identity problem whether the identity community planned for it or not. These sessions reflected a community that is past the design and implementation phases and into the details of making things work at scale.

On the cryptographic front, we saw renewed energy around:

• Post-quantum readiness—a Dilithium demo and sessions on cryptographic agility showed the community taking the transition seriously, not just talking about it.

• Zero-knowledge proofs—ZKP 101 sessions, a ZKP age verification demo, and Sam Smith’s session on misapplications of bare signatures and ZKPs for non-ephemeral case proofs.

• KERI and GLEIF—Kent Bull ran KERI + did:webs 101 with GLEIF, connecting decentralized key management to real-world organizational identity at scale.

Trust infrastructure surfaced as a theme in its own right. Erica Bjune led a two-part session on trust infrastructure as a public utility. Mike Leahy convened the first Fiduciary Commons session, working from first principles toward law. Joe Andrieu provided a digital fiduciary update. These conversations share a premise: that trust is not just a technical property of a protocol; it is a social and institutional arrangement that needs its own infrastructure. That framing resonates with the broader shift from building identity tools to building identity institutions.

The EUDI wallet drew attention with sessions on the German implementation and on wallet-level authentication and authorization. These sessions brought a European regulatory perspective into the room, grounding abstract wallet discussions in the specifics of what member states are actually building.

There were also sessions looking at identity at a more foundational level. Christopher Allen revisited SSI principles for the next decade in his “SSI 10th!” session. Denny Wong asked why personal identity matters in the era of AI. Eric Welton explored cognitive liberty and captive audiences through a First Amendment lens. Dean Saxe and Eve Maler convened a session on death and the digital estate, something that eventually concerns us all. And Wendy Seltzer led a session on identity and geopolitics, reminding us that the infrastructure we build operates within political systems that have their own ideas about who controls identity, a good counterpoint to the SEDI discussions.

The 101 sessions deserve a mention. IIW has always been a place where newcomers can get grounded, and this time the program included introductions to OAuth, OpenID Connect, FIDO/WebAuthn, ZKPs, SSI, OpenID4VC, authorization, and content authenticity. Steve McCown and Omri Gazitt ran particularly well-attended sessions. These 101 tracks are not filler; they are how the community renews itself and ensures that the deep-dive sessions in later slots have a prepared audience.

Demo Hour

One of IIW’s distinctive features is the speed demo hour on Wednesday afternoon. Twenty tables, each with a numbered sign, fill the Grand Hall. Each demonstrator gives a five-minute demo, then the audience rotates to the next table. If you’re disciplined, you can see 10 of the 20 demos over the course of an hour. It is loud and seemingly chaotic, but it works. Demo hour is about working code and running systems. You can tell a lot about a community by what it chooses to demo.

This time, the demo tables told a clear story: agents have arrived, and the identity community is building the infrastructure to make them trustworthy. Niki Niyikiza showed Tenuo’s attenuating authorization tokens that cryptographically narrow an agent’s capabilities at each delegation hop. Dick Hardt demoed AAuth, an open protocol giving agents their own cryptographic identity without pre-registration or shared secrets. Kenta Takahashi and Takayuki Suzuki demonstrated Proof of Human Delegation, using biometrics to prove that an agent acts on behalf of a specific person within their stated intent. Ankit Agarwal showed KYAPay, a protocol for agent authentication and tokenized payments. And Alex Olivier and Atul Tulshibagwale demoed a reference implementation of the OpenID AuthZEN MCP Profile for fine-grained, parameter-level authorization before an MCP server executes a tool. The common thread: agents need identity, authorization, and accountability, and those cannot be afterthoughts bolted on later.

Wallets and credentials showed up in force. Rob De Feo showed an AI agent completing an age-verified purchase and hiring a car through the EUDI Wallet via OpenID4VP. Jarek Sygitowicz and Flora Frend demonstrated practical EUDI implementations using the Digital Credentials API on iOS and Android with fallback to legacy eIDs. Dmitri Zagidulin showed Freewallet, a free, open-source web wallet for DIDs and verifiable credentials. Christopher Allen demoed XIDs, DID-inspired identifiers built on Gordian Envelope that give holders, rather than issuers, control over what gets revealed through selective disclosure and redaction.

Several demos pushed into new territory. Iain Henderson and Jon Udell showed MyKey combined with MyTerms and XMLUI, connecting decentralized identifiers to privacy terms and a semantic UI framework. David Condrey’s WritersProof captured cryptographic proof of human authorship by entangling identity, keystrokes, and timing into an unforgeable hash chain. Mahesh Balan showed MyWellWallet, a patient-owned health wallet using local LLMs and FHIR to give people an intelligent view of their health data without sending it to the cloud. And Deb Bucci demoed an execution-time delegation harness that evaluates whether a delegated action still aligns with a person’s intent at the moment it is requested. Twenty tables, twenty teams showing things that did not exist a year ago.

Looking Ahead

Because IIW runs on Open Space, every workshop is a fresh expression of where the community actually is. No program committee selects topics months in advance; the people who show up decide what matters that morning. That is what makes each IIW genuinely new. The topics at IIW 42 reflected a community whose conversations were less about whether the architecture is right and more about how to deploy it, govern it, and make it work for people who will not attend an unconference. SEDI’s duty of loyalty, MyTerms, agentic identity, post-quantum readiness, the EUDI wallet: these are implementation challenges now, not research topics. The people in the room are doing the implementation.

Huge thanks to everyone who convened a session, asked a hard question, showed a demo, or pulled someone into a hallway conversation. That is what makes IIW work, and it has been working for 42 editions now. The book of proceedings will be available soon with session notes, links, and other important details.

Mark your calendars: IIW 43 is November 3–5, 2026, with AIW3 on Friday, November 6. Tickets will be on sale in about a month. Sponsorships are available now. Until then, keep building.

You can check out all of Doc’s photos of IIW 42 for a visual report on who, what and when.

Photo Credit: IIW XLII Photos from Doc Searls (CC BY 4.0)

Alan Mayo’s latest Identity 2.5 newsletter poses a useful strategic question: when we build digital identity reuse, are we enhancing existing infrastructure, duplicating it, or replacing it? He maps three approaches onto those choices: networked identity enhances, credential/wallet identity duplicates, and decentralized identity replaces. He then places Utah’s State-Endorsed Digital Identity (SEDI) squarely in the third category and concludes that networked identity is the obvious, lowest-risk path forward. The framework is a good lens. But his classification of SEDI is wrong.

What Mayo Gets Right

Mayo is right that societies already have digital identity. Government agencies, banks, and healthcare systems hold digital records of who we are; what they issue to us are physical documents and credentials that allow a basic form of identity reuse. The strategic question is not whether to create digital identity but how to let people reuse it effectively. That reframing is valuable because it cuts through a lot of the hype that treats digital identity as something we still need to invent.

He is also right that wallet-based credentials introduce real operational complexity. Lifecycle management, revocation, device binding, recovery, verifier trust, wallet trust, and credential freshness all matter. His critique of naive “just put credentials in a wallet” thinking is fair; a high-assurance identity ecosystem cannot rely on static credentials floating around indefinitely. Utah’s own mobile driver’s license work already recognizes these problems by emphasizing consent, selective disclosure, anti-tracking, and state-signed credentials under individual control.

And he is right that institutional trust does not disappear. SEDI still needs authoritative issuers, governance, endorsement rules, certification, relying-party accountability, revocation, and legal frameworks. Even the ACLU’s analysis of Utah’s legislation praises it as a legal and governance framework with important privacy protections, not as magic cryptography that makes institutions irrelevant. None of that goes away in a world with digital credentials. The question is how institutional trust gets expressed and who controls the presentation.

Where the Framework Breaks

Mayo’s big mistake is classifying SEDI as “Decentralized Identity” in the purist replacement sense. He characterizes that category as individual-held identity, cryptographic security, self-sovereignty, and no central control. That badly misrepresents first person identity in general and SEDI’s architecture in particular. SEDI is not trying to eliminate institutional trust or replace government identity infrastructure. It is a state-endorsed legal and governance framework for digital credentials. The state still verifies, endorses, regulates, and defines duties for participants. That is not anti-institutional decentralization; it is public trust infrastructure with individual control over consent, disclosure, and the terms of the relationship.

He also conflates credential identity and decentralized identity in a way that obscures what SEDI actually does. SEDI is closer to a hybrid: credential-based presentation with state endorsement, legal duties, privacy protections, and governance. It is not simply duplicating current identity infrastructure into wallets, and it is not replacing identity infrastructure with cryptographic self-sovereignty. It sits outside Mayo’s three-bucket taxonomy because it combines institutional authority with individual agency in ways his framework does not accommodate.

Mayo overstates the idea that credential systems make every phone wallet “a mini Identity Provider.” A wallet is never the authoritative source of identity. Even with self-issued credentials, the authority rests with the individual issuing the credential, not the container. The wallet is a presentation mechanism; the issuer remains authoritative for the claims it signs. The hard problems of binding, revocation, and recovery are real, but they do not turn the wallet into a source of truth. They turn it into a presentation layer, one the individual controls rather than the institution.

He also misses SEDI’s most important innovation, and it is not a technical one. SEDI’s distinguishing move is law before technology. The point is not that new cryptographic techniques will solve identity. The point is that digital identity needs constitutional principles, fiduciary-like duties, voluntary adoption, non-tracking rules, selective disclosure, and enforceable accountability. As I wrote in A Legal Identity Foundation Isn’t Optional, SEDI provides a legal base layer for first person digital trust. The ACLU did not praise Utah’s legislation because of its cryptographic architecture; they praised it because it adds civil-liberties protections to digital identity. The duty of loyalty provision places a fiduciary obligation on institutions that rely on a state-endorsed digital identity. That is a governance innovation, not a technology choice.

Networked Identity Is Not the Obvious Answer

Mayo treats networked identity as the obviously practical path, but that model has its own structural weaknesses. A central switch creates a single point of dependency and failure. Online-only availability means the system breaks when the network does. Relying-party accreditation creates bottlenecks that limit who can participate. And a model where every identity transaction runs through a network switch creates inherent opportunities for surveillance, correlation, and gatekeeper control. SEDI is partly a response to exactly those risks.

The Scandinavian BankID systems that Mayo points to work well in small, high-trust societies with strong institutional foundations. They are real accomplishments. But they also concentrate identity infrastructure in banking consortiums, require online connectivity for every transaction, and give the network operator visibility into every authentication event. Those are acceptable tradeoffs in some contexts. They are not acceptable when the policy goal is individual control, minimized disclosure, and resistance to tracking.

Networked identity is also inherently national; each country’s BankID is a separate system tied to its own banking consortium. Cross-border use requires additional federation infrastructure that reintroduces much of the complexity Mayo attributes only to credential and decentralized systems. A networked model can be useful for some transactions, but it does not automatically win when the policy goals include individual control, minimal disclosure, offline capability, cross-border portability, and resistance to surveillance.

What SEDI Actually Is

None of this means SEDI is the clean best-of-all-worlds answer. It has its own hard problems: wallet ecosystem maturity, credential lifecycle management, adoption incentives, and the political challenge of getting other states and countries to recognize Utah’s framework. Mayo’s operational concerns about credential systems apply to SEDI too; they are not magically resolved by putting a legal framework around them.

But SEDI does not fit cleanly into any of Mayo’s three buckets, and that is the point. It is better described as state-endorsed, rights-first digital identity reuse. SEDI keeps institutional authority where it belongs: the state still verifies identity, endorses credentials, and defines legal duties for participants. It moves presentation and consent closer to the individual: the person controls what they disclose, to whom, and under what terms. And it wraps the whole system in public-law governance: constitutional principles, a duty of loyalty, voluntary adoption, and enforceable accountability.

That is not “replacing” identity infrastructure. It is not “no central control” or “all power rests with the individual.” It is an attempt to join cryptographic trust and legal trust into a public identity foundation. The state provides the endorsement and the legal framework; the individual provides the consent and controls the presentation; the technology provides the mechanism for doing both securely. As I explored in SEDI and Client-Side Identity, this resolves a problem that has plagued digital identity since the 1990s: people will not pay for identity proofing, but they already pay their state government for it without realizing it. SEDI routes around the economic bottleneck that killed client-side certificates.

Mayo’s useful contribution is the question itself. But the answer for SEDI is none of the above. SEDI enhances institutional trust by giving it a legal and cryptographic expression that the individual controls. It does not duplicate infrastructure into unsupervised wallets. It does not replace institutional authority with self-sovereign cryptography. It creates a new kind of public trust infrastructure in which the institution, the individual, and the law each carry weight. Getting SEDI’s category wrong makes it easy to dismiss. Getting it right means engaging with the harder, more interesting question: what does identity infrastructure look like when it starts from rights and relationships rather than from databases and documents?

Photo Credit: SEDI: None of the Above from ChatGPT (public domain)