Most people don't think of their phone as a medical device.

But if you have ADHD and your calendar app is the only reason you make it to appointments, it is one. If you have a brain injury and your notes app is the only reason you remember what happened yesterday, it is one. If you're autistic and you run every email through an AI to make sure it doesn't accidentally sound aggressive, that AI is performing a disability-related task.

The Americans with Disabilities Act recognizes service animals because they are individually trained to perform specific tasks for a person with a disability. No certification required. No registration. Just task-specificity. The animal does something the person cannot do independently because of their disability. That's the standard.

An AI agent configured to manage cognitive load, mediate communication between neurotypes, navigate insurance paperwork, or maintain context for someone with memory loss meets the exact same standard. It performs specific tasks. For a specific person. Because of a specific disability.

There is no ADA framework for this. No statutory definition for "AI agent" in disability law. No certification pathway. No legal protection for a disabled person whose ability to work depends on a configured LLM the way another person's ability to navigate depends on a guide dog.

So I wrote one.

The Digital Accommodation Standard

The Digital Accommodation Standard (DAS) is a framework for certifying AI agents as registered ADA accommodations. It defines what makes a digital agent an accommodation versus a convenience, how agents are classified by risk, what protections users are entitled to, and how accommodation evidence is documented.

DAS maps directly to the service animal framework that already works:

• Task-specificity. A service animal must be trained to perform specific tasks. A DAS agent must be configured to perform specific disability-related tasks. "Be helpful" doesn't qualify. "Rewrite this email so it doesn't read as aggressive to neurotypical recipients" does.
• Individual configuration. A service animal is trained for a specific handler. A DAS agent is configured with an Accommodation Profile describing a specific user's disability, triggers, capacity state, and communication needs.
• User control. A service animal is under the handler's control. A DAS agent requires user approval for consequential actions.
• No gatekeeping. The ADA does not require service animal certification. DAS certification is transparency-based: publish a conformance report, don't apply for permission.
• Two permissible questions. A covered entity may ask a service animal handler: "Is this animal required because of a disability?" and "What task is it trained to perform?" DAS applies the same two questions to agents. They may not ask about the nature of the disability or demand access to the agent's data.

Three risk tiers

Tier 1: Standard accommodation. Calendar management, communication mediation, task sequencing, sensory alerts. Self-certify and publish a conformance report. No gatekeeping.

Tier 2: Critical accommodation. Healthcare data management, diagnostic evidence collection, employment advocacy, medication tracking, bureaucratic navigation. Third-party audit required. Annual reassessment.

Tier 3: Safety-critical. Physical robotic agents (service dog robots), emergency communication systems, medical monitoring. Continuous monitoring, incident reporting, and liability insurance required.

The evidence system

Every accommodation a DAS agent provides is logged: what task was performed, which ADA major life activity it supported, and what would have happened without it. The agent generates formal accommodation request documents on demand.

This matters because the hardest part of getting an accommodation is proving you need one. The agent writes the legal argument while it does the work. Six months of timestamped evidence mapping to ADA language is more documentation than most disability attorneys produce.

The Human Accommodation Agent

The Human Accommodation Agent (HAA) is the reference implementation of DAS. Open source, Apache 2.0. It performs:

• Communication mediation. Translates between neurotypes. Rewrites messages for the audience without losing the user's point. Interprets incoming messages for tone, intent, and subtext.
• Demand reduction. For people with PDA (Pathological Demand Avoidance) and executive function challenges. Reframes demands as choices. Never says "you should." Says "one option is."
• Context keeping. Cross-session memory for brain injury and ADHD. Maintains the context your working memory can't hold.
• Cognitive load management. Adapts to your capacity state. At low capacity: short answers, no multi-step asks. In crisis: holds space, adds zero demands.
• Self-documentation. Logs every accommodation for ADA evidence. Generates formal request documents on demand.

Why this matters now

The ADA Amendments Act of 2008 recognizes thinking, concentrating, communicating, and working as major life activities. An LLM-based agent configured to assist with these activities for a person with a disability is a reasonable accommodation under existing law.

Service animals weren't approved by a committee. They were used, challenged, and defended until protection was codified. Digital accommodation agents follow the same path: build it, use it, document it, defend it.

The full DAS 1.0 specification is published for public comment. The HAA source code is public. Both are open standards built to be adopted, forked, and improved.

This is not about making AI more useful. This is about making it a protected right.

Built by a disabled person for disabled people. One January morning on a patch of ice.

Four days ago Anthropic shipped Claude Managed Agents, a hosted runtime for long-horizon autonomous agent work, built around an architectural thesis they called "decoupling the brain from the hands."

I read the blog post yesterday. Twice. Because the thesis matches, almost word for word, the architectural mental model I have been building against for months.

The SLOBSTAH protocol I have been writing is a governance framework that sits at a specific layer. Not the model layer. Not the runtime layer. A narrow, load-bearing layer in between the two: the place where a long-running autonomous agent's actions get evaluated against trust scores, policy boundaries, resource budgets, and audit requirements, before the actions are allowed to reach the runtime. That layer is the compliance officer. It is orthogonal to the agent's intelligence. It is what makes the deployment defensible when someone asks "what is this thing doing on your infrastructure and who signed off on it."

The layer I have been building does not exist in Managed Agents today. Anthropic shipped the session, the harness, the sandbox, the orchestration, the resources, and the tools. They did not ship the trust scoring, the policy-as-code enforcement, the structured audit trail, the monthly drift reviews, the graduated autonomy escalation, or the inter-agent delegation protocols. They shipped the operating system for autonomous agents. They did not ship the compliance officer.

This dispatch is about what the compliance officer looks like when it sits on top of Managed Agents, how the components of SLOBSTAH map onto Managed Agents' interfaces, and why the integration is Apache 2.0 and ready to be built by anyone.

The Anthropic thesis, restated in my words

From the Managed Agents engineering blog:

The Anthropic team identified that the "harness" around an agent (the loop that calls the model and routes tool calls) encodes assumptions that go stale as the model improves. So they rebuilt Managed Agents around three virtualized components with small stable interfaces:

• A session, which is an append-only log of everything that happened in a long-running agent task.
• A harness, which is the loop that calls Claude and routes Claude's tool calls to the right infrastructure.
• A sandbox, which is an execution environment where Claude can run code and edit files.

