ML Architecture
Agents You Can Read
A bill that only defines a word, and the on-device standard I'd answer it with.
What the committee asked
California's SB 1106 (Cabaldon) defines "agentic artificial intelligence" and does little else: the Office of Emergency Services accounts for it in its risk analysis, and, in the Assembly Committee on Privacy and Consumer Protection's amendment, the Department of Technology adds it to its inventory of state systems. It binds no builder, and it passed the Senate 39–0 with no opposition on file. But California's 2024 definition of "AI" already appeared in 13 code sections eighteen months later. A definition isn't a rule, but it's where every later rule starts. The committee's analysis shows what those rules will lean on:
- Define by what a system does, not how it's built. It calls the first draft "neither simple nor broad": anchored to "stochastic" AI, and requiring all three capabilities at once.
- The risk is the action, not the answer: "whether the system chooses appropriate actions, uses tools safely, and respects legal and personal boundaries." Its example is a coding agent that reportedly deleted a live database during a code freeze.
- Disclosure is the mechanism. The amended inventory asks, per system: what it can do, what data it uses, what mitigates the risk, and how a decision can be contested.
The amended definition covers a system that breaks goals into tasks, adjusts from results, and acts in the world: executing code, using tools, making purchases, accessing authenticated accounts. A system that only answers prompts, with no network egress or shell, is excluded.
The business: open agents, closed host
Craft's Agent Store sells agents for Craft. Per the creator guide, each is a Swift package on GitHub implementing GraniteAgentPackage. The store lists the repository, and Craft builds it on your Mac at the commit the creator published, one process per call. Creators price it free, per call in Credits (1 Cr is a cent, refunded if the agent fails; marked "coming soon"), one-time ($0.99 to $999.99), or by subscription ($5 to $100 a month), and keep 90%. Payouts aren't open yet. None of that depends on secrecy.
"But anyone can point an AI at the repo." They can. A license can stop a competitor lifting your code into a closed product, but it can't stop a model reimplementing what the code does, and whether that's a derivative work is unsettled (I'm not a lawyer; see Fair Use). So don't sell the code. Sell what a copy lacks: a metered call with a refund, maintenance for code that tracks a changing platform, and a creator who's accountable. A static one-shot agent is replicable, and I expect it to earn little.
And there's the part that isn't open: Craft itself. The agents are open source. Craft, the host that finds, calls and composes them, is closed, with proprietary orchestration. A clone of an agent gives you one piece, not the layer that decides when to call it, turns what a person asked into its input, and reads the answer against what was asked for. The spec shows what a host consumes: an agent's summary and guide, what it makes, and made reported against expected. Understanding those inputs and outputs across many agents is where the orchestration earns its keep, and it's built with room for solutions that don't exist yet. That's the reason to use Craft when the agent is a prompt away from a copy.
The cost: the host is the one thing you can't read. What I can do is keep the spec's host checklist public, so a host can be tested against it, and let anyone write a host of their own.
On licenses, I'd propose (none of this exists yet): require a license, OSI-approved for anything wearing the open-source label; let creators choose permissive or copyleft (MIT for the Craft agents, GPL-3.0 for VisionAX); and use a network copyleft license where there's a hosted backend. A closed backend is allowed, as long as the listing says the agent reaches it.
Rao's agents and MCP, side by side
| MCP | Rao's agents (granite-agent/1) | |
|---|---|---|
| What it is | An open protocol for how an AI app connects to tools and data | A standard for a Swift package an app finds, builds, runs and lists |
| What you install | A server: a program on your machine, or a service someone else runs | Source code, built on your Mac |
| Can you read what runs? | Sometimes. A remote server can't be read by anyone but its operator | By design: Craft builds the commit the listing names |
| Where it runs | Your machine, or the publisher's servers | Your Mac, in its own process per call, released once it answers |
| How it says what it does | Tool descriptions, plus optional hints clients are told to treat as untrusted | A summary, a guide, an input schema, and what it makes, where it writes and what it never does |
| What backs the declaration | A registry can verify who published a server, as I understand it, not what it does | The executable's SHA-256 is checked before every launch. never is not yet enforced, and Rao checks listings for form, not safety |
| Payment | Not defined by the protocol | Free, per call, one-time or subscription |
| Ecosystem today | Broad: any language, any client | Small: Swift on Granite, one host, 16 agents, all from Rao |
Here's the plain version: granite-agent/1 is an open-source, on-device schema standard, the counterpart to MCP. MCP, which Anthropic introduced, is built around servers: a client connects to a program or service that can run anywhere. This starts from the other end. The unit is source that your own machine builds, runs one call at a time, and releases, with a schema for what the agent takes in, what it makes and where it writes. It's the same job, a shared schema so any host can use any agent, in the opposite place. They're counterparts, not rivals. For a SaaS API or a database someone else hosts, a server is the right shape. For something that runs on your machine and touches your files, you want to read it first. I haven't built a bridge between them.
That's why it fits the committee's disclosure idea. MCP's own docs treat tool annotations as untrusted hints, which is a reasonable choice for a protocol. A declaration is only as honest as your ability to check it, and when the source is what gets installed, you can check it. The spec already answers half the inventory: what an agent can do (summary, guide, makes), its data (the input schema, makes.into), its performance (made against expected, with time and memory measured by the host) and how it fails (typed refusals, each with its fix). What it lacks is what an agent reads, reaches and spends, and a fence: it describes a process boundary, not a permission boundary.
Where it falls short today
As of November 4, 2026, from Rao's own guide and terms:
- There's no review step. "We check listings for form, not for safety."
- A public repo and a license aren't required. The guide says "Make it public"; the terms don't require it.
- Every push updates the listing by default, unless the creator chooses tagged releases.
- A takedown isn't a kill switch. Installed copies keep working until the user removes them.
Where I'd start
All proposals, in order of cheapness:
- A capability card as a listing precondition: what a package reaches, reads, runs, spends and signs in to. These are the bill's hallmarks, as data, and optional fields fit within
granite-agent/1's versioning. (The field names are illustrative.) - Check the card against the source. The store can compare
reaches: []with a package that links a networking API and refuse the listing. It will miss things, but a creator can't hide behind a registry's inability to look. - Gate listings on openness: a public repo, an OSI-approved license, a pinned commit that builds clean. Still not a safety review, and the store should keep saying so.
- Turn
intoandneverinto a fence. One process per call is where a sandbox can attach. I haven't built it, so until thenneveris a promise. - Hold updates that widen the card, and add revocation, checked beside the SHA-256 the host already verifies, so a takedown reaches installed copies.
Dashed boxes aren't built yet.
Technical version
The sixth thing is the point of the first five: publish the inventory. The state will ask of its own agents what the card already holds, and the store can publish the same shape for every listed agent, before anyone requires it.
Does the bill's definition cover Craft? Probably: a host that breaks a goal into steps and calls agents that run builds and edit files on your machine is acting in the world. I'd rather assume I'm covered than parse my way out of it. If the only artifact is a claim, the claim has to be trusted. If the artifact is the source, the claim can be checked.
P.S.
The bill details come from the committee analysis for the July 1, 2026 hearing (as amended June 11). I couldn't confirm what happened to SB 1106 afterward, so check leginfo before quoting me. The store details are from its pages on November 4, 2026, and they change often. Everything under "Where I'd start" is a proposal, not a feature.