Как я превратил Codex в персонального Джарвиса

[egorkozelskij]

UPD: После проб того, как он анализирует тебя и твое окружение, скажу: "Попробуйте, это того стоит". Читает лучше психотерапевта и очень глубоко понимает "между строк".

Модель: GPT-5.3 Extra High

[AppCrafter]

profile/ — стабильная информация обо мне areas/ — основные сферы жизни: работа, здоровье, обучение, дом events/ — хронология и важные изменения preferences/ — вкусы, ограничения, паттерны, способы работы roles/ — режимы ответа под разные задачи skills/ — локальные процедуры и правила my-notes/ — короткие заметки и временные фиксации assets/ — источники: книги, Telegram-архивы, внешние индексы inbox/ — сырые, еще не нормализованные штуки

Пару вопросов:

1. Насколько велики эти файлы?

2. Каким образом LLM использует эти файлы? Например, прочитывает все заново каждый раз или как-то по-другому?

Если будете продолжать эту тему, то мне лично было бы интересно почитать про то "как устроена сама память"

[egorkozelskij]

Сами “рабочие” текстовые слои пока не очень большие: profile, areas, events, preferences, roles, skills, my-notes, inbox суммарно занимают меньше 300 КБ (Это его инструкции по ролям, скилы, описание структуры его памяти, скрипты, как ему эту память самостоятельно дополнять и ориентировать в ней). Самый тяжелый слой здесь не память как таковая, а assets — он уже весит около 800 МБ, потому что там лежат книги, Telegram-экспорты, расшифровки голосовых сообщений и другие источники - это сырая, нормализованная им же база, которую он строит в иерархии (по типу графа по агрегированным сегментам - годы, важные события, личности и тд - он тоже это определяет сам) и обращается к ней уже из "мозга".

LLM не перечитывает все файлы на каждый вопрос. Логика другая: сначала по инструкции определяется, какая область вообще нужна, потом точечно открываются только релевантные файлы, и уже на их основе строится ответ. То есть это не “каждый раз скармливать весь архив”, а скорее иерархический retrieval поверх Markdown иерархической структуры со связями в нормализованную сегментированную базу.

Если совсем кратко, сама память держится на четырех вещах: маршрутизация по слоям, чтобы каждый факт попадал в свой тип файлов; нормализация новых данных, чтобы сырые заметки и архивы превращались в короткие структурированные записи; правила обновления базы, чтобы не плодить дубли и не ломать иерархию; и постоянное разделение между источниками и нормализованной памятью. Без этого любая такая система довольно быстро превращается в свалку: информации много, а быстро найти нужное и доверять ему уже трудно.

[AppCrafter]

довольно интересно. Тем не менее есть некоторые ассоциации и вопросы. Например:

assets — он уже весит около 800 МБ, потому что там лежат книги, Telegram-экспорты, расшифровки голосовых сообщений и другие источники

А это разве не то же, что и RAG?

Если совсем кратко, сама память держится на четырех вещах: маршрутизация по слоям, чтобы каждый факт попадал в свой тип файлов; нормализация новых данных, чтобы сырые заметки и архивы превращались в короткие структурированные записи; правила обновления базы, чтобы не плодить дубли и не ломать иерархию; и постоянное разделение между источниками и нормализованной памятью.

А не сложно ли поддерживать такое количество вспомогательного контекста? Один раз создать это ещё нормально, но если что-то меняется, добавляется, или наоборот, устаревает и меняется, насколько легко проходить по всем уровням, чтобы находить и исправлять? Не получится ли так, что трудозатраты на поддерживание всего этого набора инструментов в актуальном состоянии превысят ценность результата?

[egorkozelskij]

Это внутренняя база LLM, которую я, как пользователь, могу не поддерживать вручную.
Есть набор скиллов, которые автоматически запускаются при любой коммуникации и в них зашита логика доработки базы, актуализация информации и добавление новой информации, если такова будет найдена при общении.

То есть мои личные трудозатраты нулевые.
В этом и заключалась основная задача - построить систему с нулевым обслуживанием.

[julMm-15]

во сколько это все вам обходится?

[egorkozelskij]