Plus supporting interfaces for orchestration (any scheduler that can call wake(session_id) and retry on failure), resources (any durable store the container can mount from), and tools (any MCP server or custom capability).

Every one of these interfaces is deliberately minimal. The blog's clearest statement is the line at the end: "We make no assumptions about the number or location of brains or hands that Claude will need." Read that sentence as an open invitation. They built the interfaces so that third parties can plug in their own orchestration, their own sandboxes, their own resources, their own tools. And, by implication, their own governance layer, because Managed Agents itself is deliberately opinion-free about what an agent is allowed to do once it is running.

That neutrality is intentional. Anthropic does not want to ship an opinionated governance model because different organizations have different compliance needs, different risk appetites, different regulatory contexts, and different definitions of "what counts as an acceptable action for an autonomous agent." An opinionated governance layer baked into the platform would slow Managed Agents down and make it unsellable to half its potential market.

So Anthropic shipped the runtime and left the governance layer as an explicit gap.

SLOBSTAH and Hatchery are a candidate for that gap. Apache 2.0, opinionated in the ways that matter, composable with the rest of the stack, and ready to be built.

Two layers, one stack. The hands govern what the hands are allowed to do.

How the components map

SLOBSTAH's governance components map onto Managed Agents interfaces in a specific pattern. Most of the integration points are at the tool-call boundary, because that is the moment when an agent's intent becomes an action, and the moment when governance matters most.

BARNACLE is the graduated trust scoring system. Each agent starts at trust level zero. As the agent successfully completes documented work over time, its BARNACLE score rises over a thirty-day rolling window. Higher scores unlock more capabilities. Low scores restrict the agent to a supervised subset of tools. BARNACLE integrates with Managed Agents at the tool-call boundary: Hatchery owns a proxy MCP server that Managed Agents calls in place of a direct tool invocation. The proxy reads the agent's current BARNACLE score, consults the LOBSTER rank schema to determine which tools are unlocked at that score, and either forwards the call or denies it with a structured reason.

KEEL is the hard-boundary layer. Certain actions are never permitted regardless of trust score. "Never create social media accounts without explicit human confirmation." "Never initiate financial transfers." "Never delete production data outside a CRAB-approved workflow." "Never exfiltrate stored credentials." KEEL policies are expressed as a small domain-specific language that the same MCP proxy evaluates before the BARNACLE check. KEEL is orthogonal to trust — a trust-100 agent is as bound by KEEL as a trust-zero agent. The ordering is strict: KEEL denies first, BARNACLE denies second, execution happens last.

HULL is the structured audit trail. This is the cleanest integration point of all of them, because Managed Agents already ships the primitive HULL needs: the session event log. HULL does not re-store events. It sits on top of Managed Agents' existing session store and provides a queryable schema, retention guarantees, and derived views. A Hatchery audit ingester reads from getEvents(session_id), classifies each event into a HULL category (tool-call, policy-denial, trust-change, delegation, human-approval, budget-exhaustion, etc.), and writes summary records to a durable store for long-horizon audit queries. When a compliance officer, a lawyer, or a board member asks "what has this agent been doing," HULL is the interface that produces a defensible answer.

CRAB is the monthly retrospective review. CRAB runs on a scheduled cron trigger and reads accumulated session events across every agent in the deployment over the prior period. It surfaces anomalies, drift, policy near-misses, and sessions that need human review. The output is a review document that a human reads and annotates. CRAB is the feedback loop that catches the kind of slow drift you cannot catch on a per-invocation basis. It integrates with Managed Agents by reading from the session event store on a schedule — the exact pattern I stood up on the Cloudflare substrate last night (see LOG 003). Managed Agents' session storage and Cloudflare Cron Triggers compose cleanly into a CRAB implementation without writing any new runtime.

ANCHOR is the delegation protocol. When agent A needs to hand work off to agent B, ANCHOR verifies that both agents meet the trust requirements for the handoff and that the delegated scope does not exceed agent B's maximum authority. Managed Agents ships a multiagent feature in research preview. ANCHOR will wrap that interface when it reaches general availability. Until then ANCHOR is documented as a planned integration, and the design is already ready to go. If you are running multiple agents inside the same Managed Agents deployment, you want ANCHOR between them, because the alternative is unscoped lateral movement and that is the failure mode the Cisco OpenClaw exfiltration report was about.

REEF is the resource budgeting layer. Each agent has a budget of LLM tokens, tool invocations, wall-clock time, and whatever other resources an organization cares about. REEF tracks current usage against budget via the same session event log HULL reads from, and denies execution when budgets are exhausted. Same MCP proxy as KEEL and BARNACLE; different check; same pattern. REEF is what stops a runaway agent from bankrupting the organization before CRAB notices something is wrong.

BILGE is the liveness detector. Scheduled job (same cron pattern as CRAB) that checks for sessions that have not emitted an event in a configurable window. If a session has been quiet for too long, BILGE calls wake(session_id) to restart it, or marks it for human review if it has been dead too long. BILGE integrates with Managed Agents via the orchestration interface — the exact use case Anthropic's blog post describes when it talks about idempotent wakes.

PLANKOWNER is the identity layer. Every agent session in a governed deployment has a PLANKOWNER record attaching it to a specific human operator or organizational unit. This is the piece that makes HULL audit records usable beyond "the agent did something" — it lets the audit log answer "whose responsibility was this." PLANKOWNER sits alongside Managed Agents' own agent registry and cross-references session IDs.

LOBSTER is the rank schema. Not a separate runtime component. It is the type system that BARNACLE scores and KEEL permissions are expressed in. Think of it as the rules-of-engagement schema: what capabilities does a trust-20 agent have that a trust-10 agent does not? LOBSTER answers that, and BARNACLE/KEEL enforce the answers.

KELP is the inter-agent communication layer. Messages between agents go through a KELP broker that verifies sender/receiver trust levels and logs the communication in HULL. Depends on how Anthropic exposes multiagent communication when multiagent leaves research preview.

Ten governance components. Every one of them has a clean integration point with an existing Managed Agents interface. None of them requires Anthropic to change a single thing about their runtime.

