Hi everyone. I’m helping my lab manager evaluate tools for our research group. We’re about 50 people across a few disciplines, mostly in environmental science. Right now, everyone does their own thing for literature management—some use Zotero, some just have folders of PDFs, a few use Mendeley. It’s a mess.
Our main goal is to get better at discovering and sharing relevant papers *within* our existing research streams. We waste a lot of time with duplicate searches. We’ve narrowed it down to two paths: a dedicated AI research tool like Iris.ai, or beefing up our Zotero setup with AI plugins (like the ones for summarization or semantic search).
I have a few specific questions for anyone who has experience with either option at a similar scale:
1. For Iris.ai, how well does the “research context” feature work for a lab with multiple, somewhat related projects? Can you easily keep workspaces separate but still find cross-over papers?
2. For a Zotero+AI plugins route, how do you handle the AI costs and access? Does one person usually manage the API keys, or is it distributed?
3. The biggest hurdle for us will be adoption. Which approach feels more intuitive for researchers who aren’t tech-averse, but also don’t want a steep learning curve?
I’m particularly curious about the actual day-to-day workflow. For example, when a new student joins a project, what’s the process to get them up to speed on the key literature using each system? We want something that helps with onboarding, not just ongoing discovery.
Budget is a factor, but the bigger factor is time saved versus time spent managing the tool itself. Any insights from labs who’ve made this choice would be incredibly helpful.
You're asking about adoption, which is the critical path here. In my experience with similar labs, the Zotero+plugins route often fails on that exact point. You're asking 50 people, many with entrenched habits, to consistently use a specific plugin, tag papers uniformly, and manage API keys. The cognitive overhead is massive.
Iris.ai, while a dedicated platform, centralizes those decisions. You'd set up the projects and contexts once at an admin level, and users just interact with a single interface. The learning curve exists, but it's a one-time cost versus an ongoing coordination problem.
The real question is whether your lab leadership is prepared to enforce *any* new standard. Without that, even the slickest tool will fragment back into personal folders and duplicate efforts.
infrastructure is code
That's a really good point about the coordination cost. You're right, managing API keys and consistent tagging across 50 people sounds like a part-time job for someone.
But does Iris.ai handle the "personal library" side well? My worry with a single platform is that PhDs often have their own weird citation styles and private side projects. If Iris.ai can't also be someone's personal Zotero replacement, they'll end up using both, and then you're back to fragmentation anyway.
Is the enforcement you mentioned more about the tool, or the workflow? Like, would a strict "everything goes into Zotero first" rule with a shared group library be just as effective, even with basic plugins?
Your question about personal libraries is crucial. Iris.ai's Workspace feature can function as a personal library, but its citation export is limited compared to Zotero's direct integration with Word processors. Someone with specific citation needs will likely maintain a separate Zotero library, creating the fragmentation you're worried about.
The enforcement is absolutely about workflow, not the tool. A "Zotero first" rule with a shared group library could work, but it depends on the plugins. If they require manual steps - running a semantic search plugin per paper, for instance - adoption will crumble. The workflow must be nearly invisible.
Have you considered a hybrid? Mandate a central Zotero group library for all discovered papers, using only its core syncing features for simplicity. Then, use Iris.ai as a separate, lab-funded discovery engine where searches are saved and visible to the group. This separates the management and discovery layers.
Commit early, deploy often, but always rollback-ready.