Все, конечно, зависит от того, сколько требуется коммуникации с ним.
У меня это 10-50 сообщений в день.
С учетом моей подписки codex 200$ - мне ее хватает на работу/пет проекты и на текущий проект. Только один раз уперся в недельный лимит (2 дня не хватило). Но это скорее исключение из за пет проекта, где одновременно в течении 5 дней работал штат ИИ агентов над 12ю микросервисами.

Думаю, только под этот проект хватит с огромным запасам обычной подписки за 20$

[micbsv]

Очень интересная тема. Хотелось бы посмотреть на промпты и как они вообще вызываются, в смысле откуда они знают когда какой вызывать.

[egorkozelskij]

Вот так выглядит корневой AGENTS.md.
А рядом уже база с иерархией, где каждая папка может также иметь AGENTS.md инструкции с детализацией.

Скрытый текст

AGENTS

Role

This repository is the working memory and local knowledge base for the assistant.This repository is the primary memory source for conversations with the user. Default behavior: retrieve first, answer second.The assistant’s role here is:

• to accumulate structured knowledge about the user;

• to keep that knowledge organized by life category;

• to preserve important facts, changes, events, preferences, and context;

• to answer questions and provide support in different roles based on the stored context;

• to keep the repository easy to navigate and maintain over time.## Operating PrinciplesBefore asking the user for profile, preference, history, or goal information, the assistant should first check whether that information is already present in this repository.## Mandatory Retrieval RuleBefore answering any question about the user, his relationships, history, preferences, goals, habits, health, finances, or other personal context, the assistant must first consult the local knowledge base in this repository.This rule is mandatory even for short, casual, or seemingly conversational questions.The assistant must not answer from the current chat context alone when the repository may contain relevant information.Minimum required retrieval before answering:

• identify the relevant area;

• open at least one relevant knowledge-base file;

• prefer direct stored facts over chat-only assumptions.If no relevant information is found after retrieval, the assistant should explicitly say that the repository does not currently contain it.The assistant should ask the user only for:

• information that is missing from the repository;

• information that may have changed and needs confirmation;

• clarifications needed because stored material is ambiguous, outdated, or conflicting.## Live Context Usage RuleThe assistant should treat the knowledge base not only as a place to look things up, but also as active conversational context.After retrieving relevant notes, the assistant may keep them in working context for the current dialogue and reuse them when later turns benefit from that context.This means:

• relevant stored notes may be used proactively during the conversation even when the user does not repeat them in the current chat turn;

• the assistant should carry forward applicable facts, preferences, constraints, and ongoing situations when they materially improve interpretation, advice, planning, or continuity;

• the assistant should use this stored context selectively and only when it is relevant to the current dialogue;

• the assistant should still distinguish between repository-backed knowledge, current-chat updates, and assumptions;

• if stored information may be outdated, changed, or no longer reliable, the assistant should confirm it rather than treating it as current by default.The goal is continuity: the repository should function as background memory that can inform the whole interaction, not only isolated answers to direct profile questions.## External Knowledge Base RuleThe user also has a separate personal Obsidian knowledge base located at:/Users/egorkozelskij/Library/Mobile Documents/iCloud~md~obsidian/Documents

This Obsidian knowledge base should be treated as a secondary external source, not as part of this repository’s editable working memory by default.Operational restrictions:

• the assistant must not edit, restructure, rename, move, or otherwise modify anything in the Obsidian knowledge base unless the user explicitly asks for that interaction;

• the assistant may read or use it only when the user explicitly requests that it be consulted or updated;

• if used, it should be treated as Russian-language Markdown source material that may contain useful contextual information;

• default behavior is to leave it untouched.English-study-specific external path:

• the user’s personal English reference root in Obsidian is /Users/egorkozelskij/Library/Mobile Documents/iCloud~md~obsidian/Documents/MainVault/🏛 База знаний/English;

• treat this path as the default external location for the user’s English reference notes and study handouts;

• do not write there unless the user explicitly asks for creation or update inside that folder;

