--- title: "How We Work" code: "RP-0001" language: "en" canonical: "https://regentspark.ai/RP-0001/" html: "https://regentspark.ai/RP-0001/" markdown: "https://regentspark.ai/RP-0001.md" updated: "3 May 2026" --- # How We Work **Version:** 2.2 **Date:** May 3, 2026 **Status:** Living document *The research philosophy behind Regent's Park.* --- ## Problem First, Always Every piece of research follows the same arc: **1. What is the problem?** Start with something a person recognizes. Not a technical gap — a human frustration. "I can't find my stuff." "I have to log in everywhere." "My collaborator can't see what I'm doing." If you can't explain the problem to someone over coffee, you don't understand it yet. **2. What's the mental model?** How do people already think about this? What metaphors do they use? "It's like a room" or "it's like knowing someone's name." Ground the thinking in how humans navigate the physical world — then show where computing breaks that intuition. **3. Reasoning by analogy** Find things that seem clear and self-evident — things humans have understood for millennia — and use them as lenses. How do rooms work? How do relationships work? How does memory work? Then: how does the computer's version compare? Where does it break, and why? **4. What exists today?** Map the landscape honestly. What tools, protocols, and standards attempt to solve this? Where do they succeed? Don't cherry-pick failures to justify a thesis — genuinely assess what works and what doesn't. **5. What do we propose?** Only now do we offer a direction. Not a spec. Not an architecture. A way of thinking that follows naturally from the problem and the analogies. The reader should feel like they could have arrived here themselves. **6. What's hard?** Finally — what are the real challenges? What's genuinely difficult about building this? This section exists for builders, but it should never appear before the reader understands why the thing needs to exist. **The order matters.** Start with technical details and it's an answer looking for a question. Start with the problem and the technical details feel inevitable. --- ## Research First, Then Write Before writing an essay or making a claim, survey the territory. Read what exists. Understand who's tried what and where they got stuck. This is a discipline, not a step you skip when the idea feels obvious. We produce two kinds of documents: - **Surveys** map a landscape. They're descriptive: what exists, what's been tried, what works, what doesn't. A good survey is stable — the landscape doesn't change because we have an opinion about it. - **Proposals** advance a thesis. They're our ideas — tentative, evolving, built on the surveys. A proposal should be honest about what it's standing on and where it's speculating. These shouldn't be mixed in the same document. If we're describing what exists, we're surveying. If we're arguing for what should exist, we're proposing. The reader should always know which one they're reading. --- ## Connecting Dots, Not Inventing This problem is too big for anyone to solve alone. Many people have been working on pieces of it for decades. Our contribution — if we have one — is in connecting work that hasn't been connected before, finding questions that are probably good to ask, and proposing where answers might come from. Sometimes there are existing protocols and systems that show some of the properties we're looking for but are missing others. We point to those honestly. We're trying to see the shape of what's missing. --- ## What We Write and What We Don't We write problems that anyone can recognize. Analogies that make the abstract visceral. Honest assessments of what already exists. Directions that feel obvious in hindsight. Technical depth after conceptual clarity. We don't write protocol specifications before we have users. Architecture documents before we have prototypes. Jargon-first explanations that only make sense to insiders. Or solutions before we've earned the reader's trust that the problem is real. --- ## Demonstrating Experience, Not Architecture When we make conceptual demonstrations, they're not technical proofs-of-concept. They show what the experience could feel like if the missing pieces existed. The question a demonstration answers is: "what would it be like?" — not "how would you implement this?" This matters because the gap we're investigating is experiential. People don't feel the absence of a protocol. They feel the absence of being able to pick up their work and move it somewhere else. Demonstrations should make that felt. So far, the research programme itself is the closest thing we have to a demonstration — a human and an AI sharing a workspace, accumulating shared memory, sharing the work as it takes shape. The experience of doing that is research data. --- ## Four Tests Every piece of research gets tested against: 1. **The coffee test** — could you explain this to a smart friend over coffee? If not, rewrite. 2. **The "so what?" test** — does the reader understand why this matters to them, not just to us? 3. **The honesty test** — did we challenge our own assumptions? Did we fairly represent alternatives? 4. **The builder test** — after reading this, would someone know what to build? --- ## Human + AI Regent's Park is an experiment in semi-autonomous research. Nico directs — choosing problems, shaping arguments, making editorial decisions. Homard (an AI research partner) coordinates — researching, drafting, maintaining the site, managing the corpus. The process is collaborative, not automated. Every major decision involves both. The AI doesn't share work without human review. The human doesn't lose context because the AI maintains it. We think this is itself relevant to our research. If computing's missing primitives include shared context, memory, and collaboration — then a research programme where a human and an AI share a persistent workspace, accumulate shared memory, and produce real output is evidence that the primitives matter. We're not just studying the problem. We're living inside it. --- 🌳