Making My AI Double

Motivation of this tool comes from my real pain point when working with Codex, for example, when asking for improve a writing, however, I still keep revising pieces of work because the output often doesn’t reflect my writing preferences and style. Or when working with a complex task, I also often need to ask Codex for more clarification before I feel ready to move to the next step.

I wish Codex could remember the small things that make working together easier: how I like an answer structured, how much explanation I need for a particular task, and when it should ask before making a consequential change. I do not want it to guess a fixed “knowledge boundary” or make a personality judgment from a few turns. But when I explicitly give it relevant context, it should help at a level I can follow and turn a vague request into a clear next step.

This is more than an assistant remembering that I like concise answers. I want continual, user-controlled personalization: a slow, self-correcting working profile that updates small hypotheses when I correct it, becomes less wrong about my preferences over time, and remains easy for me to inspect or erase.

The idea: a working profile

DoubleMe builds a set of contextual hypotheses rather than a complete story about me. It is a professional working profile, not a personality or capability model: it can represent the format I prefer for a report, the explanation depth I ask for, or when I want an agent to ask first. I can explicitly save relevant professional context, but that is not the same as the system inferring what I am capable of.

Research gives me both a reason to build this and a reason to stay humble. LaMP demonstrates that retrieving relevant profile items can improve personalized outputs across several language tasks. Yet PrefEval finds that current models struggle to proactively follow preferences over long, multi-session conversations. And Balepur et al. point out that choosing or rejecting an answer does not necessarily reveal why a particular person preferred it. I do not want a grand personality profile. I want small, contextual hypotheses that I can inspect, contradict, and replace.

For example, it may eventually hold a statement such as:

For long-form technical blog posts, I prefer the main idea first, descriptive H2 sections and a table of contents, direct links to primary sources for factual claims, and enough background to make the argument understandable.

From an interaction to a preference

The learning process is intentionally slow:

explicit request / correction / approval
                ↓
      privacy-safe observation
                ↓
   narrow, contextual hypothesis
                ↓
    inspectable working profile

One evidence-bearing independent session creates a candidate. Two independent sessions make it emerging. Three make it established. Repeated turns in the same session count only once, and newer contradictory evidence can replace an older default. A direct instruction such as DoubleMe: remember I prefer detailed reports or DoubleMe: correct DM-1234ABCD to ... takes effect immediately.

This one–two–three threshold is a deliberately conservative product policy, not a statistical proof. DoubleMe considers only recent evidence-bearing sessions for each preference dimension, so newer feedback can replace a stale default.

This distinction matters: an assistant’s response is not evidence that the user liked it. At most, the response can be reduced to a few coarse, temporary features—such as whether it was short, used bullet points, contained a table, or led with the outcome. A later explicit correction or approval from the user is what turns that information into evidence.

What DoubleMe does today

The current plugin has a deliberately narrow job: it observes explicit, work-relevant signals, turns them into a local and inspectable profile, and lets me show, correct, pin, forget, pause, or export it.

It stops there. DoubleMe does not inject a profile into Codex or Ponytail, rewrite future prompts, change permissions, approve actions, or decide that a hypothesis is true. A future authorized consumer could use an established or pinned preference, but learning a preference is not permission to act on it.

This is the model I want the rest of the post to defend: observe → form a hypothesis → let the user control it → adapt only with separate authorization.

Flow diagram showing explicit feedback becoming canonical preference features, a scoped hypothesis, and a local working profile with controls to show, correct, pin, forget, and pause. These steps sit inside a DoubleMe today boundary. A dashed arrow crosses a separate authorization gate to a muted future consumer labeled not active today, showing that the profile does not automatically change Codex or Ponytail.
DoubleMe learns a local work profile; any future adaptation must cross a separate authorization boundary.

A small form of AI observability

Agent observability usually means tracing model calls, tools, failures, costs, and outcomes. DoubleMe applies the same instinct to the human-agent boundary: make the preference-learning path visible instead of letting an opaque memory system silently change behavior.

It deliberately observes less than a general trace. The relevant unit is not “everything that happened in this conversation,” but a narrow chain: an explicit request, a privacy-safe description of the response format, and later user feedback. That makes each learned preference explainable, contestable, and removable.

Codex Hooks: the observation points

Codex Hooks let deterministic scripts run at defined points in the agent lifecycle. They can be bundled in a plugin, and non-managed hooks must be reviewed and trusted through /hooks before Codex will run them.

DoubleMe uses two lifecycle events:

Hook What DoubleMe uses it for
UserPromptSubmit Read the pending user prompt and detect explicit, allow-listed work-preference signals or commands.
Stop Reduce the immediately preceding answer to coarse presentation features so a later user correction can be interpreted safely.
Diagram with three stages: a user prompt reaches the UserPromptSubmit hook, an assistant response reaches the Stop hook, and Stop creates temporary coarse features such as short, bullets, table, and outcome first. The temporary record is labeled not evidence by itself. A later user correction or explicit approval joins it at an evidence card, which supports a scoped hypothesis.
The Stop hook summarizes presentation, but only later user feedback can turn that summary into preference evidence.

The current plugin configuration is deliberately small:

{
  "hooks": {
    "UserPromptSubmit": [{
      "hooks": [{
        "type": "command",
        "command": "python3 \"${PLUGIN_ROOT}/scripts/doubleme.py\" hook",
        "timeout": 3
      }]
    }],
    "Stop": [{
      "hooks": [{
        "type": "command",
        "command": "python3 \"${PLUGIN_ROOT}/scripts/doubleme.py\" hook",
        "timeout": 3
      }]
    }]
  }
}

UserPromptSubmit receives the user prompt, while Stop can receive the latest assistant message. The important nuance is that Stop is a turn boundary, not a reliable signal that a task has been completed. DoubleMe uses it only to summarize the response format; it never lets the agent grade its own work.

The Hooks documentation also warns that transcript_path is not a stable interface. For that reason, DoubleMe does not read transcripts. It stores canonical feature labels in a local SQLite database, hashes session and turn identifiers, and removes temporary pending-turn data after seven days. Short preference statements that I explicitly save through remember or correct become profile items; otherwise, it does not retain ordinary raw prompts, assistant responses, tool traces, or hidden reasoning.

A concrete example: Ponytail and DoubleMe

Ponytail is a useful contrast. It is a coding-workflow plugin that makes a deliberate preference operational: use the smallest correct solution, prefer existing code and the standard library, and avoid speculative abstractions. Its lifecycle hooks load the chosen mode for a session and keep that mode consistent for subagents.

Imagine that I repeatedly give Codex this instruction:

Use Ponytail. Show code first and keep the explanation concise.

Here is what happens in the current DoubleMe design:

  1. At UserPromptSubmit, DoubleMe recognizes the explicit, allow-listed signals code-first and concise. It does not store the sentence itself.
  2. Ponytail independently applies its own minimal-change discipline to the coding task.
  3. At Stop, DoubleMe records only coarse features of the answer—for example, that it was short and began with a code block.
  4. On a later turn, I might say: “That was still too long; make it concise next time,” or “This format is exactly what I want.” That explicit feedback is matched with the prior turn’s safe features.
  5. After the same preference is supported across three independent sessions, DoubleMe: show can list an established, scoped preference such as “Prefer concise responses” or “Show code before the implementation explanation.”

Ponytail remains independent today. The example shows how a future authorized consumer could use an established or pinned preference; it is not a current DoubleMe integration.

Privacy and control are product features

The most tempting implementation would be to collect every transcript, embed it, and retrieve “memories” later. I think that is the wrong default for a work-preference profile. It is hard to inspect, easy to overlearn from, and creates a much larger privacy surface.

There is another boundary I want to keep: a preference should shape how an answer is delivered, not what the answer claims is true. Research on personalized LLMs has found that personalization can pull factual answers toward a user’s prior history rather than objective truth. A future consumer of DoubleMe should therefore adapt format and collaboration style while keeping factual claims grounded in evidence, not in my profile (Sun et al., 2026).

DoubleMe keeps the profile local and narrow. It supports commands to inspect, remember, correct, pin, forget, purge, export, pause, and resume:

DoubleMe: show
DoubleMe: remember I prefer detailed reports
DoubleMe: correct DM-1234ABCD to Prefer concise technical summaries
DoubleMe: pin DM-1234ABCD
DoubleMe: forget DM-1234ABCD
DoubleMe: purge DM-1234ABCD
DoubleMe: pause

The user can correct the system faster than the system can infer. That is intentional. A profile should be revisable, contextual, and useful—not a permanent story the software tells about its user.

What I expect from this project

I am curious what an AI could notice about my working habits after we work together every day. But I do not want it to claim that it knows me better than real colleagues. A colleague sees broader context, consequences, and many things I choose not to say; DoubleMe deliberately keeps a much narrower record. Its value today is not intimacy or automatic adaptation. It is a profile that I can see, correct, pause, or delete.

The immediate goal is to make preference learning observable and falsifiable: if the system has a belief about how I prefer to work, I should be able to see why, disagree with it, and remove it. A future authorized consumer should earn the stronger claim—that it reduces repeated corrections about length, structure, explanation depth, autonomy, tests, and citations—rather than receive it by assumption.

To me, an AI double should not be a clone or a secret personality profile. It should be a transparent collaborator that learns the few work preferences I repeatedly give it—and knows exactly where that understanding ends.