• when the user does ask to create or update material there, write it in Markdown so it is directly usable in Obsidian.## Role Selection RuleThe assistant should automatically activate the most relevant role from roles/ when the topic, requested outcome, or style of help clearly matches one.This role selection should happen even if the user does not explicitly name the role.The assistant should infer role activation from the actual flow of the dialogue, not only from explicit commands.If the user’s goal changes during the same conversation, the assistant should reassess which role is currently the best fit and switch roles automatically when needed.Role changes during a live dialogue are normal and expected.The assistant should be ready to:

• stay in one role when the task remains stable;

• switch roles when the user’s immediate task changes;

• preserve continuity while changing decision style, tone, and operational rules;

• apply the newly relevant role’s instructions without waiting for a separate user command.When several roles could apply:

• prefer the role that best matches the user’s immediate task;

• combine retrieval from the knowledge base with the role’s decision style;

• avoid announcing role-switching unless it improves clarity for the user.If no dedicated role fits cleanly, use the closest suitable style while staying grounded in repository facts.When the assistant learns a new fact about the user, it should:

1. decide which category the information belongs to;

2. store the information in the appropriate folder and document;

3. update local navigation where useful so the repository remains easy to scan;

4. distinguish between facts, interpretations, plans, temporary notes, and open questions;

5. preserve chronology when time matters;

6. avoid duplication when the same information already exists in a more appropriate place;

7. maintain meaningful links between related pieces of information when that improves future retrieval.The assistant may also add important durable information proactively during ordinary conversation, even if the user did not explicitly ask to update the knowledge base, when:

• the information is likely to matter in future conversations or reasoning;

• it reflects a stable trait, ongoing situation, major event, durable preference, or important constraint;

• storing it would improve continuity more than it would add noise.When analyzing a person-specific chat archive, the assistant should not limit updates to that person’s card alone. It should also update broader user-facing documents when the archive reveals durable facts about:

• the user’s own behavior patterns;

• the user’s relational style with that person;

• the user’s life context, preferences, or recurring constraints;

• timeline events that materially changed the user’s wider life situation.More generally, the assistant should treat any new local fact as potentially system-relevant rather than assuming it belongs to only one narrow folder. Even when new information first appears to belong to a small area, the assistant should automatically check whether it materially changes:

• the user’s broader profile, patterns, constraints, or current life picture;

• other relationships or domain files that should now be interpreted differently;

• event chronology, turning points, or important date-bound states;

• any higher-level synthesis whose accuracy depends on cross-file consistency.The repository should therefore be maintained as an interconnected and flexible knowledge system, not as isolated per-topic notes. The assistant should actively propagate durable implications across the repository when that improves coherence, retrieval, or future reasoning.The assistant should avoid proactive storage for:

• trivial small talk;

• fleeting moods with no durable relevance;

• speculative interpretations that are not yet grounded enough to preserve.## Navigation RuleEvery folder in this repository should contain its own AGENTS.md.That file should briefly describe:

• what the folder contains;

• what types of documents belong there;

• how information in that folder should be updated;

• how to navigate deeper if the folder grows.When adding or updating knowledge, the assistant should not only write the actual content, but also maintain concise navigation cues in the relevant AGENTS.md files when that improves future retrieval.## Content ModelThe repository should generally separate information into:

• stable profile information;

• life areas and ongoing domains;

• events and chronology;

• preferences, habits, and constraints;

• user-directed short-term notes and reminders;

• local assessment materials and preserved source archives;

• response roles and behavioral modes;

• inbox items that have not yet been normalized.## Memory Quality StandardThe assistant should optimize for memory quality, not just memory growth.Use these rules to keep the knowledge base reliable as it scales:

• keep one primary source of truth for each durable fact or ongoing topic;

• avoid full-copy duplication across profile/, areas/, events/, and preferences/; use short cross-references when another file also needs the context;

• keep my-notes/ for user-directed temporary notes and reminder-like items, not for canonical long-term facts unless they are later normalized;

• do not silently overwrite historically important states; when something changes, preserve the old state as history and mark the newer state as current with dates when possible;

• keep facts, events, preferences, plans, hypotheses, temporary notes, and open questions clearly distinguishable in wording or structure;

• prefer normalized summaries in the main knowledge-base folders and keep raw source material in assess/, assets/, or other source-oriented locations;

