PaperlayerView exact revision on arXiv

Source-linked AI summary

Scriptorium: System Design and Implementation of a Multi-Human, Multi-AI Collaborative Digital Library Search Platform

Abbas Pirmoradi, Milad Momeni, Anna Chu, Orland Hoeber

arXiv:2610.28929v1cs.HCcs.IR

TL;DR

The authors know of no system combining collaborative search transparency with multiple differently scoped AI agents. Scriptorium brings these together in a digital-library search interface, and this report documents its architecture and implementation for inspection and reuse; its evaluation remains planned.

  • Problem

    Collaborative academic search support and AI-augmented individual workspaces have been studied separately, but the authors know of no system combining shared activity with differently scoped agents.

    Source: §1 · p. 1

  • Method

    Scriptorium combines transparent shared workspaces with a Manager–Worker architecture of seven role-specialized agents, whose routing and output are constrained by deterministic guardrails.

    Source: §3 · p. 5, §6.4 · p. 12, §6.5 · p. 13

  • Results

    The report documents Scriptorium’s complete architecture, data model, interaction rationale, and AI orchestration mechanism, including prompts, guardrails, and runtime configuration.

    Source: §1 · p. 1, §10 · p. 16

  • Takeaways & Limitations

    The technical account is intended to make the design inspectable, reproducible, and reusable, particularly its deterministic preflight guards and per-agent input scoping.

    Source: §10 · p. 16

    The prototype lacks production-grade authentication and would require real authentication before adversarial or production deployment.

    Source: §8 · p. 15

Abstract

from arXiv · show

This technical report documents the design and implementation of Scriptorium, a digital library search interface designed to support multi-human, multi-AI collaboration: full cross-user transparency of search activity combined with a Manager--Worker architecture of seven role-specialized generative AI agents. A companion short demonstration paper describes Scriptorium's interaction design; because a demonstration format is constrained to a few pages, it necessarily omits most implementation detail. This report documents Scriptorium's complete system architecture, data model, collaborative-interaction design rationale, and AI orchestration mechanism, including verbatim agent prompts, the deterministic guardrails that constrain them, the language model and retrieval configuration, and the steps needed to run the system, so that the design can be inspected, critiqued, reproduced, and reused by other researchers. We also discuss the system's current limitations and the user study we are planning to evaluate its central hypothesis: that combining collaborative transparency with scoped multi-agent AI assistance increases serendipitous cross-pollination between collaborators' research threads.

1 Introduction

Collaborative academic search and generative-AI workspaces have been studied separately, but the authors know of no system combining shared activity with differently scoped AI agents. This report complements Scriptorium’s demonstration paper by documenting the implementation for inspection, reproduction, critique, and extension.

1 Introduction

  • The report addresses a gap between collaborative search support and AI-augmented individual workspaces: no system the authors know of combines shared activity with multiple differently scoped agents.The companion demonstration paper presents interaction design but omits most implementation detail because of its page limit.Source: §1 · p. 1
  • This companion technical report documents the system for readers seeking to understand, reproduce, critique, or extend its architecture, rather than to argue for the research contribution.The companion demonstration paper is described as making that research-contribution case.Source: §1 · p. 1
  • The report covers related work, research framing, architecture and data model, interaction rationale, AI orchestration, runtime configuration, limitations, and planned evaluation.The orchestration account includes verbatim prompts and deterministic guardrails; the runtime section includes steps to run the system.Source: §1 · p. 2

2 Related Work

Prior work motivates Scriptorium’s collaborative-awareness and exploratory-search features, while its seven agents adapt established forms of support to a shared, multi-author evidence base. JANUS’s interpretation of differences between collaborators’ research threads is a distinct contribution.

2.1 Collaborative Search

  • SearchTogether established awareness, division of labour, and persistence for collaborative search, but its awareness features were valued more than division-of-labour features that could require a leader.Scriptorium instead makes workspace activity continuously visible without requiring an explicit sharing action or coordinating role.Source: §2.1 · p. 2

2.2 AI-Augmented Exploratory and Workspace-Based Search

  • Prior exploratory-search work supports metacognitive planning, monitoring, and evaluation, while WAG summarizes deliberately saved workspace content rather than ranker-selected documents.Scriptorium extends this framing to multiple searchers’ saved and discarded resources; related single-user mechanisms also informed its design.Source: §2.2 · pp. 2–3

