I write about and build for Farcaster communities, and there is a failure mode I keep running into. A channel grows past the point where humans can read everything. Someone builds a moderation agent to help. The agent works, the channel relaxes, and six months later the whole arrangement quietly depends on one company's API key, one company's terms of service, and one company's idea of what counts as acceptable content.

Nobody planned that. It just happens, because the easiest way to add intelligence to anything in 2026 is to call a centralized AI API. But for tooling that serves a permissionless social protocol, it produces a contradiction worth taking seriously: the social graph is permissionless by design, and the moderation layer sitting on top of it can be switched off by a single vendor.

This essay is an architecture proposal for fixing that specific contradiction. Not a claim that all AI should run on decentralized compute. Most of it shouldn't. This is about the narrow class of tools where the whole point is that no single party can kill them, and about what it would take to make the AI layer of those tools match the guarantees of the protocol underneath.

The problem, concretely

Take a niche Farcaster channel with a few thousand members. It gets hit with the usual wave: auto-posted casts shilling a token, reply-spam from freshly created accounts, low-effort engagement farming. Volume is high enough that volunteer mods burn out. So the community wires up an agent: new casts flow through a classifier, obvious spam gets flagged or hidden, borderline cases go to a human queue.

The intelligence in that loop is an inference call. Today, the default is to send it to OpenAI, Anthropic, or Google. And here is the before/after that matters:Before:your community's moderation depends on volunteers who burn out.After (centralized):your community's moderation depends on a vendor who can change pricing, change content policy, rate-limit you, or terminate the account. Any of those events, and the channel is undefended overnight, at the vendor's discretion rather than the community's.

That is not a hypothetical class of risk. Providers revise their usage policies regularly; OpenAI, Anthropic, and Google have each done so more than once in the past two years. And moderation is exactly the awkward workload: to classify spam and abuse, you have to send spam and abuse through the API. OpenAI, to its credit, ships a free moderation endpoint built for this job. But its terms around classifying third-party content have shifted and remain ambiguous, and developers running abuse-processing apps have documented opaque account suspensions even after implementing it. The real risk isn't a classification call tripping a filter; it's discretionary enforcement on the account around it. The community that chose a permissionless protocol on purpose, to avoid platform risk, has reintroduced platform risk one layer up, in the tooling.

The failure isn't dramatic. Nothing gets censored in a headline-worthy way. The bot just stops working, and the community's practical ability to govern its own space degrades to whatever manual capacity is left.

One concession before going further, because protocol-literate readers will raise it anyway: Farcaster's own decentralization is a work in progress, not a finished fact. Casts and identity are protocol-level, but channels, the community layer this whole scenario lives in, are still a client-level construct; the official docs are upfront that channel metadata and moderation state live in the Farcaster client, not the protocol. When a bot "hides" a cast today, it does that through the client's API, and the cast itself never leaves the network. So no, decentralizing the AI layer doesn't purify the whole stack. That isn't a hole in the argument. It's the argument. Decentralization is a stack, and each layer gets won or lost separately. The channel layer's gap is native, documented, and openly debated inside the ecosystem. The AI dependency is different: it's being added right now, bot by bot, it sits entirely outside the ecosystem's control, and nobody is debating it. This essay is about not losing a layer nobody is watching.

The architecture

Here is the shape of the fix I'd build. Five components, none of them exotic. Four of them are already how serious communities run automated moderation today: webhooks in, custom agent logic in the middle, moderation endpoints out. The proposal swaps exactly one piece, where the inference runs.1. The client integration.A Farcaster app or bot account watches the channel. New casts, or casts flagged by members, become moderation requests. This part is unchanged from how centralized agents already work.2. The agent orchestrator.An off-chain service that owns the moderation logic: what model to run, what the classification categories are, what confidence threshold triggers what action. The community configures this. Crucially, it's cheap to run because it does no inference itself; it routes.3. The compute router.Instead of one API endpoint, the orchestrator submits inference jobs to decentralized GPU networks like Nosana. On Nosana specifically, you don't pick individual nodes: you post a job to a GPU market, a pool of hosts offering one hardware tier at a fixed price, and the network assigns an available host. The router I'm describing sits a level above that. It chooses which market, and potentially which network, gets the job, based on price, queue depth, and observed latency. The model itself is open-weights, so any host with the right hardware can serve it. No single host, and no single company, is load-bearing.4. The inference nodes.Independent GPU operators run the job and return the classification. From their perspective, it's ordinary paid work; they don't need to know or care that the workload is moderate. And there's no privacy problem in letting untrusted hardware see it: the inputs are public casts, already readable by anyone. Moderating public content is unusually well suited to decentralized compute for exactly that reason.5. The action layer.Results come back to the orchestrator, which acts: hide, flag, allow, or queue for human review.