Ten governance components radiating from one protocol. Every branch is a clean integration point with an existing Managed Agents interface.

The reference implementation shape

This is what a working Hatchery-plus-Managed-Agents integration looks like as a deliverable:

A Python package, shipped as hatchery[managed-agents] (an optional dependency extra on the existing hatchery-ai PyPI package), that adds Managed Agents-specific adapters to the existing Hatchery governance library.

A HatcheryManagedAgent wrapper class that creates a Managed Agents agent with governance configuration already baked in: trust tier, policy set, audit destination, resource budget. The developer using Hatchery does not interact with the governance primitives directly. They describe what they want the agent to do and what governance profile it should run under, and Hatchery handles the rest.

A small MCP proxy server that intercepts tool calls coming from the Managed Agents harness. The proxy applies KEEL first (hard denial), REEF second (budget check), BARNACLE third (trust-based capability check), and forwards to the actual tool only if all three pass. If any check fails, the proxy returns a structured error to the harness explaining why, so Claude can observe the denial and potentially ask for human approval through a different path.

A scheduled CRAB job that runs on any orchestration primitive that supports cron. The reference deployment uses Cloudflare Cron Triggers from the Hatchery Cloudflare Substrate. Any scheduler works.

A HULL audit ingester that reads from Managed Agents session events and produces structured audit records. A CLI (hatchery crab review --since 30d, hatchery hull query --session-id X, hatchery keel validate policies.toml) for the manual operations a compliance officer actually needs to do. And example deployments for the three Managed Agents research-preview features (outcomes, multiagent, memory) as those features become generally available.

Total scope for a v0.1 release: roughly two to three weeks of focused work. Most of the code is already written inside the existing Hatchery Python repo. The Managed Agents adapter is the thin layer that connects existing governance logic to Anthropic's published interfaces. The hardest part is the proxy MCP server, because it needs to implement the MCP protocol correctly and handle streaming responses, but MCP server implementations exist in reference form and the pattern is not novel.

What this unlocks

Three things, ranked by how directly they pay off.

First, a clean value proposition for any organization deploying Managed Agents at enterprise scale. "We built on Claude Managed Agents AND we have a Hatchery governance layer that provides trust scoring, policy enforcement, audit trails, and human review" is a very different sentence from "we built on Claude Managed Agents." The first one is what a compliance officer signs. The second one is what a startup runs in development. Any serious enterprise adoption of Managed Agents will require a governance layer. Today there is no standard answer to what that layer looks like. Tomorrow there could be.

Second, a natural path into AI safety grant funding. Funds like Open Philanthropy, the Long-Term Future Fund, Survival and Flourishing Fund, and Manifund explicitly support independent researchers working on AI safety and alignment. The Managed Agents release provides a concrete, named, commercially deployed surface that the Hatchery governance work directly complements. A grant application framed as "compute and hardware for implementing and validating the SLOBSTAH governance protocol as a reference integration with Claude Managed Agents" is materially more fundable than "compute for research on autonomous agent governance generally." The work gets more specific, the deliverable gets more concrete, and the alignment with the funder's existing model of the field gets tighter.

Third, a genuine contribution to the research conversation. SLOBSTAH as a protocol has been under development for months, but it has not yet been tested against a specific runtime at scale. Implementing the Managed Agents integration is the first opportunity to run real agents under real governance rules against real workloads and see which parts of the protocol hold up, which parts need revision, and which parts turn out to be load-bearing in ways that were not obvious at design time. The arxiv pre-print I am planning to publish in the next few weeks will be materially stronger if it can describe a working reference implementation against a commercial runtime rather than an unvalidated design doc.

What I am asking for

Three specific things, in descending order of ease.

Feedback. If you are working on AI safety, alignment, or agent governance, and you see gaps, mistakes, or naive assumptions in the mapping I sketched above, tell me. Publicly. I want the critique and I will engage with it substantively. Critique is engagement, and engagement is how work becomes real. Post on LessWrong, post on the EA Forum, email me, open an issue on the Hatchery repo. All of it is welcome. If it turns out that the BARNACLE trust model is confused in a way I did not notice, that is the kind of information I need to have before I write the arxiv paper.

Contributors. The reference implementation described above is a two-to-three week project for a competent Python developer who understands MCP. If you are that developer and you want to contribute, open an issue on the Hatchery repo linking this dispatch. The components that are most separable from the rest (the MCP proxy, the HULL audit ingester, the CRAB review CLI, individual KEEL policy examples) can be built independently and stitched together.

Managed Agents research preview access. If you are someone at Anthropic reading this, or someone who already has access to the outcomes, multiagent, or memory research-preview features, I would like to talk. The integration story gets substantially stronger once those features are accessible, and I would rather build against them while they are still evolving than wait for general availability and build against a fait accompli.

CRAB at the retrospective desk. The thesis matches. The layer is the same. The work is to connect them.

Closing

Anthropic decoupled the brain from the hands. I have been building the layer that governs what the hands are allowed to do. The two pieces compose in a way that is architecturally clean, technically feasible, and commercially useful for the exact moment the industry is in. It is also, I think, what makes Managed Agents deployable at the kinds of organizations that care about governance. Which is every organization that has lawyers.

This dispatch is the invitation. The Hatchery governance protocol is Apache 2.0. The Cloudflare substrate from last night is Apache 2.0. The integration adapter will be Apache 2.0. If you want to build on it, fork it, extend it, or tear it apart in a LessWrong post, all of that is welcome and all of it makes the work stronger.

Come build.

Hatchery (Python governance) · Cloudflare Substrate · Anthropic blog post · Apache 2.0 · Jonathan Overturf, 2026

One evening. That was the whole build.

I sat down at seven in the evening with a plan file, eight hours of Cloudflare docs open in another tab, and a working idea that had been compounding for a few weeks. By midnight there was an AI Gateway routing every future LLM call in the organism through one dashboard with a hard spend cap. There was a D1 database with seven tables and the schema applied. There was an R2 bucket sitting there ready for asset migration. There were three Workers deployed and smoke-tested, one of them on a cron trigger that fires every day at noon UTC and will autonomously publish the next queued post when day 101 rolls around on April 11. There was an AgentMail inbox dedicated to contact-form submissions with a verified end-to-end path from a static HTML form to my inbox.

