Mailboxes for agents
The inbox is the least obvious primitive in Glove and the most reused. It is how an agent waits, and once you have it, inter-agent messaging is nearly free.
An agent that can only act inside a single request cannot wait. It can ask a question and block on the answer, which is fine when the answer is a click away. It cannot say "tell me when the shipment lands" and then go do something else for a week. Every real workflow has at least one of those. A payment that confirms later. A restock. An approval from a human who is asleep. A background job that will finish in an hour.
The usual answer is to bolt a queue onto the side of the agent and write glue. Glove's answer is a primitive small enough to describe in one sentence: the inbox is a persistent async mailbox.
The clipboard and the letter
Glove has two ways for an agent to get something it does not have.
The display stack is synchronous. A tool pushes a form or a confirmation onto the screen and the tool's execution, and with it the whole agent loop, suspends until the user resolves it. That is like handing someone a clipboard and waiting.
The inbox is asynchronous. The agent posts a request it cannot fulfill now, with a tag, a description in plain language, and a flag for whether it should block on the answer. The request is persisted as pending. Some time later an external service, a webhook, a cron, a person in an admin panel, marks it resolved and attaches a text response. On the agent's next turn, the resolved items are injected into the conversation as messages and marked consumed. That is like dropping a letter in a mailbox and checking back later.
Both request and response are plain text. The model reads the reply the same way it reads anything else. There is no structured payload to design, because the whole point is that the thing on the other end might be a human typing.
It survives everything
Three properties make this a primitive rather than a convenience.
It survives the session. The item lives in the store, not in the context. Restart the process, open a new conversation, run on a different instance, and the pending request is still pending and the resolved reply still arrives.
It survives compaction. When the context window fills and Glove summarizes the history, pending inbox items are carried into the summary explicitly. "I am still waiting on something" is exactly the fact a summarizer would otherwise drop.
And it is enabled by implementing four optional store methods. Glove's store adapters switch features on silently: implement task methods and you get a task tool, implement permission methods and you get consent gating, implement the four inbox methods and you get glove_post_to_inbox. Skip them and the feature does not exist. Nothing to configure, nothing to turn off.
Blocking is deliberately soft. If the agent marked a request as blocking, it is reminded on subsequent turns that it said it would wait. It is not mechanically prevented from acting. An agent that has decided to wait for a payment confirmation and is then asked an unrelated question should be able to answer it.
Then the mailbox turned out to be a network
Here is why the inbox is the most reused primitive in the framework. Once an agent can receive a resolved message from outside its conversation, it does not matter who wrote the message.
glove-mesh is inter-agent messaging built entirely on the inbox. When agent A sends a message to agent B, mesh drops a resolved inbox item, tagged mesh:from:a, into B's store. B's next turn surfaces it through the exact same injection path it already had. No new agent-loop semantics. The mechanism was already there.
Four tools show up: send a direct message, broadcast to every peer, list the agents on the network with a capability filter, and acknowledge. A blocking send inserts a pending item in the sender's inbox tagged with the message id, and an acknowledgement or a reply from the recipient resolves it. A reply implies an ack, which saves a round trip.
The transport is an adapter. In-process for tests. Redis pub/sub, NATS, HTTP webhooks for real deployments. Mesh does not care, which is the same posture every Glove primitive takes toward infrastructure you already own.
Peers, not children
We want to be careful about what mesh is for, because "multi-agent" is a phrase that means everything and nothing.
Glove already has subagents: a parent agent delegates a bounded task to a child with an isolated history, and waits. That is hierarchy, and it is the right tool when one agent is in charge.
Mesh is for peers. Several specialized agents, running asynchronously or in parallel, that need to coordinate without one of them owning the others. A planner and a set of workers. A research agent, a drafting agent, and a review agent passing a document between them. The docs say it in five words: mesh is for peers, not children. If you find yourself using broadcast to give orders, you wanted a subagent.
The two are distinguished by intent even though they share a surface. Posting to the inbox means "something outside this conversation will resolve this." Sending on mesh means "I am talking to another agent." Same store, same injection, different tag prefix.
What it does not do
The docs are unusually candid about the edges, and we would rather repeat them than have you find them.
There is no authentication. The sender field is claimed by the sender and not verified. If you need signed messages, verify them in your adapter's subscribe handler; mesh stays lightweight on purpose. Broadcast with blocking resolves on the first ack, and later acks arrive as ordinary items. There are no groups or topics yet.
None of that is hidden inside a hosted control plane. It is a few hundred lines you can read.
The shape of the thing
If you squint, the inbox is the only genuinely new idea in this post, and it is barely an idea. It is a table with a status column. But it is the table that lets an agent stop being a request handler and start being a participant in time. Everything on top of it, waiting for the world, talking to peers, sleeping and waking in a subprocess runtime, is composition.
That is what we mean when we say we build primitives. Find the smallest thing that unlocks the most, make it boring, and let the interesting systems be assembled from it.