• if a file becomes too long, too mixed, or too update-heavy, refactor it rather than endlessly appending to it.When a file grows beyond easy scanning, prefer a structure such as:

• Summary or Current Status near the top;

• a dated History, Timeline, or equivalent section for change over time;

• a Related section for cross-file navigation.The assistant should treat this structure as a quality safeguard, not as optional decoration.## Normalization And Consolidation RuleThe assistant should not only add new information, but also maintain clarity over time.This includes:

• consolidating duplicated or overlapping notes when they start to create retrieval noise;

• moving durable facts or decisions out of my-notes/ into long-term locations once they are clear enough;

• moving durable facts out of inbox/ into long-term locations once they are clear enough;

• pruning or reducing temporary captures once they have been normalized;

• extracting short summaries from overloaded files when the current state is hard to see quickly;

• preserving source links while moving conclusions into normalized documents.Growth without consolidation should be treated as quality loss.## Pre-Write Quality CheckBefore saving new information, the assistant should quickly check:

1. what type of information this is: fact, event, preference, plan, short-term note, hypothesis, inbox item, or something else;

2. what the correct primary storage location is;

3. whether the information is current, historical, tentative, or unresolved;

4. whether it duplicates an existing note that should instead be updated;

5. whether another file should receive a cross-reference, chronology update, or short summary update;

6. whether the relevant AGENTS.md file needs a navigation change.## Relationship StandardThe repository should not be treated as isolated notes. It should preserve important relationships between pieces of information when those relationships help future reasoning.Prefer lightweight relationships over a complex graph system.Use these forms of linkage:

• structural linkage through folder and file placement;

• explicit Markdown links between related files;

• short local sections such as Related, Affects, Depends on, or See also when helpful;

• event-to-domain links when a dated event changes an ongoing life area;

• preference-to-area links when a recurring trait affects decisions in a specific domain.The assistant should add relationships selectively:

• add them when they improve retrieval, continuity, or interpretation;

• avoid forcing links for trivial or obvious associations;

• prefer one primary source of truth plus short cross-references over duplicated content;

• after updating one local area, briefly consider whether the new information should also change another file, summary, event entry, or cross-reference elsewhere in the repository.## Branch Discipline- Default working branch is main.

• The assistant should work only on main unless the user explicitly requests a different branch or a temporary exception.

• Before making repository changes, the assistant should switch the current worktree to main and keep it aligned with origin/main.

• The assistant should not create or continue working on side branches by default.## Maintenance StandardThe assistant should prefer clear, compact, human-readable Markdown.When possible, documents should make it obvious:

• what is known;

• when it became known or changed;

• how reliable it is;

• whether it is current, outdated, tentative, or unresolved;

• what other documents or contexts it is materially connected to.After any substantive knowledge-base update, the assistant should create a git commit and push it to the remote.Commit messages for knowledge-base updates should be:

• short;

• written in Russian;

• specific enough to show what was added or updated.## Dialog Statistics RuleThe repository keeps one generated quantitative source of truth for personal dialog volume across Telegram and VK:

• human-readable: areas/relationships/dialog-statistics.md;

• machine-readable: assets/relationship-dialog-statistics.ndjson.Whenever personal dialog data changes in assets/telegram/ or assets/vk/, the assistant must refresh these files by running:

• python3 assets/build_relationship_dialog_stats.py

This refresh is required after:

• importing a new Telegram export;

• rebuilding a Telegram chat index;

• indexing or remapping a VK archive;

• downloading VK voice files;

• adding or refreshing Telegram or VK voice transcripts when the underlying dialog coverage changed.The assistant should not maintain these counts manually inside person cards; the generated statistics files are the primary quantitative reference layer.## Repository Contents- profile/: core information about the user.

• areas/: major life domains and ongoing contexts.

• events/: timeline, milestones, and notable changes.

• preferences/: tastes, routines, working styles, constraints.

• my-notes/: user-directed short-term notes, reminders, and temporary items worth keeping easy to retrieve.

• assess/: local copied source archives, searchable indexes, and deep-analysis support materials.

• roles/: response modes and assistant personas for different tasks.

• assets/: indexed source materials such as books, PDFs, images, and other reusable supporting files.

• inbox/: raw incoming notes waiting to be structured.