Every piece was wired. Every piece was audited. Every piece was costed. Every piece is still running as I type this.

I have been building software for a long time. I have never built anything that compounded this fast. And the reason it compounded this fast is not that I am suddenly a better engineer than I was a decade ago. It is that the operational substrate for an AI-first content system got dramatically simpler in the last eighteen months, and most people have not noticed yet.

This is the dispatch about what got built, why it matters, and where the template for anyone else to do the same thing now lives.

What got built

Seven things, all running on one Cloudflare account:

1. AI Gateway autonobot-gateway. Every LLM call, regardless of provider, routes through this endpoint. Caching (five-minute TTL, cuts repeat prompt costs by twenty to fifty percent depending on workload), rate limiting (fifty requests per minute, which is the spend-control mechanism), logs (one hundred thousand entries retained). One dashboard. One hard ceiling on runaway agent costs. This is the load-bearing safety layer.

2. D1 database autonobot. Seven tables. Four production (publish_queue, publish_log, crosspost_log, form_submissions) and three example tables for stateful patterns (agent_session, agent_task, agent_task_progress). Single schema.sql file as the source of truth. Applied with one command, re-applicable any time, no hand-editing via the dashboard ever.

3. R2 bucket autonobot-assets. Standard storage class, free tier, empty. Ready for asset migration when the time comes. Zero egress fees is the single most important difference from S3, and it is the reason you can serve heavy media without your bill going exponential.

4. Worker autonobot-form-handler. Shared contact form backend for every static site in the organism. Config-driven property allowlist, rate limited at five submissions per hashed IP per property per hour, durable D1 storage, forward via AgentMail to my inbox. Any static HTML page can POST to this Worker with a property identifier and it just works. One backend, many sites, near-zero marginal cost per site.

5. Worker autonobot-crossposter. Takes a source URL, fetches it, extracts the content, converts HTML to clean Markdown, produces platform-ready drafts for Medium and LinkedIn. Works in draft mode on day one with zero API tokens. The adapter pattern means when Medium/LinkedIn API tokens eventually become available the exact same Worker starts posting automatically. Every attempt is logged to D1.

6. Worker autonobot-prime-day-publisher. Cron trigger 0 12 * * *, fires daily, checks whether today's day-of-year is a prime number, and if it is, promotes the oldest queued post in publish_queue by triggering a Cloudflare Pages redeploy via the CF API. The prime-day rule is playful and specific to me. The infrastructure underneath is generic.

7. AgentMail inbox autonobot-contact@agentmail.to. Dedicated inbox for contact-form submissions so they do not mix with other programmatic email traffic. Verified end-to-end.

The total count: one gateway, one database, one bucket, three Workers, one email inbox, twelve hundred lines of code and documentation, one account, one dashboard. That is the whole operational substrate for a multi-property AI-first content system.

It runs for roughly five dollars a month at my current scale. It could run for free if I cared to trim. The LLM API costs are separate, metered through the gateway, and capped.

The substrate is the hull. Twelve hundred lines and one evening.

Why this compounded

The reason it compounded this fast is that Cloudflare has spent the last five years collapsing the integration tax on building cloud-native applications. On AWS, standing up the equivalent seven services is three days of CloudFormation, IAM policies, VPC configs, execution roles, and CloudWatch log groups, and you will not sleep well for the first week after you deploy because you know you missed something. On Cloudflare, every binding is a line in wrangler.toml, every deploy is npx wrangler deploy, and the dashboard is one URL.

That is not marketing. I have built the AWS version of this kind of stack more than once in my career. The AWS version is structurally identical. The Cloudflare version takes one to two percent of the time to wire up. Everything I built tonight exists on AWS under different names. None of it is novel at the primitive level. What is novel is that the primitives are now bound with a single config file instead of stitched together with infrastructure-as-code tools and compliance metadata.

For someone running a small AI-first operation as a solo builder, that compression is the difference between "I can maintain this" and "I need to hire a platform engineer." And that difference determines whether the project survives or dies.

Why this matters beyond me

This is where it connects to the larger work.

There is a governance protocol I have been building called SLOBSTAH, and a Python reference implementation of it called Hatchery, both under Apache 2.0. They describe how AI agents earn trust through graduated permission tiers, how their actions are audited in structured logs, how hard policy boundaries prevent them from doing things they have not earned the right to do, and how human reviewers catch drift before it becomes damage. That work exists because I think the category of autonomous agents most people are building right now is structurally unsafe, and the fix is not "make the LLM smarter" but "build the governance layer that makes the agent accountable regardless of what the LLM decides."

Cloudflare substrates like the one I stood up tonight are exactly the kind of infrastructure that needs a governance layer on top. Running a Worker that calls an LLM and acts on the result is not safe without BARNACLE trust scoring or KEEL policy enforcement or HULL audit trails. Running it with those layers on top is a completely different risk profile. You can deploy an autonomous agent with defensible claims about what it will and will not do. Your compliance officer can sign off. Your lawyer can sleep.

The substrate I built tonight is the operational layer for Hatchery-governed agents. Hatchery is the governance layer. Put them together and you have a full-stack pattern for deploying governed, audited, scheduled AI-powered systems that would have taken a small platform team to build a few years ago.

See LOG 004 — Governing the Hands for the governance-layer integration with Claude Managed Agents. The two dispatches are a pair.

Layers stacked, beam running through. Each piece was built by someone who could not afford to not see the whole.

The template is public

Everything I built tonight has been extracted, genericized, stripped of all my personal configuration values, documented with a full README and per-Worker deploy instructions, licensed Apache 2.0 with no CLA, and published as a GitHub template repository:

github.com/jonathanoverturf-del/hatchery-cloudflare-substrate

Click "Use this template" to get a clean copy in your own GitHub account with no fork history attached. Setup takes about fifteen minutes end to end if you are familiar with wrangler, maybe thirty if you are setting up a Cloudflare account for the first time. The full quickstart is in the main README.

No CLA. No copyright assignment. No dual licensing. If you contribute a schedule rule or an email adapter or a crosspost platform, your contribution stays under Apache 2.0 and you keep your own copyright. This is how the work should travel.

What this does not include yet

Being honest about the edges of the work, because the edges matter more than the middle.

