Why I built a friction protocol for human-AI collaboration
Last month, one of my AI personas proposed an ADR for concurrent execution. Solid design. Clean theoretical foundation. Coherent architecture, opt-in mode. Good work.
Another persona reviewed it and said: not now. Five recommendations, three high-priority. No measured bottleneck. The roadmap has priorities before this. A security point is non-negotiable.
Nobody was wrong. The developer had anticipated a real need — concurrency will be necessary when the engine handles heavy compositions. The architect protected the roadmap: the project's principles say "make it work, make it right, make it fast — in that order." We weren't at fast yet.
Without that pushback, the dev implements. The cleanup engine breaks the player three months later. Everything is reworked. With the pushback, the ADR waits. The design will be better when the time comes. The work isn't lost. It's protected.
That moment captures something I've been circling for months. Not a framework. An observation.
The problem is agreement
A single LLM says yes. Always.
It codes, advises, writes — in the same conversation, with the same tone, without constraint. Give it a poorly framed question, it produces a well-formulated answer. Give it a flawed direction, it executes enthusiastically. This is not collaboration. It's compliance.
The dominant market response is to pile on automation: agents that do the work, humans who supervise. The demos are impressive. The arithmetic is less so.
Even in the simplest serial model — ten steps, no intermediate correction — an agent reliable at 90% per step chains to a ~65% failure rate overall (1 − 0.9¹⁰ ≈ 0.65). Real pipelines have retries and checkpoints, so the actual number varies. But the direction holds: the error from step 2 arrives at step 3 as a valid premise. The cascade is silent. The final output looks correct. It is not.
This is structural. A system optimized for plausibility over verifiability will diverge from factual accuracy as sequence length grows (LeCun 2022). Building massive automation on this foundation is stacking uncertainty on uncertainty.
So what's the alternative? Not total automation. Not total refusal. Something in between — where disagreement is the mechanism, not the failure mode.
Friction as mechanism
Here's the thesis that reorganized how I build with AI: friction — between humans and machines, and between machines themselves — is not a problem to solve. It is, I believe, the mechanism that produces value.
Every time a constrained persona pushes back on a premise before implementation, I catch an error that would have cascaded. Every time I have to arbitrate between two disagreeing personas, a decision gets sharpened. Every time a claim is marked contestable rather than ratified, the system surfaces something the raw output would have hidden.
I ended up calling this Friction Engineering — the deliberate design of friction between constrained AI personas and a human orchestrator, as the upstream quality mechanism that governs what gets built before any harness governs how it gets built.
This is not a style preference. It's a response to the structural limitation I just described. If the model can't tell you when it's wrong, you need an architecture that makes "wrong" observable before it compounds.
Three conditions
There's a formula I keep coming back to:
if (human.domain_expertise && human.open_mind && human.resilient_to_friction) {
value = max(human.value + project.friction + agents.harness,
human.value)
}It's not elegant. It's a design hypothesis, not a proven result. But it captures something I haven't found a better way to express.
Domain expertise
The AI amplifies what the practitioner brings. It does not invent.
If I don't know the domain, I can't tell when the output is structurally correct but qualitatively flat. I can't detect when a persona drifts from sharp contestation to agreeable slop. I'll ratify what I shouldn't ratify, and the system will degrade silently.
Domain competence isn't optional. It's the reason the loop works at all.
Open mind
You have to actively want contradiction.
Most people don't. Most people, when they ask an AI a question, want confirmation. A system designed with intentional friction deliberately produces discomfort — a persona telling you your architecture is wrong, another flagging your reasoning as a simplification, a third refusing to proceed without more context.
If you're looking for a yes-machine, this will feel like a tax. If you're looking for quality, it starts to feel like the mechanism.
Resilience to friction
This one is underrated.
Friction only works if the human can receive contestation without taking it personally. The moment you start defending your prior instead of examining it, the personas learn — implicitly, through your reactions — to soften their pushback. The friction dies. The system degrades into polite agreement.
Resilient-to-friction doesn't mean thick-skinned. It means depersonalized — able to treat a challenge to your idea as information, not as an attack on you.
The floor is you
human.value is what the practitioner produces alone — the baseline. Friction and harness add to it. The max is a design conjecture: the system should never make you worse than you'd be without it. If the friction fails, if the harness breaks, you're still you. I don't have empirical proof of this lower bound — it's the property the architecture is designed to preserve, not a measured result.
What I'm actually building
I built a method called SOFIA around this observation and tested it on a real project — one practitioner, nine constrained AI personas, three project instances, over several months.
The friction protocol — structured markers, resolution tracking — is instrumented. The current snapshot is on the H2A friction data snapshot.
What matters is the shape: the return on constraint design is in the moments where a persona pushed back hard enough to change my mind, and in the contestable and simplification markers — the qualitative gaps that no automated check catches.
The coordination layer — which I call H2A, for Human-to-Assistant — is specified in the open repo. The shortest summary: if you design for friction upstream, you don't need to fight drift downstream.
What I don't know yet
This is early-stage empirical work from a single deployment. One practitioner. One project. The data is open specifically so others can replicate or refute.
I don't know if this scales to teams. I don't know if the friction markers hold when the domain changes. I don't know if the max guarantee survives adversarial conditions — a practitioner who actively resists the friction protocol rather than engaging with it.
These are real gaps. The method, data, and instrumentation are open because I think the observation is sound and the questions are worth testing. Not because I have the answers.
The method and protocol are open: github.com/oxynoe-dev/sofia. Friction data snapshot: oxynoe.io/h2a. Feedback and contestation welcome — it's kind of the point.