Thoughts on the team plan? Is the shared library any good?

You're right to be skeptical. Our team ran a three-month pilot, and the shared library's collaborative features were essentially a version-controlled file store. The structured data from annotations is stored in a proprietary JSON schema. While you can export it, the schema isn't publicly documented, making programmatic use outside their interface a reverse-engineering project.

We found the cost per user only made sense if every member's workflow was fully contained within the platform for both reading and note synthesis. The moment someone needed to pull data into a separate analysis tool or reference manager, the friction was high enough that the shared library became a very expensive, single-source-of-truth staging area that few actually updated.

Your final question hits the nail on the head. You are paying for the privilege of organizing their output elsewhere unless you fully commit to their entire annotation and summary workflow as a team. The lock-in isn't just contractual, it's data structural.

The cost is definitely a factor, but the value hinges entirely on the "workflow containment" point the next comment makes. If your team's synthesis happens entirely within the platform, the shared library is great for seeing overlapping highlights and building a collective understanding. If not, it's a tax.

The unique structure in the annotations is genuinely useful for connecting ideas across papers, but that data is only fluid inside their walls. Exporting it turns gold back into lead. You're not just paying for the folder, you're paying for that internal fluidity.

So the real test is: can you get your whole group to commit to doing their thinking *inside* the tool? If yes, it might justify the lock-in. If no, you've got a very pretty, expensive silo.

That "fluid inside their walls" point is crucial. We actually built a middleware script to extract and reformat their JSON to something our analysis pipeline could use. It's a pain, but it turns the locked-in data into a usable asset.

The script basically maps their nested annotation structure to a flat CSV with paper ID, highlight text, and user tags. It's not perfect, but it bridges the gap if you have one team member willing to be the "exporter."

So the silo isn't completely airtight, but you're right - you're paying for the platform, then paying again in dev time to get your data out in a usable shape.

> "Exporting it turns gold back into lead."

That's exactly what I ran into when I tried to feed their annotation exports into a small RAG pipeline I was building for our lab. The JSON schema is not just proprietary - it's deeply nested in a way that assumes you're always going to view it through their UI. The "connections between ideas" that look so clever in the browser become a tangled mess of IDs and references once you try to parse them programmatically.

I ended up writing a quick script to flatten it, but even then, the tag hierarchy doesn't map cleanly to anything like a standard knowledge graph or even a simple vector store. You lose the "why" behind the linking - the reasoning that made the annotation meaningful in the first place.

So yeah, the internal fluidity is real, but it's like being in a swimming pool with a one-way valve. You can splash around all you want inside, but the moment you try to drain it into another system, you're left with a puddle of opaque metadata.

Maybe the question isn't just "can you get your whole group to commit to doing their thinking inside the tool?" but also "how long before one of your team members wants to chat with their own LLM agent about the papers they've read?" Because that's where the lock-in really bites.