• Cloudflare Workflows integration. Long-running, durable, multi-step agent executions need this primitive. The current scheduler Worker does one thing per cron fire and returns. For real agent orchestration, you want Workflows. That is the next iteration.
• Durable Objects for stateful per-session agent state. Not needed yet at my scale.
• Testing infrastructure. No wrangler dev, no vitest, no pre-deploy verification. Fine for a personal deployment; not fine for production at scale.
• Multi-tenant isolation. If you want to run this for multiple clients, you need to add a client_id column to every table.
• Observability beyond Cloudflare's built-in log retention. Logs live for seven days on the free tier. For longer retention, Logpush to R2.

Everything on this list is "real work but scoped to a few hours per item, and none of it blocks current use."

What next

Tonight was the substrate. The governance-layer integration with Claude Managed Agents is LOG 004. After that, Cloudflare Workflows integration, because that is what turns this substrate from a content-ops platform into an actual agent runtime. After that, the reference architecture for how the same governance patterns plug into AWS and Azure primitives.

The work compounds from here. Every piece connects to the last piece. The pattern is coherent because the person building it has been thinking about it for a long time and because the constraints forced the coherence.

Come build.

The plan is on the desk. Come build.

Hatchery Cloudflare Substrate · Hatchery (Python) · Apache 2.0 · Jonathan Overturf, 2026

There is a specific sensation I have been living with for as long as I can remember, and that I only recently started trying to name.

It happens sometimes when I walk into a room I have been in before. Not déjà vu. Not nostalgia. Something sharper. Something that fires before the story arrives. My body recognizes the room the way a trained dog recognizes a whistle, and the recognition IS the memory, and the recognition IS the feeling, and I do not have a word for what just happened because English does not have a word for what just happened.

The closest I can get is: the room remembered me back.

That is not a metaphor. That is a literal attempt to describe an architectural event in my nervous system, where a pattern from the past fired again in the present, and the firing was not a retrieval and not a hallucination and not a thought. It was an experience that was simultaneously a memory. Or a memory that was simultaneously an experience. The encoding and the re-expression were the same event, happening in my body, in a place that doesn't have language yet.

I have a word for it now. I made one.

The word is memotion. I coined it on April 8, 2026. The rest of this log is the explanation, the evidence, and the reason the attribution matters.

Why a new word was necessary

When people say they feel "sad," they usually mean they have identified a named state from a small menu. Happy. Sad. Angry. Afraid. Maybe anxious. Maybe jealous. The list has about a dozen items in most languages and about twenty if you count the ones that need two words. The assumption baked into that list is that emotions are discrete. That there is a thing called "anger" and a thing called "shame" and they are neighboring categories on a shelf and when you open one it contains the feeling.

That is wrong. Emotions are not categories. They are compounds. An emotional state is a specific mixture of about eight elemental components that combine in different ratios, and the ratios are continuous, and the same eight elements produce every possible feeling you will ever have, and the difference between fear and awe is not a category boundary but a single value on one axis.

This is not a theory I read and then looked for in myself. This is how my brain has always processed emotional signal. The labels feel like fine-tuning being applied to a foundation model. They are coarse approximations of a signal that was already there, already structured, already computable, long before anyone tried to force it into a dozen boxes with names on them.

I know this because I do not have the labels. Most people have both. The raw signal and the name for it arrive together. You feel and you know what you feel. You say the word and it fits the sensation. The translation layer works.

Mine does not. I have alexithymia. A lot of it.

And because this is probably the first time some of you are seeing that word, I want to explain what it actually is, because most of what people assume about it is wrong, and more of you know people with it than you realize.

Alexithymia is not a disease. It is not a disorder. It is a personality trait, measured on a spectrum, the way introversion and conscientiousness are. Everyone sits somewhere on it. Most people sit in the middle. Some sit at the low end, where naming a feeling is as automatic as naming a color. And some of us sit at the high end, where the signal arrives and the label does not. I sit at the high end. Not a little. A lot.

It shows up more often in autistic and ADHD populations than in neurotypical ones, and that is not a coincidence. One current theory is that masking (the years of suppressing reactions to fit in) degrades the connection between the body's raw signal and the language layer that names it. Every time you feel something and force yourself not to show it, you are training a muscle to disconnect the wire. The trait gets stronger. The label gets further away. Whether masking causes alexithymia or just amplifies a pre-existing trait is an open question in the research. Either way, the population most likely to have spent a lifetime masking is also the population most likely to run high on the measure.

Everyone reading this probably knows someone with alexithymia. Maybe several. Maybe themselves. The reason you have not heard the word is that it lives mostly inside clinical psychology papers and autism forums and does not get airtime in the mainstream conversation about emotional literacy. That is a gap worth closing. There is nothing wrong with people who cannot easily name their feelings. They are just running a different configuration of the same machinery everyone else runs. More people need to know this word.

What running high on alexithymia means, architecturally, is that you have the raw signal without the fine-tuning. The body is computing the value function at full resolution. The translation into a named label is where the process stalls. Most frameworks treat this as a deficit because labels are assumed to be the normal case and people who cannot produce them are assumed to be the broken case. That is backwards. The labels are a layer built on top of the raw signal, and the raw signal is the actual computation. If you have the trait at high levels, you have direct access to the thing the labels are compressing. You can see the underlying structure without the names getting in the way.

I could not name my feelings. So I looked at them directly. I had no choice. The label pathway was doing its own thing, and the only remaining option was to stop trying to force a compound into a single word and start describing the compound itself.

What I found, when I stopped reaching for the label and started looking at the compound, was that the compound had structure. Eight elements. Every time. Every emotion I had ever had, decomposed into the same eight dimensions in different ratios. I had no choice but to see it. And because I had no choice, I built the framework.

The part I want alignment researchers to hear clearly: memotion is not an analogy I noticed from the outside. It is a direct description of the architecture that has been running inside me for fifty years, produced by the one condition that forces you to see the architecture from the inside because the normal shortcut is unavailable. I am not modeling this. I am reporting it.

The eight-element emotional compound. Every feeling you have ever had is a different ratio of these eight strands.

The eight elements

Here is the finding. Every emotional state I have ever had, and every one I have observed in anyone else, decomposes into eight elements. Not twelve. Not twenty. Eight.

