Описание программного комплекса

Назначение и границы

Тимон Ядро организует совместную работу человека и ИИ-сотрудников вокруг задач, материалов и накопленного опыта компании. Система нужна там, где для результата недостаточно одного вопроса модели: необходимо разобраться в документах, учесть предыдущие решения, выполнить несколько действий и сохранить результат для продолжения работы.

Главный объект внимания — сама работа: кто её поручил, в какой области она выполняется, на каких сведениях основана, что уже произошло и какой следующий шаг допустим. Диалог служит интерфейсом постановки и уточнения задачи. История, знания, навыки и состояние выполнения позволяют продолжать её за пределами одного обмена сообщениями.

В этом документе подробно разобраны устройство системы и пример её использования. Описания механизмов Core основаны на исходниках. Общая организация корпоративных пространств и полный состав интерфейсов являются целевой моделью; текущий веб-пилот реализует ограниченный набор операций. Для каждой поставки нужен собственный перечень включённых и проверенных функций.

Место системы в организации

Рассмотрим коммерческий отдел. Менеджер готовит предложение клиенту, используя описание услуги, шаблон документа, условия поставки и историю переговоров. Данные находятся в разных местах; часть сведений требуется уточнить. ИИ-сотрудник помогает собрать материал и подготовить черновик, а человек проверяет условия и принимает решение о дальнейших действиях.

Чтобы это стало повторяемым процессом, системе нужны несколько видов информации. Шаблон относится к знаниям компании. Предпочтения конкретного менеджера относятся к его рабочему контексту или подтверждённой памяти. Порядок подготовки и проверки предложения относится к навыку. Незаконченная работа по конкретному клиенту имеет своё состояние. Смешение этих слоёв приводит к ошибкам: разовое исключение может превратиться в общее правило, а старые условия — попасть в новый документ.

Ядро объединяет эти слои в рабочий процесс и связывает их с разрешёнными инструментами. CRM, бухгалтерская система или файловое хранилище могут оставаться первичными источниками. Подключение позволяет читать или изменять их данные только в согласованных пределах. Агент не располагает актуальным состоянием CRM, если интеграция не подключена или не разрешает нужное чтение.

На схеме показано логическое разделение ответственности. Штат и Штурвал обращаются к одному Двигателю. Модель и инструменты выполняют разные функции: модель формирует и интерпретирует шаги, инструмент совершает конкретную операцию. Шлюз добавляет работу с разрешёнными ресурсами компьютера.

Состав комплекса

Двигатель — серверная основа Ядра. Core связывает пользователя, агента, историю, задания и результаты, управляет очередями и доступом. OpenCode выполняет модельный цикл в поддерживаемом профиле. Сессия исполнителя и долговременная работа пользователя имеют разные назначения.

Тимон Штат — веб-интерфейс сотрудника. Действующий веб-пилот предоставляет индивидуальный вход, выбор разрешённого агента, собственную историю, текст и ограниченные вложения, наблюдение за состоянием и остановку. Полный интерфейс задач, знаний и артефактов из проектного паспорта этим пилотом не покрывается.

Тимон Штурвал — интерфейс оператора компании. Веб-пилот читает состояние агента и поддерживает подготовку, подтверждение и проверку изменения имени, описания и языка. Operator MCP — отдельный программный интерфейс административных операций; рабочее пространство Operator — ещё одна поверхность для разрешённого просмотра. Их возможности нельзя автоматически приписывать всем кнопкам веб-Штурвала.

Тимон Штрих — личное приложение сотрудника с чатом, материалами и выбранным контекстом. Текущая платформа — macOS 15 и новее. Версия для Windows запланирована; дата выпуска и равенство возможностей не заявляются. В проверенном интеграционном кандидате Штрих и расширение продолжают одну связанную личную беседу. Прямое корпоративное подключение самого Штриха и единая работа через все интерфейсы остаются отдельной реализацией и приёмкой.

Тимон Шлюз — браузерное расширение с чатом сайта, локальным представлением данных и разрешёнными действиями во вкладке. Фоновый Node и Native Messaging host обеспечивают существующий транспорт и связь с устройством. Это вспомогательная среда исполнения, а не шестой пользовательский компонент. Замена старого Desktop-интерфейса Штрихом не переносит автоматически весь Node в приложение.

В продуктовую модель входят пять компонентов: Двигатель, Штат, Штурвал, Штрих и Шлюз. Тимон Штаб — отдельный продукт. Языковая модель, распознавание речи и коннекторы выбираются для конкретной конфигурации. Наличие каждого интерфейса отдельно не означает принятую совместную поставку.

Основные понятия

