Tailor Techniques

How Datailor captures, curates, and injects your personal preferences across every AI agent you use.

Table of Contents

Fundamentals

Q1After installing the MCP, does it automatically update AGENTS.md?

No. It does not update the file automatically, but it provides a one-command install path.

The MCP installation only registers the tool entry points. It does not modify the user's AGENTS.md by itself. Datailor uses the CLI command datailor install-agent-rules to write a preference summary into the marked block in AGENTS.md (<!-- datailor-preference:start --> ... <!-- datailor-preference:end -->). During first-time onboarding, this can run automatically if selected. During normal use, static rules are refreshed manually or synced through the sync-injection command.

If an older marked block already exists in AGENTS.md, Datailor replaces it instead of appending another copy.

Q2Which CLI platforms are supported? Are IDEs supported?

Runtime IDE/client integration is supported. Run datailor integrate install --client all to configure Codex, Claude Code, and Kimi Code automatically. Use --dry-run to preview changes before applying them, or datailor integrate export-plugin to generate plugin templates where supported.

Native history import is a separate layer. Datailor can directly read Claude, Codex, and Kimi history because those clients store conversations in text-based formats. Cursor and Trae are different: their native conversation stores use browser or IDE database formats such as IndexedDB or LevelDB, so direct cold-start import from those native stores still needs dedicated adapters.

In short, IDE/plugin setup means a configured client can call Datailor going forward. Native Cursor/Trae history import means reading their existing local chat databases, and that is the part not supported yet.

Q3During cold start, how does the MCP know which agent history to extract?

Datailor scans the default installation paths for known local history sources and checks whether those directories exist. Claude, Codex, and Kimi store their conversation history as JSONL text, so Datailor can read them directly once found.

Cursor and Trae are skipped only for native history import. Their existing local conversations are stored in browser or IDE database formats, so Datailor cannot reliably extract those archives without dedicated adapters. This does not block runtime IDE/plugin integration for clients that are configured to call Datailor after setup.

Cold start is automatic. When the preference library is empty, calling get_preference_decision or opening the preference panel triggers the scan.

Q4Do agents share preference data through the MCP?

Yes. Each agent's MCP configuration points to the same executable, while flags such as --agent claude identify the caller. There is one shared local preference library. Install it once, and it becomes available across supported agents.

Capture & Quality

Q5How often are preferences updated? Are there hooks during a session?

Datailor captures preferences through four layers:

1

Realtime Capture

Detects preferences as the user expresses them in conversation.

↓
2

Turn Buffer

Extracts preferences in batches after every five accumulated turns.

↓
3

Action Signals

Infers low-confidence preferences from actions such as passing tests or completed formatting.

↓
4

Session Closeout

Scans the full conversation to capture preferences that earlier hooks may have missed.

Q6When preferences are captured incrementally, does Datailor handle merges and conflicts?

Yes. Datailor handles conflicts through three layers:

  1. Semantic detection: Identifies direct contradictions such as "run tests" versus "do not run tests."
  2. Multi-dimensional comparison: Checks opposing patterns such as detailed versus concise, or ask back versus proceed directly.
  3. Human fallback: Marks conflicts automatically, but never overwrites them automatically. The user makes the final decision.

Conflicting preferences are frozen in a pending-review state and are not injected again until the user resolves them in the preference panel.

Q9How are relevant preferences selected? Does Datailor use vectors or keywords?

Datailor uses dual-track matching:

  • Recall stage: Uses vector similarity to retrieve candidate preferences from the user's conversation history.
  • Decision stage: Uses string similarity against stored preferences to decide which ones apply to the current task.

In heuristic mode, this runs entirely locally and requires no external API. It can also switch to LLM mode, where the model makes the applicability decision directly.

Q10What happens when Datailor detects contradictory preferences?