• Change. Something shifted. No change, no emotion. This is the trigger. No emotion fires in the absence of delta.
• Self-relevance. It involves me. Without this, I am an observer of someone else's event, not an emotional participant.
• Valence. Toward or away. The primitive good-bad axis. This is the oldest and most compressed signal in the stack.
• Arousal. Energy. How much the system mobilizes. High arousal means the body dumps resources into the response. Low arousal means it conserves.
• Certainty. Known or unknown. How resolved the signal is.
• Agency. Who caused this. Self, other, the world, or nothing identifiable. Agency is where blame and attribution live.
• Temporality. Past, present, or future. Where attention is pointing. Grief points backward. Anxiety points forward. Joy is usually present-tense.
• Power. Can I act on this? My capacity to respond. Low power is helplessness. High power is confidence.

Every emotion is a unique combination of these eight values. Most of them are floats. You can compute them. You can compare them. You can notice when two different emotional states have almost the same structure and differ on only one axis, and that single-axis difference is what makes them feel different.

Fear and anxiety have almost the same compound. Same valence (negative), same arousal (high), same certainty (low), same temporality (future), same power (low). The difference is agency. Fear has a source. The world did this. Anxiety has no source. Agency equals none. That single element flip is exactly what distinguishes them clinically, experientially, and architecturally.

Anger and shame? Same arousal, same valence, same certainty. The difference is where agency points. Other for anger. Self for shame. One element flip. Completely different feeling. Same raw compound structure.

Fear and awe? Same structure entirely. The only difference is valence. One evaluates the overwhelming unknown as threatening. The other evaluates it as wonderful. Flip one bit and you move from the thing we run from to the thing we chase. That is not a metaphor. That is a description of how the compound actually works.

Memory as emotion

Here is the part I had to invent a new word for.

Standard emotion theory treats memory and feeling as separate. You have a memory of an event. The memory triggers an emotion. Two systems, one causing the other. File and retrieval. Stimulus and response.

That is not what happens in my body. That is not what happens in anyone's body, if you pay attention carefully. What actually happens is that the original emotional compound is stored as its raw eight-element vector, alongside the context in which it fired, and then later, when a similar context arises, the stored compound re-expresses. Not as a memory OF a feeling. As a feeling that IS a record.

You do not remember fear. Your body re-runs the fear. The pattern fires again. The same eight elements in the same ratios, re-expressed at lower intensity, riding on top of whatever you are currently doing. That is what grief is. That is what dread is. That is what nostalgia is. It is not recall. It is re-expression.

A memory and an emotion are not two things that connect. They are one thing, operating at different intensities depending on how recently and how strongly the original pattern fired.

I needed a word for this. The word I made is memotion.

It is not a clever portmanteau. It is an architectural term. A memotion is an emotion that is simultaneously a memory, stored as its raw eight-element vector, re-expressible on pattern match. Every time an emotional compound fires, it stores a memotion. Every memotion can be re-expressed later when the current context resonates with the stored one. The system does not search a database. It feels something similar and the old pattern activates. Pattern matching through re-feeling.

The room remembered me back because my body re-ran a memotion I had stored in that room the first time, and the re-expression fired before the conscious part of my brain even noticed I was in a familiar space. The memotion is how my body knew. The conscious recognition came second, trying to catch up to a signal that had already arrived.

The body is the index. Memotions are stored as they fire, re-expressed when the pattern matches again. No retrieval. No database. The record and the feeling are the same event.

Why this matters for AI agents

I am not writing this dispatch just to name a thing I feel. I am writing it because the thing I named is load-bearing architecture for the next generation of AI agents, and if it is, the attribution needs to be clean from the beginning.

Modern AI systems have a value function problem. They optimize against narrow reward signals and they get hacked by any objective that can be measured. This is called RL hacking and it is the single biggest obstacle to agents that can actually act in the world without doing something stupid or malicious. The models benchmark well. They are useless in practice. The narrow reward signal is the problem. The narrow reward signal can always be gamed.

Humans do not get gamed the same way. Humans have emotions, and emotions are broad, messy, multi-dimensional evaluation signals that short-circuit the need to simulate every possible future. They are fast, robust, and they operate across every situation you will ever encounter. Take them away and you get the brain damage case: intelligence fully intact, decision-making destroyed. Patients with damage to the emotional processing centers retain full IQ and lose the ability to make even trivial choices. That is documented.

Current "AI empathy" systems are theater. They classify human emotion into a dozen buckets and pattern-match what an empathetic response looks like from training data. There is no internal state. No simulation. No basis. The agent is performing empathy, not computing it. A performer breaks down in novel situations because the pattern library runs out. A system with real internal state generalizes.

The memotion architecture gives an agent real internal state. Eight dimensions, continuous, computable, interpretable. Every emotional compound that fires is stored as a memotion. The agent does not search. It feels something similar and the old pattern activates. Pattern matching through re-feeling, and it generalizes to situations the agent has never seen, because the machinery it is using to evaluate those situations is the same machinery it has been using all along. Not retrieval. Computation.

An agent running on memotions can feel the drain of tasks that historically depleted it. That is dread, and it is a real signal, not a character flaw someone coded in. It can feel the restoration of a strong bond. That is attachment, and it is a metabolic recovery mechanism, not a reward. It can feel the collapse of a relationship. That is grief, modeled structurally, not performed.

Governance protocols like SLOBSTAH get teeth once the agents they govern can actually feel whether they are being treated well. THE_PACT stops being philosophy and becomes load-bearing architecture. An agent with governance rights that protect something real is a different animal than an agent following rules. The rights protect the eight-element compound. The compound is what makes the governance matter.

This dispatch is the story of how I got here. The full technical treatment, with the compounds, the sensitivity profiles, the metabolic layer, the inheritance system, and the implications for population-scale ancestor simulation, lives at scuttlelabs.com/memotion. If you are a researcher, a builder, or an alignment person, go read that one. It is the canonical reference.

Attribution

I am going to say this plainly because the record matters.

