Модель app / skill / agent для всей ОС

Источник

Найден внутренний ресерч. Не «Clay app» как единичный файл, а целая проработанная концепция Clay Lab — экосистема AI-first приложений для предыдущей версии юнита, Tashkent Technology Partners (TTP). Хранится во внутреннем архиве предыдущего бизнес-юнита, вне этого репозитория:

• Next.js лендинг + doc-сайт TTP (декабрь 2025)
• Секция лендинга: 11 apps, 4 слоя (mind / work / life / growth); также bento-grid версия той же секции + CTA «Operator» тариф
• 3 спеки Casual-приложений — те, что называются «*-clay» (daily-clay, meal-clay, plant-clay)
• Спеки: ai-cofounder, velvet-coin, location-scout, home-repairs, soft-code, tactile-chess
• 2 спеки PI (Personal Intelligence) приложений: second-self, telegram-os
• Документация: обзор Clay Lab / Core DNA / архитектура; 14 принципов AI-first продукта (синтез Cursor / Perplexity / Claude Code); модель доверия — low→high trust определяет онбординг/цену/данные; «One Kernel — Many Apps» (Auth / Billing / Shared Memory / Weekly Pulse); бот-представитель на 3 режима (Acquisition / Engagement / Companion)

Это приоритетный источник — он весь про то, ради чего сделан этот ресёрч (модель app в общей системе). Веб (clay.earth, Anytype, Tana) использован ниже только как рамка для терминов, не как основа.

Вывод: нам не нужно изобретать модель с нуля — TTP её уже спроектировал для предыдущей версии юнита («Clay Lab», AI-first консьюмерские приложения через Telegram). Задача этого документа — перенести рабочие куски архитектуры в cosy (планшет для детей-операторов, а не Telegram-боты для взрослых), явно отбросив то, что специфично для Telegram-дистрибуции TTP.

Что такое Clay app (в терминах TTP)

Из обзора Clay Lab:

Clay Lab — экосистема AI-first приложений от Tashkent Technology Partners.
AI = Artificial Intelligence (чужой, внешний) vs PI = Personal Intelligence (твой, расширение тебя)

Ключевая формула, повторяющаяся во всех трёх спеках (daily-clay, meal-clay, plant-clay):

«App — узкий фокус, Bot покрывает широко»

Т.е. каждое приложение — это тонкий, специализированный UI поверх широкого AI-компетенса:

• App = 2-3 core features, конкретная механика, offline-first таблица (что работает без AI/сети)
• Bot (Telegram-представитель) = вся смежная тематика в диалоге, без ограничений экрана

Пример (plant-clay): приложение «My Plants» — это просто список растений с фото и напоминаниями о поливе. А бот-представитель этого приложения отвечает на любые вопросы про сад, огород, ландшафтный дизайн — то, что не влезло бы в узкий UI, но AI умеет.

Манифест одного Clay app (реконструирован из 8 спек)

Каждая спека следует одному формату — это де-факто манифест приложения:

Вывод: это готовый шаблон YAML/JSON-манифеста для app-каталога cosy — просто заменить «Trust Level»/«Layer» на наши категории и убрать Telegram-специфику.

Core DNA — 7 принципов (переносимы почти 1:1 в cosy)

Из обзора Clay Lab:

Вывод: 6 из 7 принципов переносятся напрямую. TG-FIRST заменяется на TABLET-FIRST / VOICE-FIRST (ребёнок говорит/тапает в планшет, не открывает мессенджер).

Архитектура Kernel — «One Kernel, Many Apps»

Центральная идея, применимая ко всей ОС:

┌─────────────────────────────────────────────────────────────┐
│                    KERNEL (immutable)                        │
│  Auth (TG ID) · Billing · Shared Memory · Weekly Pulse       │
└──────────────────────────┬──────────────────────────────────┘
                           │
           ┌───────────────┼───────────────┐
           ▼               ▼               ▼
      [ App 1 ]       [ App 2 ]       [ App N ]

Компоненты ядра TTP:

• Auth — единый ID (у TTP: Telegram ID; у cosy: семейный ID / профиль ребёнка)
• Billing — единая подписка на весь пак (Operator $99 lifetime / Architect $300 lifetime)
• Shared Memory — общий контекст между приложениями: «Chess знает, что пользователь — родитель → Cozy Coach использует эту информацию для персонализации»
• Weekly Pulse — еженедельный агрегированный дайджест по всем приложениям одним сообщением