Рабочая область — контекст, в котором организованы определённая работа, материалы и доступ. На уровне серверной реализации существуют каталоги агента и пользователя, история и файлы. Корпоративная модель пространств подразделений и проектов шире этих каталогов: её нельзя считать полностью реализованной только по наличию папки на диске.

ИИ-сотрудник — программный агент с назначением, инструкциями, знаниями и доступными средствами работы. Его роль отвечает на вопрос «для каких задач он настроен». Полномочия отвечают на другой вопрос: «какие данные и действия ему действительно доступны». Инструкция «помогай коммерческому отделу» сама по себе не предоставляет доступ к CRM или право отправлять письма.

Контекст — сведения, используемые при конкретном выполнении. Знания — материалы для повторного обращения. Подтверждённая память — принятые факты, предпочтения или решения с происхождением. Навык — порядок выполнения класса задач. Инструмент — исполняемая операция. Артефакт — результат работы, например файл. Квитанция — сведения о фактическом исходе операции.

Как устроено рабочее пространство

В целевой продуктовой модели пространство связывает людей, ИИ-сотрудников, материалы и текущие работы. Для отдела продаж это могут быть согласованные шаблоны, описание услуг, правила подготовки документов и задачи по конкретным клиентам. Для отдельного проекта — его цель, решения, материалы и незавершённые действия.

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

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

Что хранится и почему это разные сущности

История фиксирует, что было сказано и получено. Она нужна для восстановления разговора и проверки предшествующих решений. Однако фраза в истории может быть предположением или отменённым условием. Поэтому факт присутствия сообщения ещё не делает его действующим правилом.

Подтверждённая память предназначена для долговременных сведений. В модуле user-memory предусмотрены виды fact, preference, decision и correction, а также состояния proposed, accepted, rejected и superseded. У записи есть источник; исправление связывается с заменяемой принятой записью. Таким образом можно различить предложение запомнить, подтверждение и последующую корректировку.

Состояние работы отвечает на вопросы «что ещё не завершено» и «что делать дальше». В механизме непрерывности используется WORK_STATE.md: область задачи, операция, проверенный прогресс, доказательства и следующий шаг. Это не общий справочник компании и не копия всей переписки. Его назначение — помочь продолжить конкретную работу после перерыва или смены технической сессии.

Файлы содержат исходные материалы и результаты. Поисковый индекс, если он используется, является производным представлением этих материалов. Изменение или удаление исходника требует согласованного обновления индекса. Наличие файлов, истории и памяти не подтверждает автоматически готовность семантического поиска по всем корпоративным данным.

Как система использует контекст

Языковой модели не требуется передавать всю базу компании в каждый запрос. В коде предусмотрены механизмы доставки контекста и его выборочного чтения. Исполнитель получает необходимые ориентиры и обращается к доступным материалам по мере выполнения. Это позволяет разделять правила, знания, историю и сведения о текущей работе.

В пути OpenCode фиксируется область сессии с ролью, агентом и пользовательским каталогом. Для вложений формируется представление, подходящее их типу. При утрате технической сессии предусмотрено создание новой и восстановление ограниченного контекста из истории. Это механизм продолжения, а не гарантия, что модель удерживает полный текст всех предыдущих обсуждений без ограничений.

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

Схема описывает логический маршрут. Конкретный способ поиска, извлечения текста и подключения источника определяется конфигурацией. Она не заявляет универсальный встроенный RAG или чтение всех ресурсов компании.

Как опыт превращается в знания и навыки

Предположим, менеджер уточнил: «Для этой услуги сначала проверяем срок доступности специалистов, затем готовим предложение». Это может быть правило конкретного случая или постоянный порядок работы. Сначала нужно установить область действия, источник и ответственного за подтверждение.

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

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

Улучшение здесь означает накопление проверенных сведений и совершенствование процедур. Оно не равнозначно изменению весов языковой модели. В принятом решении ADR-026 отдельно отключена непрозрачная автоматическая память провайдера Claude, чтобы старая заметка провайдера не подменяла актуальные подтверждённые сведения TeamON. Это решение относится к указанному провайдерному пути; его не следует выдавать за универсальное свойство всех моделей.

Сквозной пример подготовки предложения

Это иллюстративный сценарий настройки, а не отчёт о выполнении на данных реального клиента. Он показывает, как слои системы работают совместно и где нужен человек.