Datailor detects shifting preferences such as "sometimes run tests, sometimes do not" and handles them as follows:

  1. Automatic detection: Finds contradictory statements in conversation history.
  2. Freeze handling: Marks conflicting preferences as pending review and stops automatic injection.
  3. Realtime interception: If the top matches for the current task include a conflict, Datailor pauses injection and lets the agent ask the user to confirm.
  4. Frequency control: Asks about the same conflict at most once within 24 hours.
  5. User resolution: Supports keeping one preference, rejecting both, or rewriting a custom rule.

Q11How is confidence calculated? Frequency, recency, consistency?

Each preference has a dynamic confidence score that changes across five dimensions:

Fitting & Consolidation

Q14What is Fitting?

Fitting is Datailor's offline preference consolidation system, similar to memory consolidation during sleep.

During everyday conversations, Capture behaves like note-taking: it records user preferences as they are expressed. Over time, those notes can become messy. Some are duplicated, outdated, or contradictory. Others only become visible across sessions, such as a habit of running tests before fixing bugs, which a single session may not reveal.

Fitting periodically organizes that material:

  1. Input discovery: Scans historical conversations from Claude, Codex, Kimi, and other supported agents.
  2. Typed Insight extraction: Identifies eight pattern categories: preferences, workflows, error patterns, tool quirks, recovery strategies, handoff patterns, application habits, and personal habits.
  3. Memory Rot detection: Finds duplicate, outdated, contradictory, or user-rejected preferences.
  4. Apply Plan generation: Produces a structured change plan, with confidence and evidence attached to each change.
  5. Preference library writeback: Writes changes after user confirmation, or automatically in auto mode.

Mode integration:

  • Curate mode (default): Fitting runs automatically but only generates a plan. The user reviews it in the UI and accepts changes one by one.
  • Auto mode: High-confidence preferences are applied automatically. The rest are reported without being written, so the process stays mostly invisible to the user.

Artifacts are saved under <user-data>/.fitting/jobs/<job_id>/, including a human-readable report.md and a machine-readable apply-plan.json. The exact location depends on your OS: %APPDATA%\Datailor on Windows, ~/Library/Application Support/Datailor on macOS, or ~/.local/share/datailor on Linux.

Q15What is the difference between Fitting and Capture?

DimensionCaptureFitting
TimingRealtime or near-realtime.Offline and periodic.
TriggerEvery conversation turn, every five-turn flush, and session close.Session accumulation threshold, defaulting to at least five new preferences, or a time threshold, defaulting to seven days.
GranularitySingle-preference extraction.Cross-session pattern refinement, global deduplication, and rot detection.
OutputWrites directly to the preference library.Generates a report and plan, then writes back after review or auto-apply.
Library modificationWrites directly.Read-only by default; modifies the library only after apply.
User visibilityMostly invisible in the background.Requires user review in curate mode; mostly invisible in auto mode.
AnalogyTaking notes.Organizing the notes.

Relationship: Capture accumulates preferences, while Fitting organizes them. Together, they form the self-improvement loop. Without Capture, Fitting has no material to consolidate. Without Fitting, the preference library accumulates redundancy and contradictions.

Fitting x Mode Integration

V0 connects Fitting to Datailor's mode system through two explicit modes. Both modes can run automatically after hook thresholds are met; the difference is how much writeback is allowed.

Curate mode

The default review-first mode. Hooks check trigger conditions after session close or turn-buffer flush, then run Fitting when enough new material has accumulated.

  • Generates a pending_review plan.
  • Writes back only after explicit UI, CLI, or MCP acceptance.
  • Best for preserving user control and auditability.

Auto mode

The low-friction mode. Hooks still trigger Fitting automatically, but writeback is filtered through safety and confidence gates.

  • Automatically applies only low-risk, high-confidence preference changes.
  • Records workflow, error_pattern, and memory-rot suggestions without auto-writing them.
  • Best for stable defaults that should quietly improve over time.
