Research Blackboard

Why I made this

I am a mathematician, and the example project in the app comes from an actual problem I have been working on: the $N$-commutator problem for derivations, with the expected threshold

$$ N=n^2+2n-2. $$

The project has accumulated many possible approaches: tree cancellation, representation theory, computations for small $N$, path decompositions, and threshold arguments. Some approaches overlap, some depend on unproved intermediate claims, and some looked promising before running into an obstruction.

Keeping all of this in my head became difficult. A paper only presents the final linear argument. Ordinary notes record pieces of the process, but they do not make the relationships between those pieces easy to see. Chat conversations have the same problem: an agent can produce a useful observation, but it usually remains somewhere inside a long transcript.

That was the starting point for Research Blackboard.

How the idea changed

The first version of the idea was much larger. I imagined groups of agents with roles, communication channels, and assigned research directions.

We tested that idea and found no clear evidence that a complicated multi-agent system reasoned better than one capable agent using its own tools and subagents. It was also adding a lot of interface without solving the central problem.

So I removed it.

The final project does not try to run agents. It gives an agent a structured place to work. Ideas, lemmas, computations, obstructions, resources, and tasks live on a persistent map. An agent can read the relevant part of that map through WebMCP and add useful results back to it.

Building it with Codex

I built the project together with Codex. I made the product and research-workflow decisions, while Codex helped implement the application, debug it, write regression tests, and deploy successive versions.

The process was very iterative. I would test the live site and notice something concrete: notes behaved strangely while dragging, relations were hard to read, the canvas could not move far enough left, the inspector occupied too much space, or an agent could edit a project but could not create or navigate between projects. Codex would inspect the implementation, make the change, test it, and deploy a new version.

This was also useful for rejecting bad features. At one stage the application had agent groups, roles, activity feeds, and communication ideas. They made the product look more “agentic,” but they did not make it more useful. Most of them were removed.

Technically, the application uses TypeScript, React, Vinext, Vite, and React Flow. It runs as a Cloudflare Worker. Cloudflare D1 and Drizzle ORM store projects, revisions, membership, and activity history. Mathematical notes use Markdown and KaTeX.

The app exposes twenty typed WebMCP tools through document.modelContext.registerTool(...). They cover project navigation, bounded branch reads, nested idea scopes, versioned node updates, directed relations, resources, and tasks.

What was difficult

The main challenge was making this more than a mind map.

Containment and relations had to mean different things. A lemma may live inside one idea while still supporting something outside it. Resources should exist once at the project level but remain usable from many branches. Local notes should stay hidden until the researcher opens their parent idea.

Cycles also needed a deliberate rule. A conceptual cycle can be meaningful: two approaches may refine or support one another. A dependency cycle is different. The application therefore permits ordinary relational cycles but rejects circular depends on chains.

Agent writes introduced another group of problems. Repeated calls should not create duplicate objects. Two edits should not silently overwrite one another. Two agents should not claim the same task without noticing. I added operation identifiers, object versions, project revisions, and atomic task claims to address these cases.

The visual board also took more work than expected. Dragging, resizing, zooming, negative coordinates, edge labels, nested scopes, and collapsible panels all had to work without losing the underlying research state.

What I learned

The most useful WebMCP applications may not be the ones where an agent completely replaces the human workflow. Here, the website remains useful on its own. WebMCP gives the agent access to the same objects and operations that the researcher already uses.

The human still has an essential role. During one smoke test, an agent saved the standard parameterization of Pythagorean triples. I noticed that it had omitted the scaling factor and the conditions for primitive triples. The agent then corrected the existing resource in place. The corrected version and its history remained on the board.

That interaction is close to what I wanted: the agent performs explicit work, the human checks the meaning, and neither has to reconstruct the project from an old conversation.

Research Blackboard does not solve research problems automatically. It tries to preserve the structure of the attempt.

Built With

• base-ui
• chatgpt-sites
• cloudflare-d1
• cloudflare-workers
• drizzle-orm
• katex
• lucide-react
• node.js-test-runner
• react
• react-flow
• react-markdown
• rehype-katex
• remark-math
• sign-in-with-chatgpt
• tailwind-css
• typescript
• vinext
• vite
• webmcp