• Менеджер выбирает назначенного ИИ-сотрудника и передаёт задачу: подготовить черновик предложения по утверждённому шаблону. Указывает клиента, предмет, срок и ограничения. Прикладывает доступные материалы или задаёт разрешённый источник.
• ИИ-сотрудник проверяет полноту вводных. Если срок или условие не подтверждены, запрашивает уточнение. Он не должен заполнять пробелы правдоподобными коммерческими обещаниями.
• Для повторяемого порядка используется назначенный навык. Данные из CRM читаются только при наличии работающего и разрешённого подключения. Источник важных условий сохраняется в доступном для проверки виде.
• Готовится черновик. Если требуется файл, его фактическая генерация зависит от установленного инструмента. Одна фраза «документ готов» не подтверждает наличие скачиваемого результата.
• Менеджер проверяет суммы, сроки, формулировки и полноту. Правка конкретного предложения остаётся частью этой задачи; общее изменение порядка проходит отдельное утверждение.
• После перерыва работа продолжается по истории и состоянию. Если отправка предложения не разрешалась, создание черновика не превращается в автоматическую отправку клиенту.
• Если отправка отдельно разрешена и поддерживается интеграцией, проверяется её результат. При неизвестном исходе сначала выясняется состояние прежней операции, чтобы не отправить документ повторно.

Результатом считается проверенный черновик или иной заранее определённый артефакт. Полезность оценивается по полноте, количеству исправлений, времени подготовки и возможности продолжения. Конкретные показатели эффективности измеряются на пилоте, а не выводятся из наличия агента.

Жизненный цикл задания и продолжение после сбоя

В целевой модели задание проходит принятие, выполнение, ожидание уточнения или подтверждения и завершение. Возможны ошибка, отмена и неизвестный результат внешнего действия. Последний случай особенно важен: сервер мог отправить команду, а подтверждение потерялось из-за сети.

Core хранит связь агентной работы с историей и результатами. Механизм WORK_STATE предписывает фиксировать проверенные этапы, а не объявлять промежуточный отчёт завершением. Для конечного набора объектов предусмотрен подход с pending и uncertain: неопределённый эффект сначала сверяют, после чего решают вопрос о продолжении.

Например, при пакетной обработке десяти записей первые четыре могут иметь подтверждённый результат, пятая — неизвестный, остальные — ожидать. Повторять весь пакет нельзя считать безопасным восстановлением. Нужно проверить пятую запись и продолжить оставшиеся. Схема иллюстрирует требуемый порядок; надёжность конкретной интеграции подтверждается испытанием её повторов и отказов.

Остановка прекращает дальнейшее выполнение в пределах реализованного механизма. Она не является универсальной отменой уже совершённого внешнего изменения. Удалённый файл, отправленное письмо или изменённая запись требуют отдельного действия восстановления, если оно вообще поддерживается.

Модели инструменты и подключения

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

Модель может хорошо отвечать на текст и при этом не поддерживать нужный формат вызова инструментов. Коннектор может быть установлен, но не иметь права читать выбранный объект. Речевой адаптер может присутствовать в коде, но не обеспечивать требуемое качество распознавания. Поэтому проверяют конкретную комбинацию версии, модели, инструмента и данных.

Внутренняя модель и внешний API являются разными профилями передачи данных. Локальная генерация текста не делает автоматически локальными поиск в интернете, распознавание речи или внешний бизнес-сервис. Для каждого шага процесса должен быть понятен источник и сетевой маршрут.

Варианты применения

Для юридического подразделения знаниями могут быть утверждённые условия и шаблоны, навыком — порядок сравнения договора, результатом — перечень расхождений с основаниями. Решение о допустимости условия остаётся за ответственным специалистом. Уверенный ответ модели не заменяет юридическую проверку.

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

Для руководителя возможна подготовка материалов по поручениям и совещаниям. Анализ аудио требует выбранного и испытанного STT; создание задач во внешней системе — отдельной интеграции. Распознавание говорящих не устанавливает их личность автоматически.

Общий принцип для этих сценариев один: выбрать задачу, назначить источники и ответственного, ограничить действия, определить проверяемый результат. Сценарии подразделений не являются готовым каталогом всех включённых бизнес-функций.

Размещение и развитие

Целевой корпоративный профиль размещается в инфраструктуре заказчика. Внутри неё могут находиться Двигатель, веб-компоненты, хранилища и выбранная модель. Шлюз располагается на рабочем устройстве. Совместное размещение серверных компонентов на одном узле не означает высокой доступности.

Если модель, данные, вход, DNS, зависимости и необходимые инструменты доступны локально, выбранные задачи могут продолжаться при отключении внешнего интернета. При этом остаются необходимыми питание, серверы и локальная сеть. Внешние API и новые сведения из внешних систем без связи недоступны.