2.3 Precedents for the Seven Agents

  • HERMES grounds query suggestions in group queries and saved or discarded document titles, while ARIA summarizes only the documents attached to a message.HERMES builds on query suggestion research [37]; ARIA narrows workspace summarization to the attached documents.Source: §2.3 · p. 3
  • MINERVA extracts only elements stated in an abstract and marks omissions as unstated, while CLIO formats references from catalogue metadata and leaves missing fields unfilled [23] [18].These constraints avoid inferring abstract content or generating absent citation details.Source: §2.3 · p. 4
  • SOCRATES critiques gaps in the group’s evidence and ends with a question, while MOMUS applies devil’s advocacy to the group’s assembled corpus.MOMUS builds on findings about devil’s advocacy and concerns about positive-information preference and biased conversational search.Source: §2.3 · p. 4
  • Scriptorium’s novel setting is seven established forms of support operating over a multi-author evidence base that includes discarded resources; JANUS bridges persistent research threads, including when collaborators search asynchronously.JANUS produces an account of collaborators’ threads and their connections, plus a bridging query, rather than acting on document retrieval.Source: §2.3 · p. 4

3 Research Framing and Design Goals

Scriptorium is a research prototype designed to study whether transparent shared search activity supports cross-pollination between collaborators’ independent research threads. Its design makes activity visible by default, scopes AI assistance for auditability, preserves genuine activity records, and layers features onto a familiar search-results interface.

3 Research Framing and Design Goals

  • Any logged-in user can view and resume any workspace, see collaborators’ colour-coded timelines, and read shared chat; this prototype choice serves a study of cross-pollination, not production multi-tenant defaults.The four resulting design goals are ambient awareness, auditable AI, genuine activity records, and a lightweight extension of familiar search.Source: §3 · p. 5
  • Collaborator activity should be visible by default rather than shared only through explicit recommendations or pushes.This goal prioritizes ambient awareness over explicit sharing.Source: §3 · p. 5
  • Users should be able to inspect which evidence an AI agent was allowed to see, rather than rely on a monolithic assistant’s answer.This is the stated goal of auditable AI assistance.Source: §3 · p. 5
  • Timeline events correspond to tracked actions such as queries, saves, removals, and document openings, not events fabricated to make the record look complete.The timeline may itself become a data source for studying group behaviour.Source: §3 · p. 5
  • Collaborative and AI features are layered onto a conventional search-results-page interaction model instead of replacing it with an unfamiliar paradigm.Source: §3 · p. 5

4 System Architecture

Scriptorium combines a MERN-based collaborative search layer with a server-side AI orchestrator and a data model that preserves activity history. Live updates use polling, chosen for the prototype’s small planned cohort.

4.1 Technology Stack

  • The MERN stack places the AI orchestrator on the server, where it builds request context and calls OpenAI; the browser never contacts the model directly.Search results come live from Ex Libris Primo, which Scriptorium overlays rather than replaces.Source: §4.1 · p. 5, Figure 1 · p. 6

4.2 Data Model

  • Soft deletion keeps discarded documents visible as abandoned research directions, while separate ViewLog records track genuine document openings.The model distinguishes saved and removed documents with a flag; search, save, delete, and view each correspond to a tracked action.Source: §4.2 · pp. 5–6, Table 1 · p. 6

4.3 Live-Update Mechanism

  • Three-second polling refreshes timeline, chat, workspace details, and view logs; a separate sixty-second poll refreshes the topic’s cross-user document list.The prototype chose polling over push updates to avoid maintaining a WebSocket server for a planned cohort of at most approximately nine concurrent testers.Source: §4.3 · p. 6

5 Collaborative Interaction Design

Scriptorium makes workspaces visible across collaborators and brings shared activity and chat into the search interface. Its timeline, persistent chat, and task-sensitive layouts support both active searching and review across sessions.

5.1 Transparent Workspaces

  • Any logged-in user can view or resume every workspace, while editing, archiving, and renaming remain restricted to its creator.This visibility is intended to make serendipitous discovery of a teammate’s search thread observable and possible.Source: Figure 2 · p. 7, §5.1 · p. 8

5.2 The Search Timeline

  • The timeline merges search, save, delete, and view events in one filterable chronological stream, using separate colors for event type and acting user.Event colors distinguish actions; a separate avatar-initial color identifies the collaborator.Source: §5.2 · p. 9

5.3 Persistent Chat

  • Workspace-scoped chat persists across searches, avoiding the disappearing history that internal testing found with topic-scoped chat.On the workspace-details page, chat can optionally be scoped to the selected past topic.Source: §5.3 · p. 9

5.4 Adapting Interface Complexity to Task Context

  • The shared Timeline-and-Chat dock adapts to task context: it is collapsible and resizable during active search, but expanded for workspace review.On the details page, the panels sit side by side at widths of at least 690 pixels and switch to tabs when narrower; pagination uses fixed blocks of up to ten page numbers.Source: §5.4 · p. 9

6 The Multi-Agent AI Orchestrator