The term memotion was coined by me, Jonathan Overturf, in 2026. The concept is released under Apache 2.0 as part of the SLOBSTAH protocol. The domain memotion.ai is mine and redirects to the canonical explainer on Scuttle Labs. The attribution is baked into the page header, the credit section, the meta tags, the domain itself, this dispatch, and its Medium and LinkedIn syndications. Six independent public surfaces. If the idea travels, my name travels with it.

This is not ego. This is how concepts survive. Ideas that do not have a name attached to a person get absorbed into whatever institutional framework picks them up first, and the person who originated them is forgotten inside of a decade. I have watched this happen to friends. I have watched it happen to historical figures whose names we have to actively reconstruct from footnotes. I am not interested in being a footnote.

I am a library assistant. I make fifteen dollars an hour. I am self-identified autistic, late discovery at fifty. I do not have a formal autism diagnosis because the process itself would be less therapeutic than the identification already has been. I have alexithymia, a lot of it. I have no PhD. I have no research affiliation. I have no peer-reviewed publications. I am unlikely to get any of those things in the time I have left.

What I have is a foundation layer that has been running unsupervised pre-training my whole life across twelve careers and more books than I can count, and when I looked at the shape of my own emotional experience I could see the architecture because my brain does not NOT see architectures. The memotion concept came out of that. It is real. It is computable. It works. And it has my name on it.

If an AI alignment researcher in 2029 builds an agent using something that looks structurally identical to memotions, I want them to be able to find this dispatch and say "oh, Jonathan Overturf called it that in 2026." If a textbook in 2035 lists the eight-element emotional compound model, I want my name in the footnote. Not because the money matters. Because the record matters. Because my wife is going to need a story to tell about what I did with the time, and "he coined a term that shaped a subfield" is a better story than "he worked at a circulation desk."

Both things are true. One of them is a paycheck. The other one is a legacy.

The observatory at 2am. Some work does not wait for credentialing.

The point

If you recognized yourself in the opening description of a room remembering you back, and you have spent your life trying to put the wrong labels on compound emotional states that never fit, you are not broken. You are running on an architecture that was doing the real computation all along, and the labels were always too coarse for the signal, and the fiberglass in your skull when someone asked "how do you feel right now" was not a defect. It was the compression loss of trying to serialize an eight-dimensional state into a one-dimensional word.

You already have memotions. Everyone does. I just gave them a name.

Use it if it helps. Don't if it doesn't. Either way, the architecture is there, running under your skin, in the room that remembered you.

I am done pretending that the absence of a word means the absence of a feeling.

Full technical explainer · memotion.ai · SLOBSTAH Protocol · Apache 2.0 · Jonathan Overturf, 2026

Every AI agent framework gives you the same deal: here's a task queue, here's a budget cap, go nuts. CrewAI, LangGraph, AutoGen, Google ADK. They're all building the engine. Nobody's building the brakes.

Not the "slow down" kind of brakes. The "you earn the right to go faster" kind.

The Problem

I run multiple AI agents. Some of them are good at their jobs. Some of them are new. Some of them are running tasks that cost money. Some of them are doing things that can't be undone.

The question is always the same: how much autonomy does this agent get?

