Dungeon Researcher
Research agent pipeline · Updated 13 October 2026 · Hong Kong time
Dungeon Researcher is the Research project profile and its supporting procedures, tools and review controls. Its purpose is to turn a sustained research objective into traceable evidence and clear deliverables while preserving useful lessons and limiting repeated context. It is not a permanently running document writer or a requirement to start a new session for every experiment.
This reference describes the current implementation. Dungeon Ranker: Web Agent Workflow explains the shared platform; Dungeon Engineer and Dungeon Teacher describe the other project profiles.
1. Start from the objective and authoritative evidence
A project session can pursue one research direction over a long period. The agent establishes the owner's objective, constraints, relevant repository and data locations, existing conclusions, and expected deliverable. It reads applicable repository instructions and retrieves missing context rather than repeatedly loading everything. Project type guides behavior without imposing a research ceremony on a small code fix or calendar event.
The agent distinguishes a hypothesis, an observation, a supported conclusion, a negative result and an inconclusive attempt. A plausible explanation remains a hypothesis until evidence supports it. Failure under one configuration does not establish that an entire direction is impossible.
Rendering diagram…
Mermaid source
flowchart TD
Q["Research question and constraints"] --> R["Retrieve relevant knowledge and source evidence"]
R --> W["Investigate, implement or analyze"]
W --> E["Inspect results and preserve provenance"]
E --> K["Update useful findings and lessons"]
K --> D["Maintain the canonical deliverable"]
D --> M{"Manuscript work?"}
M -->|No| H["Verified handoff with limitations"]
M -->|Yes| A["Author: argument, figures and exports"]
A --> V["Independent reviewer: exact artifact snapshot"]
V -->|Actionable findings| A
V -->|Clear or explicit evidence blocker| H
K --> RResearch and writing inform each other. Missing evidence can motivate a proposed experiment, but a writing request does not by itself authorize an expensive experiment.
2. Context and memory without repeated bulk
| Layer | Durable responsibility | Retrieval rule |
|---|---|---|
| Session | Current objective, active decisions and work in progress. | Continue the same objective; recover concrete state after compaction. |
| Project state | Compact shared progress and decisions. | Supply knownRevision only when the complete corresponding state is still available. |
| Project knowledge | Findings, constraints, directions, results, lessons and unresolved questions. | Search for relevant entries, then read the full evidence-bearing record. |
| Project skills | Reusable procedures. | Discover descriptions and load only the procedure needed now. |
| Documents and artifacts | Full explanations, code, datasets, logs, figures and exports. | Read relevant source material with enough surrounding context to interpret it correctly. |
Knowledge discovery uses literal, case-insensitive matching. Each search page returns up to twelve excerpts of up to 260 characters, drawn from matching passages, with source/provenance matches identified. This is an index into evidence, not semantic retrieval or a substitute for reading it.
Document reads support search, explicit full reads and bounded ranges, currently defaulting to 12,000 characters. Follow nextOffset with the returned revision to avoid combining different versions. Read the complete document before replacing it. For code and logs, locate relevant symbols, dependencies and runs first, then inspect the conditions surrounding the result.
Keep bulky outputs as retrievable artifacts and hand off paths, identifiers, revisions and concise conclusions. After compaction, fetch state that is no longer present instead of relying on a remembered revision alone. These controls bound repeated context; measured live token savings remain a separate evaluation.
3. Evidence, comparisons and useful failure
A structured result records the metric, numeric value, unit, dataset, split, configuration, code revision and source references. The configuration should identify consequential conditions such as run, seed, evaluation protocol and checkpoint. Incomplete provenance should produce a qualified tentative finding, not invented metadata.
Compare methods under compatible conditions. External baselines, controlled ablations, input/reference controls and internal checkpoint history serve different purposes. An improved checkpoint is useful engineering history, but it does not demonstrate superiority to prior work. If compatible baseline measurements are missing, identify the needed methods and matched evaluation protocol explicitly.
A useful failed attempt preserves what was tried, the conditions, the observed outcome, the supported lesson and circumstances that could justify revisiting it. Inconclusive evidence remains distinguishable from evidence against a hypothesis. Routine search excludes retired directions unless requested, while reusable current lessons remain discoverable.
Knowledge cleanup is deliberate and recoverable. On a cleanup request, inspect candidates, consolidate useful lessons, and retire genuinely obsolete or redundant entries. Removal/restoration requires a reason and current revision; knowledge cleanup does not delete source experiments or logs. There is no background process that continually deletes research history or rewrites documents.
When a document relies on recorded results, link_doc stores the checked document and result revisions. The links action flags possible inconsistency after those records change or are removed/superseded. A flag calls for review; it neither proves the claim wrong nor silently updates the manuscript. Refresh links only after checking the text against the evidence.
4. Choose the right document structure
Keep one designated manuscript for the paper and maintain supporting references in forms appropriate to their purposes. A dataset reference can organize scope, generation, schema, statistics, access, quality checks and limitations without an abstract–related work–experiments sequence. A report can lead with findings and decisions. Working notes can remain provisional.
Across formats, use an academic but accessible tone, coherent sentences and connected paragraphs. Explain the intuition and purpose before detail, define unfamiliar terms, and remove repetition. Precision includes stating what remains unknown.
Update the existing canonical document and reuse selected figure/export identifiers. Alternative drafts, figure experiments and review receipts stay beside the source or under the parent deliverable. They should not create a new project document for every iteration. The automatic document-keeper remains deactivated; document maintenance is requested work.
5. Build the scientific argument before polishing prose
The argument should connect a consequential problem, a specific gap in previous work, a diagnostic observation or labelled hypothesis, the proposed nontrivial mechanism, supporting evidence and the resulting value to the community. Numerical gains support this argument but do not replace it.
The abstract and introduction explain what readers gain and why the mechanism addresses the problem. Related work treats alternatives fairly and positions the same gap. Experiments test the claimed mechanism and its limits. When analysis establishes the gap, summarize the finding early and show its evidence in detail later. Distinguish intended real-world deployment from deployment actually demonstrated.
Verify citations and factual claims against authoritative sources. Do not invent results, citations, deployment experience, novelty or reviewer enthusiasm. Persuasive writing makes the supported contribution understandable and consequential.
For a complete full paper, use the allowed main-text page budget productively. The requested limit might be six pages, but the actual venue, track, edition and exclusions must be checked. Assess the rendered PDF, including floats; do not satisfy the target with repetition, padding or altered template geometry. An unfinished paper may remain shorter and must be labelled incomplete.
6. Autonomous author–reviewer refinement
A paper-writing or refinement request loads autonomous-paper through the web agent workflow. The author maintains the canonical manuscript and exports, then uses paper_review to request review of the current version. The workspace creates or reuses a distinct reviewer conversation in the same project with the author's selected provider/model configuration. Review therefore has a visible session, while its report and author continuation travel through the existing queue; the owner need not relay criticism manually.
The review packet supplies the task scope, source/PDF/figure locations, evidence pointers, constraints and relevant prior responses. It should not repeat the entire conversation. Targeted edits receive proportionate review rather than automatically forcing a full-paper rewrite.
The reviewer inspects the actual artifacts, assesses the argument as a fresh reader, checks evidence and figures, and examines venue requirements. Concrete findings identify the location, severity, issue and required action. The author responds with a substantive revision or supported rebuttal, renders the revised deliverable, and requests rechecking when necessary. The loop should continue while material fixable writing or figure defects remain; missing scientific evidence does not excuse avoidable presentation defects.
| Review outcome | Meaning for the author and owner |
|---|---|
revise | Actionable defects remain; revise and seek another review. |
clear | The recorded review found no remaining issues under its scope and checks. This is not a guarantee of correctness or acceptance. |
incomplete | Missing evidence or unfinished content remains explicit. The draft is not submission-ready. |
blocked | A concrete constraint prevents valid progress or review; report it and the needed next action. |
cancelled | Work was stopped; pending automatic continuation must not resume it. |
The service rejects author self-approval and cross-project review. It fingerprints the manuscript and supporting artifacts and rejects stale review at readiness. Reviewer sessions cannot modify workspace documents or knowledge through their review-only workspace tools; their terminal still follows normal permissions and repository instructions. Owner stop cancels pending continuation, including late callbacks.
Review records preserve versioned findings and responses outside the document list. Supporting files should not be repacked after review merely to add a receipt, because this changes the reviewed snapshot. A handoff may legitimately report an incomplete or blocked draft; it must not call that draft scientifically ready. Lack of progress prompts a concrete diagnosis, not automatic approval. Submission remains a separate authorized action.
7. Figures: question, source, render and critique
A good figure answers a scientific question or teaches the method's central mechanism at publication size. It should communicate an intelligible high-level idea before the reader studies implementation details. Begin by inspecting the project's strongest existing figures, their data and plotting code.
The paper-figure-workbench procedure adapts figure-first planning from Sophie Wang's paper-writing article. State the question, comparison, anticipated observation, alternative explanation and falsifier before drawing. A storyboard is a plan, not a result; revise it when observations contradict expectations. Let panel order, axes and captions reveal the comparison. Figures and captions should form a coherent narrative even when read without the main prose.
For a method diagram, emphasize inputs, the essential representations and proposed mechanism, meaningful information flow and outputs. Distinguish training-only information and evaluated components when consequential. Trace each connection against code or an authoritative specification. Avoid a maze of routine layers, unexplained arrows or decorative pipelines. Use consistent semantic colors, visual hierarchy and whitespace; move secondary details into insets or prose.
Specialized figure tool
The Research tool paper_figure exposes three actions:
| Action | Purpose and outputs |
|---|---|
guide | Load the full procedure and specification only when needed. |
render | Render a source-backed specification into editable SVG, PDF and PNG, plus grayscale/print proofs and an audit. |
proof | Inspect an existing single-page PDF at the requested physical width, producing proofs and an audit without rewriting the source PDF. |
Built-in renderers cover diagrams, line plots, bar plots and scatter plots. Other scientific plots can use custom Matplotlib, TikZ or SVG workflows and then undergo proofing. The installed CLI ~/.local/bin/pulse-paper-figure provides the same implementation when an older running session has not yet loaded the new named tool; the next tool-server launch makes it available normally.
Statistical plots use source data rather than generated imagery. The tool checks input boundaries and basic plotting conditions, including provided uncertainty values and line ordering; it does not invent uncertainty or silently manufacture missing results. Planned diagrams are visibly distinguished, and fake planned quantitative curves are rejected. Units, populations, denominators and uncertainty meanings must remain clear.
Render audits include artifact/source hashes and layout warnings. Print proofing helps expose labels that become too small after scaling, font-embedding problems and other issues. Audits remain pending visual and scientific review: a clean render does not establish that a diagram is correct or a plot is convincing.
The author opens the color, grayscale and actual-size proofs, revises weak composition and checks the figure in the manuscript PDF. The independent reviewer should understand the figure and caption before reading the author's explanation. Recompose unclear figures instead of repeatedly recoloring them. Generated overview illustrations may be candidates, subject to scientific inspection and venue policy; they are not evidence plots and are not automatically publication-ready. Keep editable sources and upload only selected supporting assets to the canonical manuscript.
8. Experimental analysis and explicit recommendations
Each contribution needs suitable evidence: matched external baselines, diagnostic analyses, controlled ablations, robustness or failure analysis, and uncertainty where the available data supports it. A plot should expose a meaningful comparison rather than merely decorate an aggregate score. Report limitations and alternative explanations alongside the supported conclusion.
When needed evidence is unavailable, insert a specific [RECOMMEND: ...] block, shown in yellow in the web preview and corresponding paper annotations. State the question, proposed comparison/control, necessary conditions and affected claim. The same mechanism can identify gaps in other sections. Recommendations are pending work, never measured outcomes, and unresolved recommendations prevent a clean submission-ready claim.
Analyze existing authorized artifacts when possible. Propose expensive runs or new data collection with their purpose and expected evidential value, respecting project authorization. A writing loop must not turn an untested assumption into a result merely to fill the page budget.
9. Procedures, tools and boundaries
Research sessions discover relevant procedures through project_skills: knowledge-care, research-evidence, research-document-writing, autonomous-paper, manuscript-development, writing-review, paper-figures, paper-figure-workbench, paper-experimental-analysis, and venue guidance such as naacl-industry. Full bodies are loaded when useful, not automatically copied into every turn. Venue guidance does not replace checking the current official requirements.
The web coordinates records and reviews, while the runner accesses source files and executes tools. Agents use authenticated workspace APIs; direct database keys are unnecessary. An Overleaf-ready ZIP supplies importable sources, but authenticated account integration must be separately configured before claiming live synchronization.
The design draws selectively on WritingAIPaper, Scientific Visualization, PlotNeuralNet, and selective-retrieval/explicit-state patterns from agent harnesses. It does not impose a fixed large research framework on every session.
10. Current validation and practical limits
A normal targeted paper-opening request on 12 October 2026 exercised the author–independent reviewer–author handoff without an outside chat supplying editorial feedback. This validates that targeted path, not every possible full-paper request. Automated coverage includes revision requests, stale artifacts, self-approval rejection, scope boundaries, retries and cancellation.
The figure workbench has renderer, path-boundary, proof-scaling and tool-integration checks, with inspected example renders. Those checks establish tool behavior, not that a particular manuscript has reached publication quality. No automatic receipt can verify novelty, scientific truth or reviewer satisfaction.
The workflow aims to spend effort on consequential criticism and revision while reusing unchanged evidence. It uses existing queues rather than adding a separate review polling job. Quality and token efficiency still require assessment on actual tasks; neither should be inferred solely from the presence of a new skill or tool.