Auto trigger
Session end hook Turn-buffer flush New preference threshold Cooldown and time thresholds

Injection & Observability

Q7How does a user open the HTML panel to view their Manifesto?

Run the CLI command datailor ui. Datailor starts a lightweight local HTTP server, defaulting to 127.0.0.1:8080, and opens the browser to the preference panel.

The panel includes six views:

  • All: A searchable list of all preferences.
  • Pending: Newly captured preferences awaiting confirmation.
  • Conflicts: Detected contradictory preference pairs that the user can resolve.
  • Evolution: A timeline of how preferences change over time.
  • Injection: Recent records of preferences that were actually injected.
  • Settings: Runtime mode selection, including auto, autonomous, and curate modes, plus theme controls.

The onboarding flow also supports --open-ui, which opens the panel after cold-start scanning finishes.

Q8Does Datailor currently implement preference injection logic?

Datailor provides four layers of preference injection:

Static Rules

Written into AGENTS.md / .cursorrules

Read automatically when the agent starts.

Session Prewarm

Generates a session-specific cache

Matches preferences for the current task.

Realtime MCP

get_preference_decision

Called by the agent before each response.

Local Fallback

fallback_rules.md

Used as a baseline when the MCP is unavailable.

Note: Realtime injection depends on the configured client or plugin calling Datailor. datailor integrate handles supported Codex, Claude Code, and Kimi Code setup. Native Cursor/Trae history import is a different problem: it requires adapters for their local database-backed conversation stores.

Q12Is preference injection observable? How can users know what actually took effect?

Yes. Datailor exposes three transparent paths:

Injection Log

.injection-log.jsonl

Records every MCP decision event, including time, context, preference ID, confidence, and whether it took effect.

UI Panel

Injection Tab

Shows the latest 200 injection records and groups them into injected, reported, and no-match statistics.

Feedback Loop

Confirm / correct / reject

User feedback adjusts priority and produces recommendations such as promote, stable, or review_needed.

Q16Which hooks and tools does the repository provide?

Datailor implements five session lifecycle hooks plus Fitting-related tools:

H1 hook_session_start

Runs at session start. It prewarms the preference cache and generates the preference instructions that should apply to the session.

H2 hook_user_message

Runs when each user message arrives. It retrieves relevant preferences and returns the instructions the agent should follow before responding.

H3 hook_turn_complete

Runs after each turn. It buffers turn data and extracts preferences in batches once five turns accumulate.

H4 hook_action_executed

Runs after actions such as passing tests or completing formatting. It generates low-confidence pending preferences from behavior signals.

H5 hook_session_end

Runs at session end. It flushes the turn buffer, captures the full conversation, syncs injection artifacts, and checks whether Fitting should run.

Fitting-related MCP tools:

ToolPurpose
start_fittingStarts a Fitting job, with support for instructions and dry runs.
get_fitting_statusChecks the status of a specific or latest Fitting job.
apply_fitting_planApplies user-approved changes. It requires explicit accepted_change_ids.

Other tools:

ToolPurpose
get_preference_decisionGeneral preference decision lookup.
capture_preferences_from_sessionCaptures preferences from a specific session file or directory.
report_preference_feedbackRecords user feedback, including confirmation, correction, or rejection.
resolve_preference_conflictResolves preference conflicts.
sync_preference_injectionSyncs injection artifacts into AGENTS.md or .cursorrules.
open_preference_panelStarts the local preference panel.

Internationalization

Q13How does Datailor handle multilingual text and encoding?

Datailor uses UTF-8 throughout, so multilingual text has no special encoding risk.

All text storage, including the Markdown preference library, JSONL logs, and HTML pages, uses UTF-8. JSON serialization disables ASCII escaping with ensure_ascii=False. HTML pages declare <meta charset="utf-8">, and CLI output is forced to UTF-8. Multilingual preference content, evidence excerpts, and conflict notes can be read, written, and displayed normally.