Collection

Architecture

Atomic tooling: one tool per domain, the orchestration inside it, and a model that only has to say what it wants

Most of an agent's tool calls are plumbing: read a file, hash it, write it, re-read it, retry a search, page a result. The industry's answer is to let the model write code that does the plumbing in a sandbox. This system takes the opposite route: one tool per domain whose arguments carry a command and its complications, with the fallbacks, verification, hashing and result budgeting built into the tool. The model declares; the runtime executes, bounds and records. Five such tools are live. Here is what they do, how they compare to programmatic tool calling, and what is still missing.

Architecture

Authority outside the model: a prospective control plane for containing agent actions

In this build a model does not set its own authority: limits are a token checked outside the model, actions are declared operations the runtime executes, and every use and refusal is recorded by the runtime. This page states what that could contain in development, training-time tool use, evaluation and deployment, what is enforced today, and what full containment would still require.

Architecture

The Directory and the Ledger: a system that lists everything it can do and keeps everything it did

An AI agent is only as trustworthy as two answers: what could it have done, and what did it actually do? miscsubjects answers both with data. A Directory holds every capability as a row that contains the exact call that runs it. A Ledger keeps every request and every answer as exact bytes, stored once under their hash. This is the architecture, with the measurements.

Architecture

Live software objects: what a model's reply can now be, with the receipts

A model's reply, an article and a workspace tab can now carry the same live object: a task, a conversation, a sheet, a script run, a folder, a place, a price, a switch. Each is drawn as its app, acts through the app's own controls, is read back from the app while shown, can be answered to in words, mirrored into another app, shared by link, and keeps its receipts. This page is the inventory of what is registered and the record of what was proved on the live build on 9 October 2026.

Architecture

Task provenance: every payload of a piece of work, on one page the worker could not have written

When an agent says "done", the only witness is usually the agent. This system binds a scoped token to a task, so every call made for that task is filed under it by the runtime, with its exact request and answer. The task's page is assembled from those records, not from the worker's report. This article walks the mechanism, a recorded run, a full lead-to-inbox example, and the specified projection from a task to a shareable article with hashed sources.

Architecture

Unified dispatch: one runner for the terminal, browser, phone and cloud, and tokens that lend out exactly part of it

Every capability of this system, from a shell command on a Mac to a browser session, an iMessage line, a cloud container and 1,500 web services, is one row called through one runner with one call shape. That single authority is then lent out in pieces: a scoped token, built on the macaroon construction, carries its own readable limits, can be narrowed by whoever holds it, can never be widened, and leaves a record of every use and every refusal. This is the design, the cryptography, the recorded proof and the honest edges.

the whole object this page is drawn from, as JSON · Open JSON

{
  "schema": "page/1",
  "id": "type:architecture",
  "layout": "collection",
  "kind": "Collection",
  "status": "published",
  "title": "Architecture",
  "summary": "",
  "query": {
    "kind": "architecture"
  },
  "version": "52391baffd5497ddf05fd625728abbeef039e2852c5f98b92748c5862a87f691"
}