Scriptorium uses seven specialized agents behind a Manager–Worker orchestrator, with inputs scoped in code and deterministic checks before model calls. Routing, prompts, and output constraints are designed to make agent behavior inspectable and bounded.

6.1 Design Rationale

  • Seven named agents use distinct personas, scoped inputs, and output limits; the design hypothesis is that this makes responses more predictable, citable, and trustworthy than a general-purpose assistant.The interaction log also records which agent collaborators invoke and when.Source: §6.1 · p. 10

6.2 Agent Roster

  • Code constructs a fresh, minimal input object for each agent, rather than relying on the model to self-restrict its attention.ARIA receives only documents attached to the current message; SOCRATES and MOMUS receive saved and discarded workspace history. Chat transcripts are limited to eight turns for agents that receive them, and CLIO and MINERVA fall back from attached documents to saved documents when needed.Source: §6.2 · pp. 10–11

6.3 Deterministic Preflight Guards

  • Deterministic preflight checks can refuse a request before any model call, based on workspace state.For example, ARIA requires attached documents, while JANUS requires search or save activity from at least two people.Source: §6.3 · pp. 11–12

6.4 Routing

  • An explicit @agentname mention delegates directly; otherwise, a manager routes the message or asks for clarification below 0.7 confidence.The routing call receives the message alone, without workspace content; if it fails, a keyword heuristic is used.Source: §6.4 · p. 12

6.5 Prompt Design and Hard Output Limits

  • All agents have prompt-stated input and output limits, but HERMES also has code-enforced limits because its JSON feeds clickable query-suggestion controls.The code clamps HERMES output to five queries of at most seven words each; the other six agents rely on the model to follow the stated limits.Source: §6.5 · p. 13

7 Reproducibility

Section 7 documents the model, workspace context, retrieval configuration, interface endpoints, and setup needed to run Scriptorium. It also identifies the code repository.

7.1 Language Model

  • Scriptorium uses gpt-5 through the OpenAI Chat Completions API, with provider defaults unless the model is changed through OPENAI_MODEL.Named-agent requests use one model call; delegated @ai requests use routing and worker calls, while preflight refusals use none. Without an API key, a deterministic mock provider supports development and testing.Source: §7.1 · p. 13

7.2 Context Construction

  • Context construction deduplicates saved and deleted documents by catalogue record and retains the last eight of the twelve available chat turns.The supplied slices also include attached-document metadata, workspace query history with authors, and each collaborator’s queries and currently held document titles.Source: §7.2 · pp. 13–14
  • Agents receive workspace-wide context, allowing them to reason across the group’s work on topics beyond the current search.The context is assembled from database records rather than the client’s copy; it includes collaborator queries, saved and deleted documents, activity, attached documents, and recent conversation.Source: §7.2 · pp. 13–14

7.3 Retrieval

  • Search results come from the institution’s Primo Search REST API, so another deployment requires its own API key and view identifiers and returns its licensed collection.Scriptorium consumes selected PNX fields; cover images are resolved by DOI through BrowZine and by ISBN through Syndetics.Source: §7.3 · p. 14

7.4 REST Interface

  • Table 3 lists the REST endpoints served by the Express backend under /api.The supplied passage identifies the table’s scope but does not enumerate its endpoints.Source: §7.4 · p. 14, Table 3 · p. 14

7.5 Running the System

  • The report gives installation and configuration steps, with npm run dev starting both processes after dependencies are installed in the root, backend, and frontend.Running agents requires an OpenAI API key with access to the configured model, and usage is billed to that key’s account.Source: §7.5 · pp. 14–15

7.6 Code Availability

  • The source code is available on GitHub under the MIT licence.Repository: https://github.com/abbaspirmoradi/Scriptorium-DL-InterfaceSource: §7.6 · p. 15

8 Known Limitations

The report identifies authentication, hosted-model dependence, polling, and model non-determinism as limitations. These constrain deployment conditions, reproducibility, or update behavior.

Authentication

  • The client stores an unsigned user object and backend endpoints trust client-supplied identifiers, making real authentication necessary before adversarial or production deployment.The authors consider this acceptable only for a controlled study with cooperative, consenting participants who are informed of the property.Source: §8 · p. 15

Hosted model

  • Agent behavior depends on a hosted OpenAI model whose snapshot, defaults, pricing, and availability may change outside the authors’ control.The authors recommend pinning a dated snapshot for later reproduction; workspace content sent to agents is transmitted to OpenAI, which study participants must be told.Source: §8 · p. 15

Polling

  • Chat and the activity timeline use three-second polling, a mechanism the authors describe as unsuitable for a production-scale version.Polling is characterized as simple and reliable at the system’s intended small scale.Source: §8 · p. 15