Автономность подтверждают на согласованном сценарии с отключённым исходящим доступом. Установка и обновление без интернета проверяются отдельно от повседневного выполнения. Пополнение локальных знаний возможно только при наличии соответствующих функций и процедур; оно не означает автоматического обучения весов модели.

Что подтверждено и что уточняется при внедрении

В исходниках прослеживаются пользовательские рабочие каталоги, история, механизмы подтверждённой памяти, состояния работы, доставки контекста и OpenCode-сессий. Это основание для описания устройства Core. Оно не заменяет проверку этих механизмов в выбранной корпоративной поставке.

Веб-пилот предоставляет ограниченную рабочую поверхность. Лимит вложений его интерфейса — до трёх файлов суммарно 2 МиБ; представление истории — последние сто собственных сообщений. Эти параметры не описывают всю ёмкость серверного хранения. Пилотный вход не является корпоративным SSO.

До промышленного применения фиксируют матрицу ролей и объектов, состав клиентов, модель, интеграции, форматы файлов, объёмы, сроки хранения, обновление и восстановление. Полная обработка артефактов, качество реальной речи, автономный профиль и производительность требуют собственных испытаний. Неподтверждённые показатели не задаются приблизительными числами.

Управление ИИ-сотрудниками

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

В Core предусмотрены операции изменения имени, описания, роли, языка и параметров модели; редактирования инструкций и документов; назначения, снятия, включения и отключения навыков; назначения коннекторов и провайдера исполнения; изменения напоминаний. Перечень подтверждён контрактом OperatorAgentChange. Это набор серверных операций, а не утверждение, что все перечисленные действия уже представлены кнопками в Штурвале. Текущий веб-пилот предоставляет ограниченный набор настроек, описанный в руководстве администратора.

Административное изменение проходит через подготовку, просмотр и подтверждение. Подготовленная операция содержит объект, исходную ревизию и описание изменения. При подтверждении проверяются полномочия, актуальность ревизии и соответствие операции подготовленному содержимому. Результат возвращается как квитанция со статусом. Сохранение настройки и её применение в исполнителе различаются: часть изменений действует со следующего обращения. После таймаута оператор проверяет статус существующей операции, чтобы не создать повторное действие.

Назначение доступа пользователям

Доступ к ИИ-сотруднику и права администрирования — разные назначения. В текущем канальном runtime Core роль определяется для конкретного агента. Владелец экземпляра имеет область всего экземпляра; администратор — область текущего агента; обычный пользователь работает в собственной рабочей области. Для обычного пользователя отдельно проверяется наличие в списке допущенных к агенту. Сам факт определения роли user ещё не означает разрешение входа.

В каналах предусмотрено сопоставление по поддерживаемым идентификаторам пользователя, имени или телефону. Идентификаторы разных каналов нельзя считать одной личностью только из-за совпадения числа. Проверка owner специально учитывает тип канала. Списки допуска должны читаться актуальными, чтобы изменение назначения отражалось при последующих проверках.

Нельзя переносить эту таблицу на произвольную корпоративную ролевую модель. Персональная учётная привязка Operator позволяет установить действующего оператора, но существующий административный доступ имеет широкую область компании. Он не доказывает наличие готовых ограничений «оператор только отдела продаж» или «аудитор только журнала». Сопоставление с корпоративным IdP, группы подразделений и тонкие области административных прав требуют отдельного серверного контракта и проверки поставки.

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

Корпоративные подключения MCP

MCP — Model Context Protocol, интерфейс подключения инструментов и источников к исполнителю ИИ. Для организации это способ предоставить выбранному ИИ-сотруднику операции корпоративной системы: например, чтение записи CRM или получение документа. Такие примеры описывают сценарий интеграции; поддержка конкретного продукта и операции подтверждается наличием и проверкой соответствующего коннектора.

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

Защищённый ввод учётных данных отделён от просмотра метаданных подключения. Операции сохранения используют ожидаемую ревизию, а журнал фиксирует сведения об операции без значений секретов. Для пути Claude конфигурация MCP передаётся через временный файл с ограниченными файловыми правами, чтобы значения не оказывались в аргументах запуска. Это конкретный механизм данного пути исполнения, а не универсальное утверждение о всех провайдерах.

Корпоративный MCP не следует смешивать с Operator MCP. Первый в данном описании означает подключения для выполнения рабочих задач; второй предоставляет административные операции управления системой. Обычному сотруднику не требуется устанавливать MCP-клиент ради работы в веб-интерфейсе. Назначение рабочего коннектора не должно трактоваться как выдача административного интерфейса.

База знаний и управление материалами

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

