¶ Case Study: Obliqo
Type: Case Study
Status: Published
Version: v0.2
Last synthesized: 2026-06-10
Reviewed by: AI-drafted; human content-review pending
Open tensions: 6
A writer finishes a draft, opens a side panel in the browser, and pastes the text in. A minute later four readings come back. None of them praise the draft. One says a claim the writer thought was original is already common knowledge; one points to a contradiction between paragraph two and paragraph nine; one takes the central assumption and tries to break it; the fourth refuses to smooth the other three into agreement and instead hands back a single question the writer now has to answer alone.
That browser side panel is Obliqo. It is a real artifact — a Chrome extension and a web app, built, deployed, and running — and this page documents it as one case, not as the spine of the handbook. The reason it earns a chapter here is narrow: it is the place where the abstract claim of Cognitive Friction had to survive contact with shipped code, real models, and a writer who could just close the tab.
What follows is a chronicle. What was built, what was tried, what broke, and — the part most case studies skip — what is still unmeasured.
¶ What it is, by exclusion
Obliqo is not a writing assistant. That distinction is load-bearing, and it was made at the level of the product's own positioning before a line of UI was drawn: the project's internal documents describe it as a "structured disagreement engine," and the maxim repeated through its development is "not an assistant — a structured disagreement engine." An assistant lowers effort: it smooths the sentence, fixes the function, closes the gap between intent and output. Obliqo raises effort on purpose. It does not improve the text. It attacks it.
The wager underneath that refusal is older than the product, and it is not project coinage. The learning-sciences literature on desirable difficulties — Robert Bjork's term — holds that "certain training conditions that are difficult and appear to impede performance during training… yield greater long-term benefits than their easier training counterparts." Spacing, testing instead of rereading, varied practice: each feels worse in the moment and retains better over time. Obliqo is one attempt to put a difficulty of that kind in front of a writer at the moment they are most tempted to skip it — the moment just before they publish, when the draft feels finished and the easiest thing in the world is to believe it.
Whether adversarial reading by a model is a desirable difficulty in Bjork's precise sense, or only resembles one, is not settled here. The literature studies human learners under human-designed difficulty; the transfer to a machine adversary is the project's own bet, not an established result.
¶ The architecture: four readings that never meet
The core mechanism is four AI agents reading the same document in parallel, each with a distinct epistemic posture, none of them able to read the others. The isolation is the design, not a limitation: agents that can see each other converge, and convergence is exactly the flattening Obliqo exists to prevent. A fifth agent reads all four and synthesizes — but it is instructed to name the contradictions rather than dissolve them.
The roles, as they run:
- Global Researcher sets the draft against what is already known — what is missing, what is already common, what is actually new.
- Timbre reads the document against itself — internal coherence, latent tensions, the assumption stated nowhere but load-bearing everywhere. It listens for where the voice rings false: where the text sounds forced, or quietly puts on armour to cover a weak join. (In the handbook this reader is named Timbre to keep the word Resonance for the concept alone — the emergent surplus of the coupling, not a single agent checking one text.)
- Distortion is the antagonist, and it scales. At low intensity it asks gentle open questions; at the top of its range it goes after first principles. This is the agent that most directly performs Adversarial Friction.
- Synthesis — internally the Weaver — reads the first three and writes the integration. Its standing instruction is the hard one: do not average the voices, name where they collide, and end on the one question only a human can close.
Each run returns a Markdown revision document carrying all four voices plus the synthesis, a coarse triage score (the project's three levels are urgent / important / nice-to-have), and that final open question. The per-claim verdicts the engine emits are deliberately blunt — STANDS / BENDS / GIVES — and they are kept in fixed English across every locale, because they are treated as interface codes, not prose to be softened in translation.
The whole method has a name inside the project — Friction Orchestra — and the trademark for it is held by Pyragogy, not by Obliqo. We flag it here as project coinage, not an established construct: it is the umbrella term for the four-voices-plus-synthesis pattern, defined in the project's own materials and licensed to the product. It is named here, not redefined; the conceptual work the name points at is the handbook's Resonance and Divergence pages.
¶ What was actually built, and on what
The stack is unremarkable on purpose, and naming it is the honest thing to do because the case is partly a case about deployability. The extension is Manifest V3, built around Chrome's side panel — the API that lets an extension "host content in the browser's side panel alongside the main content of a webpage," so the critique sits next to the draft instead of replacing it. The web app is a SvelteKit front end; authentication and storage run on a self-hosted Appwrite; the agent pipeline is an n8n workflow calling models through OpenRouter; the whole thing deploys to a single VPS on push. None of these tools belong in the definition of what Obliqo is — they are the plumbing, and plumbing changes — but they are the difference between an essay about friction and a thing a writer can install.
One product decision is worth lifting out because it is where the philosophy shows in the code. Every run is private by default. Sharing is an explicit act, never the default state. The stated reason is that this turns the tool from a control instrument into a courage instrument: the writer runs Obliqo before taking the document to a team or a public, in the privacy where being wrong costs nothing — which is the only place the friction can do its work without becoming performance. The handbook names that hazard elsewhere as the Compliance Trap, and the default-private design is a direct hedge against it.
¶ What broke, and what the breaking taught
A case study that only reports the architecture is a brochure. The development record shows the engine being recalibrated repeatedly, and the direction of the corrections is itself the finding.
The verdict logic was tuned across many workflow versions — the live run engine is past its fiftieth iteration — and a recurring class of fix was about the engine being too agreeable, not too harsh. One late change pulled the most antagonistic agent's vote out of a scoring gate so that a single aggressive reading could not by itself inflate a document's severity; another tightened the Researcher so that "this is missing" had to clear a verifiability bar before it counted. Both moves point the same way: the hard part was not making the machine disagree. The hard part was keeping the disagreement earned — stopping it from manufacturing friction that looked rigorous and wasn't. An adversary that objects to everything teaches a writer nothing, the same way a flatterer does. It just fails in the opposite direction.
This is the project's lived version of the asymmetry the handbook states in the abstract: the model does not suffer the exchange and will not remember it. Left unchecked, an engine built to disagree drifts toward disagreement-as-output — friction as a deliverable rather than a service to the writer's thinking. The recalibrations are what holding that line looks like in a commit history.
There is also a smaller, concrete artifact of being new. A freshly published extension can trip Chrome's "not trusted by Enhanced Safe Browsing" warning — not a verdict on safety but a function of newness. The Web Store's own review documentation states that "all submissions go through the same review system, regardless of the tenure of the developer or number of active users," so the warning is not a claim that the extension is unsafe, only that it is recent. A tool whose entire argument is that trust must be earned through friction gets asked, on install, to earn its own over a few weeks. The instruction to the user is simply to continue past the warning. The irony is left where it falls.
¶ What is not yet known
Here the case has to stay honest, because the temptation in a chapter like this is to close with a number.
There is no number to close with. Obliqo is live and has paying users, but the count is small and the project caps its earliest tier at two hundred lifetime accounts — a ceiling, not a current figure, and it would be a fabrication to present it as one. Adoption, retention, and conversion are real and changing, and they are not reported here.
The harder gap is the one the whole handbook circles. We do not have evidence that a writer who uses Obliqo thinks better than one who does not — only that the tool reliably produces friction, and that the friction is, by construction, the kind the desirable-difficulties literature predicts should help. Whether it helps this writer on this draft, whether the help survives the writer learning to dismiss the orange agent the way one learns to dismiss a smoke alarm, whether dependency forms in the other direction — these are open, and they are open in the same way the Epistemic Ownership Dilemma and the risk of Long-Term Cognitive Co-Evolution are open.
What the case establishes is narrower than a result and more than nothing. It establishes that an artifact built on designed disagreement can be shipped, can run against real documents at real cost, and can be tuned over months toward friction that is earned rather than performed. The wager that this changes how a person thinks is still a wager. The engine is running, and the part it was built to provoke — the moment the writer reads the open question and has no one to hand it to — is the part no version of the workflow can finish for them.
¶ References
- Robert A. Bjork and Elizabeth L. Bjork, "Desirable Difficulties" (UCLA Bjork Learning and Forgetting Lab) — on training conditions that impede performance during learning but improve long-term retention and transfer. https://bjorklab.psych.ucla.edu/research/ — Coining of the term is typically attributed to: R. A. Bjork (1994), "Memory and metamemory considerations in the training of human beings," in D. J. Herrmann, H. Weingartner, A. Searleman, & C. McEvoy (Eds.), Memory: Interdisciplinary Approaches (pp. 185–205). Springer. Note: the publisher details and page numbers above were derived from secondary references and have not been verified against the original volume; readers should check before citing.
- Chrome for Developers, "chrome.sidePanel" API reference — hosting extension content in the browser side panel alongside page content (Manifest V3). https://developer.chrome.com/docs/extensions/reference/api/sidePanel
- Chrome for Developers, "Chrome Web Store review process" — review timing and the heightened scrutiny applied to new developers and new extensions. https://developer.chrome.com/docs/webstore/review-process
- Howard Rheingold and the Peeragogy Project, The Peeragogy Handbook — the peer-learning lineage this project forks. https://peeragogy.org/
↑ Back to Part IV — Cases and Experiments · Handbook · Home