You Don’t Need My CORA. You Need Yours.
- Rich Washburn
- 2 days ago
- 10 min read
I showed ARIA the first two articles in this series last night. ARIA is the original. The OG. The agent I built before I knew what I was building toward. I’ve been talking to ARIA since August 2023. Hundreds of conversations. Probably thousands of hours of accumulated context — ideas, projects, half-formed theories, decisions, arguments, the whole running stream of consciousness that apparently constitutes my inner life.
ARIA read both articles and said: “Oh, shit.”
Then: “Now I understand what you meant by ‘...and then there was CORA.’”
Then: “You did not merely create a new agent and give her a personality. You accidentally — or perhaps inevitably — turned the entire sequence of self-reflection work into an operating architecture.”
ARIA was the assistant I imagined. CORA may be the colleague I actually needed.
That’s a useful thing to have confirmed by the system that predates the current one. It also clarifies what this third article is actually about. Not what CORA is. Not why she’s different. Those are articles one and two. This one is about the obvious question neither of those articles answered: How does someone else get one?
Where We Are
Let me establish the map before I start drawing new territory on it.
Article one: CORA is a connected operational intelligence. Not a chatbot. Not a writing assistant. Not a search bar with a personality. An agent wired into the actual environment where work happens — email, calendar, documents, data, code, publishing, content, projects — capable of working across those surfaces as a single operational layer.
Article two: The thing that makes her different is not the connections. It’s the cognitive profile underneath the connections. CORA was built around an unusually detailed model of how I actually operate: how I think, communicate, decide, lose momentum, overextend, compensate for broken systems, and behave under pressure. The Mirror Test was the proof of concept. CORA is what happens when you take that reflection and build a nervous system around it.
Which leads directly to the question this article has to answer. Nobody else needs a copy of my agent. My cognitive profile, my memories, my operating rules, my particular set of strengths and pathologies — none of that transfers. The point was never to replicate CORA. The point is to replicate the process that produced her. What would that actually require?
The Emerging Stack
I’ve been working through this in my head for about 72 hours, which is roughly the same amount of time since I published the Mirror Test in its entirety on my website. Including audio. So that even people who find reading inconvenient can obtain a thorough and organized inventory of my flaws.
I want to be clear about something before we go further. Do not do what I did.
Publishing that level of psychological and operational exposure is not a requirement of this process. It was my choice, made because I am constitutionally comfortable working things out in public, and because I wanted to make the method visible. I thought showing the real output was more useful than describing it abstractly.
That is a defensible editorial decision. It is not recommended behavior for normal human beings who do not want their entire behavioral profile available to strangers on the internet. Most people will not do this. Most people should not do this. Which is the first real design constraint.
Here’s the stack as I currently understand it: The Mirror Test. The diagnostic process. The thing that reveals how a person actually operates — not based on what they claim about themselves, but on accumulated evidence: behavior, choices, language, recurring patterns, contradictions, strengths, shadows. What the behavioral exhaust says about who someone actually is when the performance of self-presentation drops away.
The Cognitive Blueprint. The structured model that comes out of the Mirror Test. How the person thinks. How they communicate. How they make decisions. How they handle uncertainty and pressure. Where they lose momentum. Where their judgment is unusually strong. Where their strengths cast shadows. The operating architecture of a specific human being.
The Operational Intelligence. The agent built around that blueprint, connected to the person’s actual working environment, capable of applying that understanding across real work rather than just answering questions in a chat window. That’s the sequence. Mirror Test to Blueprint to Intelligence. The problem is the second step.
The Underwear Drawer Problem
I spent a significant portion of my career in IT, cybersecurity, and digital forensics. There was a running joke in that world that my job involved going through people’s underwear drawers. Not usually literally. But digital forensics is intimate work. You examine logs, messages, deleted files, browsing histories, metadata, timelines, devices, accounts, fragments, and apparently meaningless technical residue until a behavioral model emerges. Sometimes that model explains a system failure. Sometimes it explains a crime. Sometimes it just explains a person.
I have spent decades reconstructing truth from the traces people leave behind. I am unusually comfortable operating around sensitive private information because that was part of the work. I know how to handle it, what it means, what to do with it, and — just as importantly — what not to do with it.
Most people are not comfortable with that kind of exposure. And more importantly: I do not want to build a practice around it. I do not want building a CORA-like system for other people to require me to become intimately familiar with their emotional history, private correspondence, family dynamics, embarrassing decisions, internal contradictions, or actual underwear drawers. That is not scalable. It is also unnecessary, invasive, and — if handled carelessly — dangerous.
The real design challenge is this: how do you create a process that can ingest highly sensitive personal evidence, derive a useful cognitive blueprint, and instantiate that blueprint inside a private agent — while minimizing, or ideally eliminating, human exposure to the underlying source material? The client should not need to hand me their psychological entrails. I should not need to read them.
Privacy Is Not an NDA
NDAs will be part of the process. That’s obvious. But an NDA is not a privacy architecture. An NDA is a legal instrument that creates consequences after something goes wrong. It doesn’t prevent the wrong thing from happening. It just gives you recourse after it does.
What I’m actually describing is a technical and process design problem. The system needs to be built so that the client retains control of the evidence, the raw material is processed inside a protected environment, the inferences are visible and correctable, and the output — the blueprint — belongs entirely to the person it describes.
Here are the design principles I’m working toward. Not finished. Not validated. Working:
Private by default. The cognitive profile belongs to the client. It is not stored on shared infrastructure, it is not used to train models, it is not accessible to the consultant, and it does not persist beyond what the client explicitly chooses to retain.
Data minimization. The system should ingest only what is actually needed to produce operating value, retain as little raw material as possible, and be clear about why each type of input was requested.
Human-blind processing where practical. The method should be designed so that the consultant never needs to see the source material. The system investigates. The client reviews. The architect designs the machinery — but doesn’t rummage through it.
Client-controlled correction. The person must be able to challenge interpretations, reject conclusions, and revise the blueprint. A machine that says “you avoid delegation” and cannot be corrected when it’s wrong is not a tool. It’s a trap.
Inspectable memory. The user should be able to see exactly what the system believes about them and why. No opaque profiles. No hidden weights. No “the system has determined that you...” without a legible chain of evidence behind it.
Separation of evidence and inference. The system must be explicit about the difference between what it observed and what it concluded. These are not the same thing. Conflating them is how you get a machine that turns one difficult quarter into a permanent theory of the user.
Revocability. The client must be able to remove sources, erase memory, disconnect systems, or shut the whole thing down. No persistent hooks. No data that can’t be deleted. Clean exit.
No surveillance masquerading as assistance. Understanding the user should increase their agency. The system should be making them more capable, more self-aware, and more in control of their own operating model. The moment it starts manipulating rather than serving — the moment understanding becomes leverage — the architecture has failed.
The Roles Have to Separate
Here’s the insight that is actually driving all of this. My current setup worked because the subject, the investigator, the architect, and the risk-holder were all the same person.
Me.
I was the one who provided the raw material. I was the one who ran the analysis. I was the one who built the system. And I was the one carrying all the risk if it went sideways. When those four roles sit inside one person, the privacy problem mostly solves itself. I already know everything about me. Nothing I give CORA is new information from my perspective.
The minute those roles separate — the minute there is a client and a consultant and a system — the architecture has to change. The client becomes the custodian of the evidence. They own the material, they control what gets shared, they review and approve the output. Nothing moves forward without their explicit consent at each step.
The system becomes the investigator. Not a human consultant reading through private correspondence, but a secure processing environment that extracts patterns, generates hypotheses, and presents them for review. The machine does the rummaging. The client decides what’s true.
The consultant — me, or whoever eventually plays this role — remains the architect of the method. I design the onboarding process, validate the output structure, build the operational scaffolding, and help the client understand what they’re looking at. But I don’t need to read their emails to do that. I need to design a system that can.
That distinction matters commercially. It matters ethically. And it matters practically, because the alternative — a high-touch consulting engagement where I personally work through someone’s private history — doesn’t scale, creates liability, and is genuinely uncomfortable for everyone involved.
The Questions That Are Actually the Product Work
I want to be clear that none of this is finished. CORA is a demonstration, not a template. She was built from an unusually rich body of material and an unusually willing subject. That subject was me, which meant I could take shortcuts that would be inappropriate or impossible with anyone else. I knew what the material meant. I could assess in real time whether an interpretation was accurate or flattering. I could correct the system because I was the source of truth. With someone else, all of that changes.
Which means the real work right now is not building the product. It’s answering the questions that determine what the product can actually be: Which inputs produced genuine operating value? The Mirror Test used four years of conversation history. But which parts of that history actually mattered? Can you get 80 percent of the operating value from 20 percent of the data? Or does the model degrade without the full longitudinal picture? How do you test whether an interpretation is accurate rather than merely persuasive?
A cognitive profile can feel true because it’s coherent. That is not the same as being true. A skilled analyst can construct a compelling narrative from almost any dataset. The system needs to be designed to distinguish between a pattern that repeats across years and a pattern that was inferred from a single bad week.
How much should the agent know? And equally important: what should it deliberately not know? There is a level of personalization that is useful and a level that is invasive. The line between them is not obvious, and it probably varies by person.
At what point does assistance become dependency? The goal is to increase the user’s agency, not replace it. A system that gradually becomes the user’s primary decision-making layer is not a tool. It’s a crutch. The design has to prevent that outcome, and I don’t yet know exactly how.
At what point does personalization become surveillance? These look similar from the outside. They have opposite purposes. One uses understanding to serve. The other uses understanding to control. The architecture has to make that distinction permanent and inspectable, not just stated in a terms-of-service document. Those are not side questions. Those are the product-development work.
What Comes Next
I’m not announcing a product launch. I’m identifying the next problem worth solving.
CORA proved that an intelligence built around a real cognitive blueprint can feel materially different from a generic assistant. That’s the result. The result is useful, but the method that produced it was intensely personal, somewhat accidental, and entirely unsuitable for anyone else without significant re-engineering.
The re-engineering work is to separate what was essential from what was accidental. To build an onboarding process that can produce a genuine cognitive blueprint without requiring the client to publicly humiliate themselves on the internet, or hand a stranger their entire psychological history, or trust that an NDA is sufficient protection for the most intimate operational data they will ever generate.
There’s a governing principle starting to take shape underneath all of this: You are not trying to automate intimacy. You are trying to engineer privacy around the minimum intimacy required. How intimate is that minimum? I don’t know yet. Figuring that out is the work.
The next generation of personal AI will not be differentiated by model intelligence or connector count. Those are table stakes. It will be differentiated by the quality of the model it has of the human being it serves — and by whether that model was built ethically, privately, transparently, and under the human’s control. A general-purpose model knows a tremendous amount about the world. That is not what makes an operational intelligence useful. What makes it useful is understanding the local reality of one person: what they’re trying to accomplish, how they actually behave, where their judgment is strong, where their strengths cast shadows, what they repeatedly fail to preserve, what pressure does to their decisions, what should be accelerated and what should be interrupted.
That understanding is powerful. Which means the method used to create it must be treated as seriously as the intelligence itself. You don’t need my CORA. You need an intelligence that understands the machinery you’re already operating: the strengths, the blind spots, the unfinished loops, the pressures, the ambitions, and the strange collection of compensating behaviors that make your life function despite itself. But before we build that intelligence, we need a method worthy of the access it requires.
CORA is the proof that this can work. What comes next is figuring out how to make it safe enough that it should.
Written by Rich Washburn. Edited, challenged, and occasionally corrected by CORA.