Я покажу вам, як перетворити моделі, агенти, навички та автоматизації, які живуть у робочих процесах й інструментах вашої команди, на одну скоординовану систему.
Те, що сьогодні має більшість команд, виглядає зовсім інакше. Їхні моделі, навички та автоматизації сидять в окремих інструментах, приватних розмовах та індивідуальних налаштуваннях.
Кожен мусить навчати свій ШІ тому, що він знає і як працює. Контекст, виправлення та робочі процеси, які вони створюють, рідко досягають когось іншого.
Одна людина вводить Claude в курс останньої стратегії. Інша просить Codex пошукати в старій теці. Третя відновлює корисний робочий процес з пам'яті. Кожен чат містить дещо іншу версію бізнесу.
Ми створили цей спільний шар за допомогою HQ. Він розташований під Claude Code, Codex, Cursor або будь-якими відкритими моделями, які обирає ваша команда, переносячи контекст компанії та можливості між ними.
Давайте створимо такий.
Почнемо з щотижневого аналітика, який у понеділок уже знає, що змінилося: які рішення ухвалено, які проєкти зрушили, які ризики зросли і що команда пообіцяла зробити далі.
Наприкінці ваша команда матиме:
- одне місце, де кожен агент може отримати актуальний контекст компанії;
- робочі правила, які переживають нові чати та зміни моделей;
- щотижневого аналітика, якого може запустити будь-хто в команді;
- спільні навички та автоматизації, які покращуються, коли команда їх використовує;
- цикл перегляду та синхронізації, який перетворює вдосконалення однієї людини на нову відправну точку команди.
Не починайте з моделювання всієї компанії. Спочатку доведіть систему на одному робочому процесі, що повторюється, а потім розширюйте її щоразу, коли команда знаходить ще один процес, який варто поширити.
1. Створіть середовище навколо моделі
Модель може мислити, писати та викликати інструменти. Але їй усе ще потрібне середовище, яке пояснює, як влаштована робота у вашій компанії.
Корисна система відповідає на п'ять запитань:
- Що знає ШІ?
- Як він знаходить потрібний контекст?
- Яких правил він має дотримуватися?
- Яку роботу, що повторюється, він може виконувати?
- Як кожен запуск покращує наступний?
Довгий системний промпт може відповісти на деякі з цих запитань для однієї сесії. Система компанії робить відповіді структурованими, постійними та доступними для всіх.
Знання доступні для пошуку. Правила переживають чат. Інструменти мають межі. Робота залишає артефакти. Ухвалені робочі процеси стають придатними для повторного використання, а не зникають, коли розмова закривається.
Ось чому одна й та сама модель може відчуватися зовсім по-різному у двох компаніях. Модель може бути ідентичною. Робоче середовище — ні.
Модель забезпечує інтелект. Система забезпечує компанію.
2. Доведіть систему на одному реальному робочому процесі
Спроба змоделювати всю компанію спочатку може залишити вас із тижнями організованого контексту й без доказів, що система покращує хоча б одну частину роботи.
Почніть із робочого процесу, який має чотири властивості:
- він відбувається часто;
- межі чіткі;
- він залежить від контексту компанії;
- людина може швидко оцінити результат.
Щотижневий бриф про стан компанії підходить.
Вхідні дані вже існують, але вони розкидані по нотатках зустрічей, файлах проєктів, рішеннях та головах людей. Вихідний результат корисний для всієї команди, а засновник може швидко визначити, чи є бриф точним.
Визначте контракт перед створенням воркера.
Вхідні дані
- зустрічі за останні 7 днів
- поточний стан проєктів
- рішення, зобов'язання та відкриті питання
- ризики та заблокована робота
Процес
- отримати відповідні джерела
- перевірити кожне фактичне твердження
- виявити суперечності та відсутню інформацію
- синтезувати зміни на рівні компанії
Результат
- ухвалені рішення
- прогрес за проєктами
- ризики та блокери
- зобов'язання на наступний тиждень
- список джерел
Межі
- лише чернетка
- зупинка для перегляду людиною перед поширенням
Якщо робочий процес усе ще змінюється щоразу, коли людина його запускає, залиште його ручним. Процес має стати повторюваним, перш ніж стати спільною інфраструктурою.
3. Дайте ШІ довготривалу пам'ять компанії
Почніть із поточного покрокового налаштування HQ. Встановіть HQ, створіть робочий простір компанії та відкрийте HQ як активну робочу теку в інструменті ШІ, який ваша команда вже використовує.
Швидкий старт з відкритим кодом — це одна команда:
npx create-hq
Тепер додайте лише той контекст, який потрібен для щотижневого брифу.
Почніть із такої структури:
- HQ
- companies
- your-company
- company-brief.md
- knowledge: decisions and playbooks
- sources: meetings
- signals
- people
- projects
- policies: weekly-intelligence.md
- workers: weekly-intelligence
Почніть тут і додавайте глибші знання, навички, автоматизації та спеціалізовані воркери компанії лише тоді, коли реальний робочий процес цього вимагатиме.
Бриф компанії пояснює, чим займається бізнес, як він заробляє гроші та що важливо зараз. Проєкти зберігають поточний стан. Рішення зберігають причини, чому команда обрала той чи інший шлях. Файли людей роблять відповідальність видимою.
Аналітика зустрічей фіксує зобов'язання, ризики, питання та рішення, які ніколи не потрапили в акуратний документ.
Не вставляйте всю компанію в кожен промпт. Хартія HQ дає агенту карту того, де живуть знання, політики, проєкти та воркери. Агент слідує за цією картою та отримує глибше джерело, необхідне для завдання.
Дайте агенту невелику стабільну точку входу та глибший контекст на вимогу.
Це зберігає пам'ять компанії доступною, не витрачаючи контекстне вікно до початку роботи.
4. Перетворіть судження компанії на політику
Знання розповідають воркеру, що сталося. Політика розповідає, як компанія очікує виконання роботи.
Створіть companies/your-company/policies/weekly-intelligence.md:
Політика щотижневої аналітики
- Підтверджуйте кожне фактичне твердження джерелом.
- Виявляйте суперечливі докази. Ніколи не вирішуйте їх мовчки.
- Повідомляйте про ризики з оригінальним рівнем терміновості джерела.
- Позначайте відсутню, застарілу або невизначену інформацію.
- Ніколи не включайте секрети чи контекст інших компаній.
- Зупиняйтеся для схвалення людиною перед поширенням.
Тримайте першу політику досить короткою, щоб люди могли її підтримувати.
Існує три рівні контролю:
- Інструкція просить агента дотримуватися вподобання.
- Політика робить правило довговічним для сесій і людей.
- Хук або механічна перевірка блокує дію, коли помилка може бути дорогою.
«Цитуйте свої джерела» може початися як політика. «Ніколи не надсилайте без схвалення» заслуговує на примусове виконання на межі дії.
Не намагайтеся описати кожну можливу поведінку. Закодуйте кілька інваріантів, які мають пережити кожну модель, колегу та проєкт.
5. Упакуйте робочий процес як спільний воркер
Тепер перетворіть ухвалену процедуру на багаторазовий воркер HQ.
Запустіть /newworker і дайте йому одне вузьке завдання. Загальний аналітик компанії звучить корисно, але його важко тестувати та легко використати не за призначенням. Воркер щотижневої аналітики має чіткі вхідні дані, результат і умови зупинки.
Специфікація воркера:
Назва: weekly-intelligence
Призначення: Створювати щотижневий бриф компанії з джерелами для перегляду людиною.
Дозволені джерела
- бриф компанії
- зустрічі за останні 7 днів
- поточні проєкти
- рішення та зобов'язання
Процедура
- Підтвердьте звітний період.
- Отримайте дозволені джерела.
- Виділіть рішення, прогрес, ризики та зобов'язання.
- Перевірте твердження за матеріалами джерел.
- Позначте суперечності, прогалини та застарілу інформацію.
- Напишіть бриф у необхідному форматі.
Необхідний результат
- короткий виклад
- ухвалені рішення
- рух проєктів
- ризики та блокери
- зобов'язання на наступний тиждень
- невирішені питання
- список джерел
Ніколи
- не вигадуйте відсутні факти
- не читайте контекст іншої компанії
- не розкривайте секрети
- не надсилайте та не публікуйте бриф
Готово, коли: Кожне твердження підтверджене або позначене як невизначене, і чернетка готова до перегляду людиною.
Знання компанії постачають факти. Політика постачає судження. Воркер постачає послідовність, що повторюється.
Один промпт може створити один корисний бриф. Воркер робить метод доступним для іншого колеги наступної п'ятниці.
6. Зробіть так, щоб кожне виправлення покращувало систему
Не ставтеся до першого успішного запуску як до завершеної інфраструктури.
Запустіть воркера, перегляньте бриф і діагностуйте кожне виправлення на правильному рівні.
- Бракує факту → Покращте знання компанії.
- Неправильний контекст → Покращте маршрутизацію та описи ресурсів.
- Повторювана помилка → Покращте навичку воркера.
- Небезпечна поведінка → Покращте політику або хук.
- Слабкий результат → Покращте контракт результату.
- Застаріла інформація → Покращте процес накопичення знань.
Якщо воркер пропустив рішення, бо зустріч ніколи не була зафіксована, переписування промпту не виправить систему. Покращте процес накопичення знань.
Якщо він продовжує ховати ризики під другорядними оновленнями, загостріть контракт результату.
Якщо хтось просить його поширити бриф без схвалення, посиліть політику та межу дії.
Корисне питання: яка частина середовища дозволила цю помилку?
Виправте цей рівень, а потім запустіть той самий приклад знову. Виправлення має пережити результат, який його виявив.
Саме так людське судження накопичується. Ви навчаєте систему один раз, а потім робите покращену поведінку доступною для наступних запусків, замість того щоб повторювати виправлення в приватних чатах.
7. Зробіть систему розумнішою щоразу, коли команда її використовує
Щойно бриф, політика та воркер переживуть перегляд, запустіть /hq-sync.
Це момент, коли HQ стає ШІ-мультиплеєром.
Відділ продажів може перетворити роботу із запереченнями на навичку. Підтримка може закодувати правила ескалації. Операції можуть покращити звіт. Інженери можуть додати контрольний пункт перегляду.
Коли кожен внесок переживає перегляд, він синхронізується в Main і стає частиною спільної системи компанії.
Наступний колега успадковує контекст, правила, навички, воркери та автоматизації, які компанія вже перевірила. Йому не потрібен оригінальний чат або промпт.
Він відкриває HQ у своєму улюбленому інструменті ШІ та продовжує з покращеної версії.
Це цикл накопичення HQ: використовуйте систему, покращте один рівень, перегляньте його, синхронізуйте та підвищте відправну точку для всіх.
Моделлю може бути Claude, Codex, ChatGPT або відкрита модель. Шар компанії під нею стає все розумнішим.
Ізоляція компаній усе ще діє. Синхронізація не повинна сплющувати тенанти, обходити дозволи або класти секрети в спільні файли. Спільна система працює лише тоді, коли межа навколо «спільного» залишається чіткою.
Спільне навчання також підвищує ставки. Слабка інструкція тепер може вплинути на всіх, тому ставтеся до Main як до продакшену.
Переглядайте кожен внесок перед синхронізацією. Тримайте політики вузькими. Тестуйте воркерів на реальних прикладах. Використовуйте /harness-audit, щоб перевіряти ефективність контексту, контрольні точки якості, збереження даних, пошук і безпеку в міру зростання налаштування.
Щойно зміна переживає перегляд, синхронізуйте її. Потім оберіть наступний робочий процес, що повторюється, і знову покращте спільну базову лінію.
Повна послідовність така:
Пам'ять → контекст → політика → воркер → перегляд → стандарт команди
Почніть з одного регулярного завдання цього тижня. Визначте його вхідні дані, результат і межу схвалення. Запустіть його вручну, виправте, а потім перетворіть ухвалений метод на воркер, яким ваша команда може ділитися.
Модель змінюватиметься й надалі. Пам'ять, правила та найкращі способи роботи вашої компанії не повинні скидатися разом із нею.
Якщо ви хочете створити спільну систему для власної команди, спробуйте HQ.
Підписуйтеся на мене — @VibeMarketer_. Буде більше цікавого. Дякую за читання :)