The operational failure modes have boring answers, which is a good sign for an architecture. A node is slow: the orchestrator times out and resubmits to the next node, the same way any job queue handles a dead worker. A node is offline: the router stops selecting it. The network is congested: moderation is latency-tolerant in the seconds range, unlike chat, which is part of why this use case suits decentralized compute in the first place. And the degraded mode is chosen deliberately: if inference is unavailable, the system fails toward "queue for human review," never toward silent auto-removal. The community's authority is the floor the system falls back on, not a feature bolted on top.

One underrated property: open-weights models make the moderation policy itself inspectable. A community can publish the exact model and prompt it moderates with. Members can disagree with the policy, fork it, or vote to change it. Try that with a closed vendor's classifier.

The part that isn't solved

Every architecture like this has a question it would rather not answer: why should you trust the classification a random GPU operator sends back?

A centralized API answers with reputation and a contract. A decentralized network has to answer differently, and I want to be direct that the honest answer today is "partially."

The naive fix is spot-checking: run high-stakes jobs on two nodes and compare. That helps against random faults, but think about what it does against an adversary. If someone stands up multiple nodes in the network, correlated wrong answers pass the comparison. So you escalate: majority-of-N voting. Now you're paying N times per inference for the sensitive cases, and you've assumed node operators are independent, which the cheapest attack violates first. You can add reputation: nodes accrue trust over time, and audited failures cost them future work. Better, but reputation systems need someone to define and run the audit, and if that's one party, the single point of failure has moved house again, from the API vendor to the reputation oracle. Staking and slashing push the same idea into economic territory: nodes post collateral, provable misbehavior burns it. That's the strongest mechanism on the menu, and it's also the hardest to build, because "this classification was wrong on purpose" is genuinely difficult to prove on-chain for a subjective task like moderation.

I'm spending a third of this essay on the trust gap because I think glossing over it is how decentralized AI proposals discredit themselves. The honest position is this: for spam classification, cheap redundancy plus reputation is probably good enough, because the cost of a wrong answer is low and recoverable, especially when the failure mode is "a human reviews it" rather than "content vanishes." For higher-stakes judgment calls, verification of subjective inference without re-centralizing is an open research problem. The architecture above is built so that the stakes stay in the zone where today's imperfect answers are acceptable, and so the human-review floor catches what falls through.

That's a narrower claim than "decentralized AI is trustless." It's also one I can defend.

The obvious objection

Steelman the other side properly: centralized APIs are cheaper per call at small scale, faster, more reliable, better documented, and integrating one is an afternoon of work. Frontier models behind those APIs also still hold an edge in nuanced judgment over the open-weights models you'd run on a GPU network. If you're building a startup's support bot, using decentralized compute for it would be malpractice.

All true, and none of it touches the argument, because the argument was never "decentralized compute wins on performance." It's that this specific class of tool is bought for its guarantees, not its throughput. A community that chose a censorship-resistant protocol is expressing a preference about who can shut things down. Tooling that reintroduces a shutdown switch, one layer up, doesn't serve that preference just because it's cheaper this quarter. You pay the latency and complexity cost exactly where the guarantee matters, and nowhere else. Spam classification also doesn't need a frontier model. Purpose-built open-weights moderation models already exist, Meta's Llama Guard and Google's ShieldGemma among them, and small open models handle narrow classification well, which is what makes the workload portable across commodity GPU hosts.

The mistake to avoid, on both sides, is treating this as a general architecture war. It's a matching problem: match the infrastructure's guarantees to the tool's actual requirements. Most tools need cheap and good. This one needs unkillable more than it needs brilliant.

Why now?

The pieces exist separately today: permissionless social protocols with real communities, GPU networks renting idle capacity at a fraction of hyperscaler rates (supply runs deepest in consumer-grade cards, which happens to be exactly what small classification models need), and open-weights models good enough for narrow classification. What's missing is the connective layer, the orchestrator-and-router pattern above, built as boring, reusable infrastructure rather than as a one-off bot.

The communities are the demographic, and they're not hypothetical; they're the people currently doing this work by hand, or watching their centralized bots operate on borrowed time. The end-user UX, done right, is invisible: the channel just stays readable, and the mod queue stays short.

The protocol layer is being decentralized in the open, gap by gap, with the whole ecosystem watching and arguing about it. The tooling layer is where the quiet re-centralization is happening, one API key at a time, with nobody watching at all. That's the layer to fix, and moderation agents, where the mismatch between the protocol's guarantees and the tooling's guarantees is sharpest, are the right place to start.