Safebots adds AI behaviors to community streams: inline suggestions, goal tracking, code discussions, and multilateral negotiations. All governed. All attributed. All on infrastructure you control.
Most AI tools are separate applications. You context-switch to them, copy-paste content in, copy-paste results out. They don't know your community's context, can't act on it, and leave no audit trail.
Safebots is different. A bot is a behavior attached to a community's own streams. When a message is posted in a chat, a goal is updated, or a code symbol changes — a bot can respond in place, as part of the same stream, using the same governance, access controls, and notification system as everything else.
There is no "bot user" with a separate identity, separate access rows, or separate billing context. A bot is a Safebots/bot stream published by the community. When it acts, it acts as the community — with the community's identity and the community's pre-authorized governance decisions. Actions are attributed to both the source of the information and the bot that processed it.
A bot declares which message types it responds to and which tool runs for each. That's it. The platform routes messages, runs tools inside Safebox's governance sandbox, and posts results back to the stream.
Each bot has a Safebots/handlers attribute: a JSON object mapping message types to tools. "Streams/chat/message" → "suggest/messages" means: when a chat message arrives, run the suggestions tool.
Activating a bot (relating it to the community's Safebots/bots category) is the community's standing decision to pre-authorize every future firing of every declared handler. A judgment automatically votes approve on bot actions that match the declared types.
Every tool runs inside Safebox — a sealed execution environment with no network access, no filesystem access, and a strict list of approved action types. A bot cannot do anything its handler didn't declare it would do.
Every bot action is attributed as from @source via @bot. If a suggestion is based on information from Alice's message, that attribution is preserved. The audit trail is always complete.
The suggestions bot reads recent messages in a chat stream, understands what's being discussed, and offers contextual next steps — not generic completions. It knows about the community's goals, related streams, and ongoing workloads.
JWTManager::validate to make it clearer it also refreshes tokens?JWTManager::validate has 23 direct callers. Renaming it would be a class-B contract change — backward compatible, callers would need a signature update but no semantic changes. Conventions require updating the docblock to reflect the new name.
The bot doesn't just answer — it offers to act. The suggested workflows are real: clicking "Start rename workflow" triggers the Code plugin's governed rename pipeline, with a human-in-the-loop approval step before anything changes.
A goal stream is a structured record of an outcome the community is working toward. Goals have states (open, in progress, blocked, done), related artifacts, and a chat thread. Safebots keeps goals connected to the work being done on them.
Goals capture the "why" behind a task, not just the task itself. When a Code sprint completes, the goal it served gets updated automatically.
A goal can link to any stream — chat threads, code symbols, documents, Grokers concepts. The graph makes these connections queryable.
When a related symbol's contract changes, or a sub-workload completes, the goal stream is updated. Subscribers are notified through the standard Qbix subscription cascade.
Safebots includes a full multilateral negotiation protocol for situations where multiple communities need to agree on something before action can be taken — a contract term, an API interface, a shared policy.
Any participant proposes a "lock" — a specific, atomic agreement item. Locks are versioned streams. Amendments create new versions, not overwrites.
Each party has a seat in the negotiation stream with its own authority domain. Participants discuss in the attached chat, propose amendments, and counter-propose.
Parties sign locks using Qbix's vote mechanism. Once accumulated signature weight meets the negotiation's quorum, the lock auto-commits. Cryptographically verifiable, no intermediary.
A committed lock can automatically trigger Safebox workflows. Agreeing on an API interface can trigger a Code sprint to implement it. Agreeing on a policy can publish it to all relevant streams.
Grokers, Code, and Safebots are designed to compose. Each layer has a clear domain and does not duplicate the others.
The knowledge layer. Parses everything, builds the graph, analyzes every function, maintains concepts and conventions, tracks what changes affect what. Doesn't write code. Doesn't talk to users.
The execution layer. Reads from Grokers, proposes changes, verifies contracts, cascades to callers, runs tests, ships branches. Doesn't analyze code. Doesn't orchestrate humans.
The collaboration layer. Talks to people, surfaces knowledge from Grokers, triggers Code workflows on human intent, facilitates negotiation and agreement. Doesn't modify files. Doesn't build graphs.
1. Safebots receives the chat message, runs code/discuss against the Grokers graph.
2. Grokers supplies: 23 callers, current contract, applicable conventions, Grokers/impact preview.
3. Safebots presents the impact summary, offers workflow options.
4. Developer approves → Safebots triggers Code's rename workflow.
5. Code clones workspace, proposes rename, verifies class-B contract, updates 23 callers, runs tests, ships branch.
6. Grokers detects the file changes via regrok, re-analyzes affected symbols, posts updated impact report.
7. Safebots notifies the goal stream that the rename is done.
Notifications in Safebots are not a feature Safebots built. They're the Qbix Streams subscription system, which has been handling this for years. Anyone can subscribe to any stream and any message type. They choose their delivery channel: email, mobile, in-app. When a bot posts a relevant message to a stream, subscribers receive it through their normal channels.
A developer who subscribes to a code symbol stream receives a notification when its contract changes. A product manager who subscribes to a goal stream receives an update when a sprint completes. A community leader subscribed to the negotiation stream is notified when a lock is proposed. None of this required Safebots to build a notification system.
Bots can also be stream participants. A Safebot subscribed to a code symbol gets the same Code/contractChanged message as a human subscriber — and can respond to it by opening a planning discussion, proposing a fix, or flagging it for the team.