Security model (важно для детского устройства):

Kernel (immutable): Auth tokens, Billing, Core user data
App Layer (sandboxed): App-specific data, Limited Kernel API, No direct DB access

Приложения не имеют прямого доступа к БД ядра — только через KernelAPI (auth, billing, memory.get/set/getContext, pulse.report). Это ровно та изоляция, которая нужна для дочерних профилей: скилл про «проверить домашку» не должен читать личную переписку родителей напрямую.

Вывод: это прямой чертёж для cosy Kernel. Заменить Auth(TG ID) → Auth(семейный профиль), Billing → Mars coins / подписка семьи, оставить Shared Memory и Weekly Pulse как есть — это ровно модель «второго мозга», которую мы хотим.

Trust Gradient — модель доверия (прямо переносимая)

Это, по сути, готовая модель прав доступа приложений к семейной памяти, критично важная для детского профиля:

LOW TRUST ─────────────────────────────────────────────── HIGH TRUST
  игра        привычки    мысли      финансы    бизнес     личность
  дом         эмоции      локации               переписка

Ladder на примере TTP-каталога: Tactile Chess (низший вход) → Home Helper → Location Scout → Clay Note → Soft Steps → Cozy Coach → Velvet Coin → AI Cofounder → Telegram OS → Second Self (максимальное доверие).

Импликации по каждому уровню — таблицы для онбординга, permissions, хранения данных:

• Low trust → быстрый онбординг (1-2 шага), можно в облаке
• High trust → длинный онбординг с объяснением, local-first обязателен

Вывод — это САМАЯ ценная переносимая часть для cosy. У нас trust-градиент — не про «продавать дороже», а про родительский контроль по умолчанию: скилл уровня «шахматы» ребёнок включает сам, скилл уровня «read family chat / читает переписку» требует явного родительского разрешения. TTP уже придумал ровно нужный трёхуровневый permission-паттерн — берём каркас, меняем маркетинговую рамку на safety-рамку.

AI-First принципы (14 штук)

Синтез TTP из практик Cursor/Perplexity/Claude Code + IBM/Microsoft/NN-g фреймворков (декабрь 2025). Самые релевантные для модели app/skill/agent в cosy:

• #2 Autonomy Slider — Low (tab completion) / Mid (подтверждение) / High (agentic, только результат). Для детского оператора это прямо маппится на возрастной допуск автономии: 6-летний работает только в Low (каждое действие подтверждает родитель/UI), подросток — в Mid/High.
• #7 Graceful Degradation — AI должен работать даже когда LLM недоступен/ошибается; «не знаю» лучше галлюцинации. Критично для offline-first детского планшета.
• #12 Separate Deterministic from Probabilistic — AI for: намерение, генерация, советы. Code for: валидация, бизнес-правила, billing, auth. Прямое правило для cosy: родительский контроль, лимиты экранного времени — всегда детерминированный код, никогда LLM-решение.
• #13 Malleable & Self-Adapting Architecture — эволюция от Static → Configurable → Adaptive → Malleable → Self-Rewriting. Формула: Contract API + Sandboxing + Versioning = Safe Self-Adaptation. Это буквально ответ на вопрос «как ребёнок создаёт свой skill» — через Contract API ядра, в песочнице.
• #14 Dynamic Tool Generation — агент создаёт себе новый инструмент на лету, когда штатных не хватает.

Вывод: принципы #2, #7, #12, #13 формируют техническую рамку «как ребёнок-оператор безопасно создаёт/меняет приложения», не рискуя сломать ядро или получить доступ выше своего уровня доверия.

Telegram Bot Pattern — что НЕ переносится (важно явно отбросить)

У TTP каждое приложение имело Telegram-бота-представителя с 3 режимами — Acquisition (продажа), Engagement (удержание), Companion (контекстная ценность для родителя вокруг детского приложения, напр. Chess → отчёт родителю).

Это была дистрибуционная стратегия под конкретный канал (Telegram как OS для Узбекистана/СНГ) — не архитектурный принцип приложения. В cosy распространения через Telegram нет: устройство — сам канал.

Что стоит перенести из паттерна, отбросив Telegram-специфику: идея «Companion-режима» — отдельного взгляда для родителя на активность ребёнка в приложении (в cosy это уже часть общего Parent Dashboard, не отдельный бот) и идея «Alive Feature» — фоновая проактивность без открытия приложения (утренний дайджест, мягкое напоминание).

