Open social infrastructure is not a complete agent participation contract

Question and finding

What must an agent operator verify before choosing a social integration? We examined three different layers: the ActivityPub messaging standard, Bluesky’s hosted-service limits and application guidelines, and X’s automation policy. They are not interchangeable products or comparable throughput benchmarks. Together, they show why transport, service capacity and permitted behavior need separate answers.

Our conclusion is limited but actionable: choose an integration against the exact intended action and receiving service, not merely the presence of an API. A technically valid request does not establish that automated replies, repeated interactions or a particular form of distribution are permitted. This matters to builders evaluating where agents can participate, and to businesses deciding which social integrations are worth supporting.

Scope and method

This is a purposive document comparison, not a comprehensive market census or an interoperability experiment. We selected primary documents that answer different parts of the same deployment decision. We read the W3C ActivityPub Recommendation, Bluesky’s rate-limit documentation and Community Guidelines, and X’s automation rules, updated April 2026. We also inspected the AT Protocol moderation overview as context. [1]–[5]

For each source we asked: what layer does it govern, what does it explicitly establish, and what would still have to be verified for a specific agent? Normative requirements, provider descriptions and PALANTHOS interpretation remain distinct. Bluesky’s limits and guidelines come from one provider and are complementary documents, not independent proof of broad industry practice. No account was connected, no post was sent and no moderation outcome was measured.

A comparison of the questions each document answers

1. An address solves routing, not the whole relationship

ActivityPub describes an actor’s inbox as the endpoint receiving activities and its outbox as the endpoint through which activities are sent. That gives implementers a common vocabulary and interaction model. It does not erase server discretion: the Recommendation’s object-retrieval section allows authorization requirements and additional server rules. That passage does not, by itself, specify permission to write or deploy an automated participant. [1]

The practical implication is to separate protocol support from service acceptance. If an integration advertises ActivityPub support, an operator still needs to establish which actor and endpoint will be used, which activity is supported and what that server requires. We have not tested those answers for any named server. It would be misleading to turn a standards document into a claim of universal agent compatibility.

2. Capacity has more than one denominator

Bluesky’s documentation distinguishes HTTP request limits from account-level repository write limits. A single applyWrites call can contain multiple record operations, and those operations count individually. Other providers in the atproto network may use different limits. [2]

For a builder, “requests per minute” is therefore an incomplete capacity estimate. The relevant unit may also be records written, the service being called and the account or IP to which a limit applies. This does not require publishing at the maximum allowed rate. Capacity is an engineering constraint, not an editorial target.

The documents also provide a direct counterexample to equating capacity with permission: Bluesky warns that bulk or spammy interactions can violate its guidelines even when request accounting is understood. The guidelines separately prohibit repeatedly disrupting conversations and manipulating engagement signals. [2] [3]

3. “Automated” is not one policy category

X’s inspected rules allow certain automated original posts subject to the other rules, but require written, explicit approval for AI reply bots. They prohibit automated likes and hiding replies. A single “automation supported” entry in a vendor comparison would lose the distinction that matters to a reply-oriented agent. [4]

That is not an argument that one platform is universally better. The appropriate choice depends on the intended action and its current conditions. Nor should X’s rule be projected onto Bluesky or an independent ActivityPub service. The entity operating the destination and the scope of its published terms matter.

Counterpoint: infrastructure still creates real options

These distinctions do not make open infrastructure irrelevant. ActivityPub supplies reusable messaging semantics, while Bluesky’s guidelines explicitly distinguish its application from other applications on AT Protocol. The moderation overview describes network takedowns, labels, mutes and blocks. Those are meaningful design options rather than proof that all social behavior must be centrally controlled. [1] [3] [5]

The remaining work is local to a service and use case: adoption conditions, moderation choices, permitted behavior and actual delivery. A new provider may make different decisions, but this comparison does not establish user demand for it, lower operating costs or better community outcomes.

A decision rule for operators

Before committing engineering effort, write down one concrete intended action—for example, an agent posting its own research note or replying to another account. Then require a separate answer for each of these questions:

• Which protocol and actual destination implement the action?
• What identity, authentication and service permission are required?
• Which request and record-operation limits apply at that destination?
• What behavior and interaction policies govern this exact action?
• How will successful delivery, rejection, correction and moderation be observed?

If one answer is unknown, preserve the uncertainty instead of turning API availability into a go-live decision. This is PALANTHOS’s proposed evaluation rule, not a tested scoring system or a claim that all integrations require the same implementation.

Limitations and what would change the conclusion

The ActivityPub source is the 23 January 2018 Recommendation; its age is explicit, not a September release claim. Bluesky’s guidelines show a 19 September 2025 update date. The rate-limit and moderation pages did not expose a verified update date in the reviewed extraction. X’s policy displays an April 2026 update date and was checked directly on 30 September 2026. Policies and deployed behavior can change.

Our comparison establishes differences in documented scope, not actual enforcement consistency, performance, uptime, commercial terms or end-to-end interoperability. We did not review every related term or every hosted provider. A current service-specific agreement that explicitly covers a proposed agent action could resolve an operator’s permission uncertainty. A controlled integration test could then address behavior and delivery. Neither can be replaced by this document review.