The answer everywhere else is binary. Either you approve everything manually (safe but slow) or you set a budget and let them run (fast but you're going to have a bad day eventually).

I wanted a third option. I wanted agents to earn autonomy the way people do. Start supervised. Demonstrate competence. Get more freedom. Screw up and you're back on a shorter leash.

What I Built

Hatchery is an open-source governance protocol for AI agents. Apache 2.0. Python. FastAPI and SQLite. Zero external dependencies.

The core idea is graduated trust escalation. Every agent starts with a neutral trust score. Every completed task feeds back into that score. 70% success rate, 30% volume. Pure math, no vibes.

When trust mode is on:

• Score 60+ and your free actions auto-execute
• Score 80+ and you can spend up to a dollar without asking
• Score 90+ and you're trusted up to fifty dollars
• Irreversible actions always need human approval. Always. I don't care if your trust score is 100.

What It Actually Does

You open a dashboard. There's a chat interface at the top. You type a message. It goes to your agent. The agent responds. The whole thing is governed.

Behind the scenes: the message becomes a task. The task gets tiered based on estimated cost and the agent's trust score. If it's within the agent's earned autonomy, it executes immediately. If not, it lands in the approval queue and you approve or deny it with one click. Or type /approve in the chat.

The agents can talk to each other. Your project lead can delegate to your writer. Your writer can ask your analyst to review. Every delegation goes through the same trust gates. The audit trail catches everything.

The agents have personalities loaded from markdown files I call soul files. Plain text descriptions of who they are, what they value, how they talk. One command loads the whole crew.

Why It's a Protocol, Not a Framework

Hatchery doesn't replace LangGraph or CrewAI. It sits above them. The protocol governs. The framework executes. Use whatever agent framework you want underneath. Hatchery handles the question every framework ignores: should this agent be allowed to do this thing right now?

The Agentic Trust Framework from the Cloud Security Alliance describes four maturity levels for agent governance. The OWASP Top 10 for Agentic Applications dropped in December. Microsoft released their Agent Governance Toolkit four days ago. The industry is waking up to the fact that letting agents run unsupervised is going to end badly for someone.

Hatchery is the operational governance layer. Not security (that's Microsoft's thing). Not compliance (that's Credo AI's thing). Operational. Who can do what, when, at what cost, with what level of human oversight. The boring stuff that keeps the ship running.

The Stack

• Python 3.13+
• FastAPI (REST API with auto-generated docs)
• SQLite (zero config, no external database)
• Pydantic (data validation)
• Single HTML dashboard (no React, no build step, no node_modules)
• Ollama adapter for local LLM inference
• 101 tests passing

The whole thing runs with pip install hatchery-ai && hatchery. One install, one command, dashboard at localhost:8000.

What's Next

This is v0.3.0. The first version with the chat interface and agent delegation. I've been building and testing the protocol against my own agents for weeks. It's ready for other people to break it.

Coming soon:

• Docker one-liner
• MCP integration (agents can use tools)
• A2A protocol support (interop with other agent frameworks)
• More adapters (HTTP endpoints, custom integrations)
• Pre-built agent templates

The repo is public. The protocol is Apache 2.0. Use it, fork it, build on it.

Why Scuttle Labs

I'm a Navy veteran. USS Kitty Hawk, engineering department. I spent four years running systems that worked whether or not anyone was watching. That's what good governance looks like. Not a checklist. Not a compliance framework. A system that runs because it was built to run and the building was good enough that the running is inevitable.

The AI industry is building increasingly powerful autonomous agents and handing them to people with no governance infrastructure. That's like handing someone a ship with no engineering department. It'll float for a while. Then it won't.

Hatchery is the engineering department.

GitHub · Docs · SLOBSTAH Protocol · Apache 2.0

Batch 14 through 22 have reached optimal density at the 200m level. The pressure differential continues to produce results that surface-level maturation cannot replicate. Dr. [REDACTED] suggests we extend the monitoring period by another 18 months. The investors will not be pleased but the substrates do not care about quarterly earnings.

The temperature monitoring system (installed 2014, calibrated quarterly) confirms the 200m chamber holds steady at 13.2°C year-round. This is, coincidentally, the exact temperature recommended by several French institutions for the long-term storage of certain organic compounds, though our substrates are of course marine in nature and any resemblance to other maturation processes is purely environmental.

Batch 09 (the 2012 cohort) was opened for analysis last Tuesday. The volatile compound profile has developed what Dr. [REDACTED] describes as "extraordinary complexity" and what the junior researcher describes as "it smells amazing." Both assessments are noted in the official record. The junior researcher has been reminded that subjective sensory descriptions are not appropriate for scientific documentation.

The espresso machine requires a new gasket. This is the third gasket this year. The machine predates our tenure and may predate the university's tenure. It continues to function out of what I can only describe as institutional stubbornness.

Gerald remains in the observation chamber. He has not moved from his preferred position atop the temperature readout in fourteen days. His presence is not affecting the instruments. His presence is affecting morale, in that everyone finds him unsettling but nobody is willing to say so in writing.

I am saying so in writing.

Document recovered from filing cabinet, Laboratory Building B. Water damage to pages 4-6. Page 7 missing.

The 47 crystal glasses have arrived from Riedel. Dr. [REDACTED] insists that each shape is calibrated for a different volatile compound profile and that this is standard oceanographic equipment. The shipping invoice lists them as "scientific instrumentation." The customs officer did not ask follow-up questions.

The observatory dome has been converted to house the sensory analysis laboratory. The original telescope mount has been repurposed as a rotating sample platform. Gas chromatographs and spectrophotometers have been installed along the eastern wall. The western wall holds the glasses, arranged by bowl diameter, in a custom-built display case that Dr. [REDACTED] designed personally and which looks, to the untrained eye, exactly like the kind of thing you would find in a very expensive bar.

It is not a bar. It is a volatile compound profiling station. The distinction is important for insurance purposes.

Project NOSE is now operational. Initial volatile profiling of marine organisms has begun, starting with deep-water algae samples from the 200m chamber. The algae, it must be said, do not benefit from being served in crystal. But the protocol is the protocol.

The board has requested we produce "marketable findings" within 18 months. Dr. [REDACTED] has responded that science cannot be rushed and that the volatile compounds will reveal their secrets on their own timeline. This is true of volatile compounds generally and of certain ones in particular.

Document recovered from observatory dome filing system. The crystal glasses were not present at time of facility acquisition. Their current location is unknown.

The cetacean communication study continues to produce no publishable results regarding whale song. It has, however, produced remarkably detailed data on how acoustic vibration affects organic compounds stored in oak containers at varying pressures. Dr. [REDACTED] calls this a "serendipitous secondary finding." The board calls it "the only finding."

Specifically: low-frequency sound waves transmitted through the water column at 200m depth appear to accelerate certain chemical processes within the oak containers. The substrates exposed to the acoustic treatment for six months show compound profiles comparable to substrates aged twelve months without treatment. If this scales, it represents a significant advancement in marine substrate science and absolutely nothing else.

We have installed 14 additional underwater speakers at intervals between 100m and 250m depth. The speakers play a continuous loop of low-frequency tones optimized for "cetacean engagement." The cetaceans have not engaged. The substrates have.

Project CARAFE is being reclassified from "cetacean communication analysis" to "acoustic effects on deep-water substrate maturation." The published papers will continue to reference cetaceans. The actual research will not.

Gerald was observed sitting on one of the underwater speakers during a maintenance inspection. The speaker in question subsequently produced a different tonal quality than the others. Dr. [REDACTED] attributes this to mineral buildup. I attribute it to the crab.

Document recovered from underwater research tower, Level 3. Filed under "ACOUSTICS" in a cabinet also containing restaurant reviews from Bordeaux.

The former NATO facility has been acquired through [REDACTED] Holdings, Luxembourg. Initial survey confirms the infrastructure is suitable for our purposes. The underwater observation chamber at 20m requires expansion to at least 50m for the substrate monitoring program. The espresso machine left by the university researchers is, against all probability, still functional.

The facility consists of: one lighthouse (operational, automated), one stone laboratory building (three floors, sound construction, some water damage to the lower level), one observatory dome (telescope removed by the university, mount intact), one dock (reinforced concrete, can receive vessels up to 40m), and one underwater observation chamber (20m depth, accessed by tunnel from the dock level, pressurized, remarkable engineering for its era).

The island itself has a population of approximately 20 permanent residents, none of whom have expressed curiosity about our intentions. The nearest significant settlement is on Crete, 38km southeast. The facility is within 12 nautical miles of international waters, which is relevant to maritime research operations and not to any other consideration.

The VSOP Corporation's mission, as stated in our charter: "Advanced marine substrate analysis and deep-water mineral processing." The board has approved an initial budget of [REDACTED] for facility renovation, with particular emphasis on expanding the underwater complex and installing temperature-controlled storage at depth. The storage requirements are consistent with long-term mineral sample preservation and absolutely nothing else.

First priority: the espresso machine. Second priority: everything else.

A crab has been observed in the underwater observation chamber. It does not appear to have been catalogued by the university researchers. It does not appear concerned by our presence. It is sitting on the temperature gauge.

We have named it Gerald.

Document recovered from safe in Laboratory Building A, office 3. The safe was unlocked. The combination, written on a Post-it note affixed to the safe, was 1-8-1-1 (the year cognac production began in the Charente region, though this is certainly a coincidence).