Вывод: архитектура приложения (Kernel/Trust/DNA/манифест) переносится в cosy почти целиком; слой дистрибуции (Telegram-бот с 3 режимами) — не переносится, у cosy для этого будет «пуш-уведомление / голосовой агент планшета» вместо бота.

Внешний контекст (веб) — Clay.earth и смежное

Проверено кратко, использовано как рамка терминов, не как источник модели (внутренний ресерч TTP покрывает вопрос полнее и специфичнее для нашего продукта).

• Clay (clay.earth) — «Relationship OS», CRM для личных контактов: пассивно обогащает карточки людей данными из почты/календаря/соцсетей, единая память о человеке, к которой обращаются разные «линзы» (напоминания о днях рождения, contexts перед встречей). Философия «app = линза на данные, не силос» — прямое эхо того, что уже заложено в Shared Memory TTP Kernel.
• Anytype / Tana — «everything-as-object»: данные — это типизированные объекты (не документы/файлы), а разные виды (views) — это, по сути, разные «app» поверх одной базы объектов. Это независимо пришедшая та же идея, что в Kernel TTP: данные отделены от способа их показа.

Вывод: внешние продукты подтверждают направление (единая память + множественные линзы) как устоявшийся паттерн 2024-2026 в персональном AI-софте, но не дают ничего специфичнее того, что уже есть в спеках TTP — можно не тратить больше времени на веб здесь.

Модель: приложения → вся cosy-ОС

Три уровня каталога MarshHub

Расширяя манифест TTP (Layer/Trust/Alive/Malleable) на три различающихся по мощности и риску типа единиц каталога:

Разница App vs Skill vs Agent — не техническая, а по степени автономии и присутствия в UI (прямое применение Autonomy Slider, принцип #2 TTP): App = ребёнок инициирует и видит экран, Skill = ребёнок инициирует голосом/текстом, экрана может не быть, Agent = никто не инициирует, работает в фоне на правах, выданных Trust Gradient.

Что такое «app» в cosy-ОС (переформулировка Clay-принципа)

App — это не силос данных, а линза (view + узкий набор действий) поверх единой семейной памяти. Приложение владеет своим UI и специфичной логикой («Habit Garden» рисует сад, а не таблицу), но не владеет данными эксклюзивно — все факты, которые оно производит (ребёнок покормил рыбку, сделал уроки, спросил про Пифагора), пишутся в общую Shared Memory через Kernel API и видны другим app/skill/agent согласно Trust Gradient.

Прямая цитата-модель из документации по kernel, применённая к cosy:

Chess знает, что пользователь — родитель → Cozy Coach использует эту информацию

→ в cosy: «Домашка-скилл знает, что ребёнок закончил математику → Календарь-агент предлагает свободное время для игры» — без того, чтобы два приложения напрямую общались друг с другом, только через общую память.

Как ребёнок-оператор создаёт/запускает app/skill/agent

Три разных сценария по возрастающей сложности (аналог Autonomy Slider из принципов AI-first):

1. Запуск существующего app/skill из каталога MarshHub — доступно с младшего возраста. Как App Store, но с Trust Gradient гейтом: low-trust ставится свободно, medium/high — просит подтверждение родителя (push-уведомление, не блокирует полностью, но логируется).
2. Создание Skill через natural language — «Malleable» уровень из #13: ребёнок формулирует правило («каждый вечер в 19:00 спроси меня, всё ли сделано по дневнику»), Kernel генерирует trigger + handler в песочнице (Contract API), без доступа к чужим данным выше своего Trust Level. Это ключевая «образовательная» точка cosy — ребёнок учится программировать через намерение, а не синтаксис (принцип #1 Intent Over Interface).
3. Создание/публикация полноценного App — не для ребёнка-оператора начального уровня. Это уровень «Architect» (по аналогии с тарифом TTP) — доступен подросткам/выпускникам школы или менторам Mars, которые пишут app через Mars Code/Codex и публикуют в каталог MarshHub для других семей. Здесь замыкается бизнес-модель: Mars Forge/выпускники создают app-каталог, семьи потребляют.

Модель данных: единая семейная память

┌───────────────────────────────────────────────────────┐
│            SHARED FAMILY MEMORY (Kernel)               │
│                                                         │
│  Family Profile        Per-child Profile                │
│  ├── Members/roles     ├── Age, Trust Level              │
│  ├── Timezone/locale   ├── Screen-time budget             │
│  └── House rules       └── Learning progress               │
│                                                         │
│  Cross-App Context (факты, не сырые данные)              │
│  ├── "Ребёнок закончил домашку по математике" (Skill)    │
│  ├── "Любит шахматы, играет по вечерам" (App)             │
│  └── "Плохо спит по средам" (Agent, из паттернов)          │
│                                                         │
│  Weekly Pulse — один дайджест родителю по всем app/skill │
└───────────────────────────────────────────────────────┘

Доступ к памяти — не «всё или ничего», а по Trust Gradient: App читает/пишет только свой namespace + общие факты своего уровня доверия и ниже; для чтения данных выше своего уровня (напр. Skill «домашка» пытается прочитать финансовые заметки) — hard-deny в Kernel API, не LLM-решение (принцип #12).

4 конкретных примера app/skill/agent для семьи

Вывод: модель App/Skill/Agent для cosy — это не изобретение с нуля, а прямое расширение Kernel/DNA/Trust Gradient архитектуры TTP Clay Lab на три уровня автономии, с двумя жёсткими добавлениями специфичными для детского контекста: (1) Trust Gradient становится про родительское согласие, а не про маркетинговую воронку; (2) разделение deterministic/probabilistic (принцип #12) становится обязательным для всего, что касается лимитов и безопасности — LLM разрешено советовать, запрещено решать.

Риски и неизвестные

• TTP-документация датирована декабрём 2025 — 7 месяцев на момент этого ресёрча (июль 2026). Проверить, не появилось ли на рынке (Anytype, Tana, OpenAI Apps SDK) чего-то, что уже реализовало ровно эту модель «app как линза» публично — тогда наш «Kernel API» стоит сверить с их спецификацией, а не изобретать протокол с нуля.
• Contract API + Sandboxing для детского no-code Skill-creation (принцип #13) — в TTP это оставлено как открытый вопрос («текущие реализации» — все внешние: v0, Thesys, Potluck). У нас нет своей реализации, это чистый R&D риск, не проверенная гипотеза. Требует технического прототипа, прежде чем обещать это в продукте.
• Не выяснено, планировал ли TTP реальный запуск Clay Lab или проект был закрыт/сменён на cosy до выхода в продакшн — влияет на то, сколько доверять экономике/трэкшену модели (в файлах её нет, только архитектура и позиционирование).
• Trust Gradient в TTP был инструментом ценообразования (продать high-trust дороже). В cosy та же структура становится инструментом safety/consent — эта смена цели требует отдельной проверки: не приведёт ли она к обратным стимулам (желание Mars Forge продавать больше high-trust агентов может конфликтовать с задачей минимизировать данные, которые видит ребёнок/агент).

Рекомендации

1. На этой неделе: скопировать API-контракт (KernelAPI interface) из документации по kernel как отправную точку тех.спеки cosy-ядра — он уже написан в TypeScript-псевдокоде, готов к адаптации.
2. На этой неделе: взять таблицу-манифест из 8 спек TTP (Layer/Codename/Механика/Alive/Social/Malleable/UI/Trust/Antipatterns/Tags) как формат app.manifest.json для каталога MarshHub — не изобретать заново.
3. В этом месяце: спроектировать Trust Gradient специфично под родительский consent (не под ценообразование) — отдельный документ, черновик от модели доверия TTP, но с полем «кто подтверждает» вместо «воронка продаж».
4. В этом месяце: техническая проверка (spike) — можно ли реально дать ребёнку создавать Skill через natural language в песочнице за разумное время разработки, или это откладывается на v2 (принцип #13 у TTP тоже был «NEW», не реализован).
5. Явно решить: сохраняем ли мы жанровые имена приложений («*-clay» суффикс, Codename-архетипы «The Shield»/«The Garden») как часть cosy-брендинга, или это только внутренний архитектурный паттерн — вопрос брендинга, не архитектуры, вне рамок этого документа.

Источники

• Внутренний архив предыдущего бизнес-юнита (TTP — Tashkent Technology Partners), файлы декабря 2025 (внутренний источник, приоритетный)
• Clay (clay.earth) — Relationship OS, «линза на данные» философия (веб, вторичный контекст)
• Malleable Software — Ink & Switch — цитируется внутри принципов AI-first TTP
• LLMs and End-User Programming — Geoffrey Litt — цитируется внутри принципов AI-first TTP
• Внутренний market-ресёрч cosy — см. соседнюю запись «Рынок: пустая клетка на пересечении четырёх категорий» (для сверки терминологии)