When a research group needs to find candidates, several people are usually busy with it: the advisor has a rough scope in mind, the senior labmate has a list of potentially suitable names, and the student handling outreach is thinking about how to send the invitation. The trouble is that this information is rarely in the same place—the scope was mentioned once in a meeting, the list is in someone's notes, and the profiles to be used have to be asked for again. By the time it is all compiled, often no one can produce a complete version.
The essence of this problem is not that people are not diligent enough, but that there is no shared work surface. Talent Profiles address "what makes a record trustworthy," while the Collaborative Research Workshop addresses "where this trustworthy record is kept and who maintains it together." This article unpacks the point where the two connect.
01 When the list is scattered across chats vs. stored in a project group
▲ Figure 1 | The difference is not who remembers more, but whether the next person can pick up and use it.
Let's start with the most obvious difference. When the list is scattered across chats and emails, everyone adds a few notes to their own document, and mismatched versions are the norm when compiling: the same person appears as two entries, one person is written in two ways, and afterward it is hard to trace which version was which. Once it is put into a project group, there is only one copy—who added it, when it was added, and what it was based on at the time all stay in the same space.
The way uncertain items are handled changes as well. When organizing separately, an uncertain entry is often glossed over; in a shared draft, names that do not match can be put in a separate section, clearly telling later users "this one has not been verified." It is better to keep it as pending verification than to mix records of unclear origin into the official list.
Handover cost is the third difference. If someone else takes over the project, the context scattered across chats has to be explained all over again; in a project group, the conversations, agents, and files are all there, so the next person can open it and continue.
02 Three tabs, each taking care of one piece
▲ Figure 2 | Members, agents, and files—three types of objects sharing the same context
The Members layer answers "who is participating." The project creator and regular members are distinguished in the list, and the division of labor is explicit: the advisor sets the scope, the senior labmate adds candidates, and outreach is responsible for sending out the materials. Once roles are clear, there is no need to repeatedly discuss who should fill in which part.
The Agents layer answers "who organizes it." A project group can bind an agent, and members can invoke it by typing `@` in the input box. For candidate sourcing, its use lies in organizing the pile of names each person contributes according to the same set of fields—basic information, education, employment history, and main research achievements—aligned item by item into columns, rather than each person writing their own paragraph. In a MuchSci project group, this step happens in the same place as the discussion, with no need to move the list in and out.
The Files layer answers "where the output goes." The candidate list, organized profiles, and finalized invitation materials are all retained with the project and will not be washed away by new chat messages. During discussion, materials can be cited directly instead of dropping a link and letting everyone find it themselves.
03 How a shared draft grows
▲ Figure 3 | From creating the group and setting the scope to the finalized draft entering the Files area, all six steps happen in the same space
The process roughly has six steps: create a project group for a recruiting project and first clarify the scope; members each add candidates without rushing to organize them; in the chat, `@` the bound agent and have it fill in profiles in bulk according to the four categories of fields; put uncertain records in a separate section marked pending verification and keep them out of the official list; place the organized profiles in the Files area for members to share; and have someone familiar with the situation review them once more.
The valuable part is that "incompleteness is allowed." The existence of the pending-verification section shows that the organizing process acknowledges its own uncertainty. If a shared draft only allowed confirmed content, members would simply delete uncertain items, losing leads instead.
Traceability is another benefit. Who added a record, what it was based on, and whether it has been verified all remain in the project space. When it is time to formally send invitations, checking back costs much less.
04 Interface: Members, Agents, and Files on one screen
▲ Figure 4 | Three separate headaches, all caught by the same shared draft
After entering a project group, the interface looks like a project workbench: the right side has three tabs—Members, Agents, and Files—and the bottom input box indicates that typing `@` can invoke the bound project group agent.
▲ Figure 5 | Inside a project group: three tabs side by side, and you can directly `@` an agent in chat to assign tasks
The key here is the `@` mechanism. In a regular chat, @-mentioning a person calls them over to see a message; in a project group chat, @-mentioning an agent invokes its capabilities. The same input box can send messages to members and assign tasks to an agent, making the agent part of the collaboration workflow. MuchSci places Talent Profiles under the tab of the personal agent assistant, and together with this mechanism, profile organization and discussion can happen in the same place.
05 Boundaries
① This article discusses feature mechanisms and usage, and does not constitute a promise of results. A project group can centralize context, but that does not mean finding candidates will necessarily go more smoothly; in practice, it also depends on members' usage habits and how clear the task is.
② Structured information is not evaluation. Profiles are an organization of public information and do not constitute an evaluation of anyone's abilities, a recommendation, or an endorsement; judgments involving specific individuals must be independently verified and are the responsibility of the user.
③ Only public information is used. No personal privacy data is involved; when used for formal purposes such as review, recruitment, or due diligence, the current rules and procedures of the relevant organization shall prevail.