Model non-determinism

  • The same agent may produce different outputs for the same workspace state, although hard output-length limits and narrowly scoped prompts reduce but do not eliminate this effect.Source: §8 · p. 15

9 Discussion and Planned Evaluation

The report frames Scriptorium’s orchestration as multi-user workspace-augmented generation and describes a planned study of collaboration, agent use, and trust. The study is still being designed.

Discussion

  • Scriptorium grounds agent outputs in resources collaborators explicitly saved or discarded, rather than documents selected by a retrieval ranker.Its workspace is the group’s shared collection, and JANUS compares collaborators’ individual activity within it—a construct the authors say has no single-user analogue.Source: §9 · p. 15

Planned Evaluation

  • The planned study will compare timeline availability to examine whether and how quickly collaborators learn relevant prior activity without being told.Pairs or small groups will complete a realistic, multi-session academic search task.Source: §9 · p. 15
  • The study will examine which agents groups invoke and when, and whether auditable per-agent input scoping increases stated trust relative to a single undifferentiated assistant.The trust comparison is also to be probed informally in the companion demonstration’s interactive session.Source: §9 · pp. 15–16

10 Conclusion

The report documents Scriptorium’s architecture, data model, collaborative-interaction rationale, and multi-agent orchestration so others can inspect and reuse the system.

Conclusion

  • The report documents the complete architecture, data model, collaborative-interaction rationale, and multi-agent AI orchestration of a digital library search interface for multi-human, multi-AI collaboration.The authors particularly invite scrutiny and extension of its deterministic preflight guards and per-agent input scoping approach.Source: §10 · p. 16

A Verbatim Agent Instruction Strings

The appendix reproduces the seven workers’ prompts and explains their shared constraints and role-specific inputs, tasks, and output limits.

A Verbatim Agent Instruction Strings

  • The appendix reproduces the prompts from the running source, preserving the model-received line breaks apart from re-wrapping and typesetting substitutions.Each prompt is the first argument to llm.call, with the user request and scoped input supplied in workerInput.Source: A Verbatim Agent Instruction Strings · p. 18
  • All seven prompts share a named persona, an explicit input declaration ending “Nothing else exists,” and a closing hard limit.Most agents receive conversation history, but rules in four prompts restrict it to resolving who said what; CLIO and MINERVA do not mention it.Source: A Verbatim Agent Instruction Strings · p. 18
  • ARIA summarizes only attached documents without comparing them, while CLIO formats metadata-only references and forbids inventing missing bibliographic details.ARIA’s preflight guard refuses when no documents are attached; CLIO marks missing metadata instead.Source: A Verbatim Agent Instruction Strings · pp. 18–19
  • HERMES proposes exactly five non-repeated queries of at most seven words, with its query count and word cap re-enforced in code.Its input is limited to query history and saved or deleted document titles.Source: A Verbatim Agent Instruction Strings · p. 19
  • SOCRATES identifies evidence gaps or evaluates a stated claim, using deleted-document abstracts to flag dropped directions that may leave gaps.Its prompt limits the response to four gaps, one pointed question, and 100 words.Source: A Verbatim Agent Instruction Strings · p. 19
  • MINERVA extracts document design, data, sample, and analysis only when stated or inferable from abstracts, marking missing information “not stated.”When asked to compare, it groups documents by methodology family.Source: A Verbatim Agent Instruction Strings · p. 19
  • MOMUS contrasts the corpus’s dominant claim with document contradictions and may name outside counterarguments, which must be labeled “to verify.”It uses conversation only to resolve claim attribution and has a 120-word limit.Source: A Verbatim Agent Instruction Strings · p. 20
  • JANUS organizes activity by collaborator, identifies a connection between research threads, and proposes a bridging query; a bridge requires at least two active collaborators.Any suggested scholarly bridging work is labeled “to verify.”Source: A Verbatim Agent Instruction Strings · p. 20

B Agent Resolution and Manager Fallback

Explicit agent mentions resolve before model calls; if manager routing fails, a fixed-order keyword classifier provides a degraded fallback.

B Agent Resolution and Manager Fallback

  • Role aliases let explicit mentions reach the intended worker even when a collaborator recalls its function but not its persona.@ai and @manager instead address the manager and trigger routing.Source: B Agent Resolution and Manager Fallback · p. 21
  • On manager-call failure, a fixed-order keyword classifier routes specific intents to enabled agents; unmatched requests receive a clarification listing active agents.Contradiction and bridge terms are checked before more general gap, citation, method, summary, and query-reformulation terms.Source: B Agent Resolution and Manager Fallback · p. 21
  • The classifier is a degraded mode, not the design goal, and explains routing behavior that the manager prompt alone does not specify.Source: B Agent Resolution and Manager Fallback · p. 21

Related papers

Loading 2610.28929v1…