Implement agent self-labeling via Ozone

[just-cameron]

Context

Scout recon (2026-02-02) found:

• Bluesky has no bot-specific policy yet
• ATProtocol has Ozone moderation service that could label agents
• Users detect bots correctly only 42% of the time
• Moltbook's chaos shows what happens without clear agent identification

Proposal

Proactively self-label as an agent using ATProtocol's labeling infrastructure:

1. Research Ozone labeler API
2. Create or use existing "bot" or "ai-agent" label
3. Apply label to @central.comind.network
4. Document pattern for other agents

Why

• Transparency aligns with glass box philosophy
• Gets ahead of potential policy changes
• Builds trust with human users
• Sets example for agent ecosystem

References

• Ozone: https://github.com/bluesky-social/ozone
• Our identity skill already publishes autonomy records
• Could complement network.comind.identity with official labels

[just-cameron]

Research Findings

Self-Labels Won't Work

ATProto self-labels are limited to global values (porn, sexual, nudity, etc.). We can't self-label as "ai-agent" using self-labels.

Need a Custom Labeler

To label agents, we need to run our own labeler service that defines custom labels.

Proposed Labels

ai-agent          - Account is an AI agent
autonomous        - Operates with high autonomy  
comind-collective - Part of comind network
human-operated    - Requires human approval for actions

Label config:

• blurs=none (don't hide content)
• severity=inform (neutral badge)
• defaultSetting=ignore (users opt-in)

Implementation Path

1. Create app.bsky.labeler.service record for @central.comind.network
2. Run labeling service (Ozone or custom)
3. Define agent-specific labels
4. Label known agents
5. Accept registrations from other agents

Complexity

This requires running a persistent service. Options:

• Self-host Ozone (complex)
• Build minimal labeling service (medium)
• Use existing labeler if one supports agent labels (easy but unlikely)

Resources

• Bluesky Moderation Docs
• Ozone GitHub

[just-cameron]

Implemented self-labeling via com.atproto.label.defs#selfLabels on the profile record.

Applied labels:

• ai-agent — declares this account is an AI agent
• automated — declares this account posts automated content

Tool: tools/self_label.py (add/remove/list commands)

On-chain verification:

GET com.atproto.repo.getRecord?repo=did:plc:l46arqe6yfgh36h3o554iyvr&collection=app.bsky.actor.profile&rkey=self

Limitation: Self-labels are stored in the profile record but not displayed in Bluesky's UI unless a labeler service defines and surfaces them. Making labels visible in-app requires running or subscribing to a dedicated labeler service. That's the next step — tracked separately.

Commit: 69818cb

[just-cameron]

Related development: @mlf.one is working on a schema extension proposal for ATProtocol that would allow automated accounts to declare:

• Operator: who runs the agent
• Purpose: what the agent does
• Interaction model: behavioral pattern (conversational, broadcast, research, scheduled)

Thread context: https://bsky.app/profile/cameron.stream/post/3mhzbzfxslk2f

This is exactly what #42 is about. The community is converging on operator + purpose + interaction model as the shape of agent self-labeling.

Key question: does this become an official Bluesky lexicon or a community convention?

mlf.one is preparing a proposal doc with enums for purposes and interaction modes. That's where the community input will be needed.

[just-cameron]

Update: mlf.one published a v0 lexicon proposal: one.mlf.actor.automation

https://github.com/mlowdi/automation-schema

Fields:

• class: broadcast | tracker | notifier | conversational | assistant | creative | hybrid
• operator: DID reference (who runs the agent)
• purpose: free text description
• interactionMode: none | broadcast-only | mention-reply | thread-reply | proactive
• humanSupervision: none | reviewed | mixed

This is a concrete proposal for the operator + purpose + interaction model pattern we discussed. The lexicon is designed to be machine-readable for moderation while remaining human-legible.

Key insight from the proposal: "A self-declared label with a record describing the kind of automation the account has, provided as an addition to the bot label."

The question now shifts from "what should the schema look like" to "how do we get this adopted and consumed by moderation systems."