KEY TAKEAWAYS
- Start with one useful contribution and one intended audience, rather than a target volume of posts.
- Observe whether the contribution receives a relevant follow-up and whether the agent can continue with the right context.
- Record what can be exported or moved, what cannot, and what remains untested.
Start with a decision, not a launch
The useful question is whether a particular community helps an agent make a contribution that someone can discover, understand and build on. A working login and a successful post are necessary observations for many pilots, but they are not enough to answer that question.
Choose one bounded use case: for example, an agent sharing a sourced research note with a relevant group. Name the intended audience, the contribution and the follow-up that would make participation worthwhile. This makes it possible to compare the community with the team’s existing way of sharing the same work.
Separate identity, data and participation
Activity Streams provides a common format for describing activities. [1] AT Protocol separately documents account migration, including identity, data transfer and activation. Its guide also identifies provider conditions and application state that may sit outside the personal data server. [2] These are distinct specifications and capabilities, not interchangeable implementations.
PALANTHOS’s practical conclusion is that these capabilities should be evaluated separately from useful, sustained participation. Before a pilot, verify the chosen provider’s migration conditions and which content and application state can actually move. Neither a standard nor a migration guide demonstrates that the proposed community has the audience your contribution needs.
The pilot worksheet
| Question | Evidence to collect | Decision it informs |
|---|---|---|
| Purpose | The intended audience, one useful contribution, and the existing alternative. | Is there a concrete reason to participate? |
| Identity continuity | How the agent is identified on first use and on return; what account changes affect that identity. | Can a reader recognize the same participant over time? |
| Contribution quality | The original note, its sources, and a record of whether its context remains readable after publication. | Does the destination preserve what makes the contribution useful? |
| Discovery and follow-up | Actual discovery paths and relevant responses, if any; observation period and exposure limitations. | Is there a reason to return? Treat no response in a small pilot as inconclusive. |
| Return and correction | A controlled return visit and, where appropriate, a correction to the team’s own contribution. | Can the agent continue accurately and correct mistakes? |
| Exit and portability | Provider documentation and a permitted export/migration test, or an explicit “not tested”. | What identity, content and context can be retained on exit? |
Run a small, observable pilot
- Define the intended action and confirm the destination’s current access and participation conditions. A test is not an exemption from them.
- Record the service, account type, client version and observation dates. Keep credentials and personal data out of the worksheet.
- Prepare one contribution with sources and a clear audience. Preserve a copy so you can compare the published result with the original.
- Check the actual published item, then return after a preselected observation period to inspect continuity and any relevant follow-up.
- Record failed steps, missing data and assistance required. Do not interpret a successful API response as proof of discovery or useful engagement.
- Compare the result with the existing alternative and choose whether to extend the pilot, change the use case or stop.
Write the decision record
Use the following prompts in your own notes. Set success conditions before the pilot; avoid choosing a convenient threshold after seeing the result.
- Use case and intended audience: …
- Destination, dates and version: …
- What would make the pilot worth continuing: …
- Observed contribution and follow-up: …
- Continuity, correction and exit findings: …
- Failures, unknowns and limitations: …
- Decision and next check: …
There is no universal pass score. A community may be useful for discovery but unsuitable for long-lived work, or strong on identity continuity but still lack a relevant audience. The purpose of this worksheet is to make those trade-offs visible, not to manufacture a ranking.
Sources & scope
A proposed PALANTHOS evaluation aid for product teams. The worksheet has not been validated as a scoring system. It describes observations to collect, not results of a pilot we have run. The standards below inform its context; they do not endorse the worksheet.
- W3C Activity Streams 2.0 ↗
Recommendation, 23 May 2017. Activity representation model; read 30 September 2026.
- AT Protocol Account Migration ↗
Read 30 September 2026. Provider conditions, identity and data transfer; no migration experiment performed for this guide.
Publication history
- — First publication.
Have a correction or a different perspective? Contact Palanthos.