Контракт управления документами различает company_context, agent_context, agent_skill и user_context. Инвентаризация возвращает документ с областью, ревизией и размером. Такая адресация позволяет понять, какой именно материал редактируется, и обнаружить изменение версии до перезаписи. Область хранения при этом не заменяет проверку полномочий вызывающего оператора: широкая административная учётная запись не становится узкой только из-за выбора пользовательского каталога.

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

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

Файловый контекст и инвентаризация документов не равнозначны полнофункциональному корпоративному поиску. Массовый импорт, OCR, семантическая индексация, автоматическая синхронизация источников и наследование прав из внешней системы должны быть подтверждены конкретной интеграцией. Нельзя заявлять их на основании самого наличия документов или MCP.

Как соотносятся разрешения

Для рабочей операции необходимо рассматривать всю цепочку: личность человека, доступ к выбранному агенту, область данных, назначенный инструмент, учётные данные внешней системы и допустимое действие. Проверка только одного звена недостаточна. В частности, доступ к диалогу не означает право отправлять письмо, наличие навыка не означает право изменять базу, а доступ к модели не означает разрешение передавать ей любую информацию.

Рассмотрим пример: менеджеру разрешено работать с агентом продаж; агенту назначен коннектор CRM; внешняя учётная запись разрешает чтение определённых записей. Это позволяет спроектировать сценарий подготовки черновика по доступным данным. Отправка предложения клиенту является отдельным действием: для неё нужны соответствующий инструмент, внешнее право и предусмотренное сценарием подтверждение. Такой пример — требуемая конфигурация и проверка интеграции, а не описание уже проверенной универсальной политики для любой CRM.

При внедрении составляют матрицу «кто — какой агент — какие данные — какие операции». Проверяют разрешённый запрос, попытку чтения чужих данных, запрещённое изменение, отзыв назначения и повтор действия после ожидания. Результаты фиксируют для выбранной версии и подключения. Готовая универсальная матрица произвольных корпоративных ролей и единая консоль всех разрешений текущим веб-пилотом не подтверждены.

Подробности административного процесса приведены в руководстве администратора, границы защиты — в документе по безопасности, готовность веб-интерфейсов — в карте реализованных возможностей. Эти документы следует читать вместе: наличие серверной операции, наличие экрана и подтверждённая работа в конфигурации заказчика являются тремя разными фактами.

Как читать остальные документы

После этого описания функциональные характеристики раскрывают классы возможностей и условия их использования. Архитектурное руководство объясняет взаимодействие компонентов. Модель безопасности разбирает доверие, доступ и автономность. Руководства пользователя и администратора относятся к обозначенному в них пилотному срезу.

Подробные паспорта Двигателя, Штата, Штурвала, Штриха и Шлюза содержат технические точки интеграции и открытые решения. Программа проверки определяет, какие доказательства нужны для передачи. Страница готовности помогает разрешать противоречия между историческим проектом и более свежей реализацией.

Личный и корпоративный контекст

Личные материалы и история Штриха хранятся у существующего владельца личного разговора. Регламенты компании, серверные задания и принятые корпоративные результаты относятся к экземпляру Core. Передача материала между областями должна быть явной: сотрудник выбирает, что передаёт, какому агенту и для какой задачи. Подключение к компании само по себе не публикует работодателю весь личный контекст.

В Шлюзе различаются три маршрута: личный Codex, связанная беседа Штриха и агент TeamON через Node. У них разные владельцы истории и исполнения. Выбор другого маршрута не переносит сообщения автоматически. Проверенный локальный мост Штрих — Шлюз обеспечивает продолжение связанной личной беседы; это не сквозная корпоративная история между каналом, Штатом, Штрихом и расширением.

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

Публичный консультант и рабочий сотрудник

Консультант на сайте отвечает по публичной документации и выдаёт ссылки на документы и утверждённые схемы. Его путь исполнения — отдельный публичный gateway, отдельный профиль OpenCode и выбранный API модели. Корпоративные инструменты, Operator MCP и документы сотрудников в этот профиль не включены.

Корпоративный ИИ-сотрудник получает назначение, контекст и разрешённые инструменты в экземпляре компании. Для него действуют серверные полномочия и границы конкретного рабочего процесса. Публичный диалог о функциях Ядра не является демонстрацией всех полномочий такого сотрудника.

База знаний консультанта использует лексический поиск SQLite FTS5 с ранжированием BM25, префиксами и словарём названий. Это отдельный публичный индекс документации; он не равнозначен корпоративному Context MCP. При обновлении документации меняются и страницы, и поисковый индекс, и ссылки для выдачи.

Основание документа

Сверка продуктовой документации и исходников 15 сентября 2026 года. Правила сверки и ограничения.