О продукте · · 7 мин чтения
Зачем GrantTap нужен центр управления локальными агентами
Задача остаётся видимой, даже когда меняются провайдер, сессия и компьютер. Объясняем решение, на котором строится продукт.

Coding-агент может работать десятки минут, пока вы отошли. Сложнее не открыть ещё одну сессию, а понять, какая работа ждёт решения, на каком она компьютере и был ли инструмент действительно разрешён и использован.
В GrantTap человек следит за Task. Execution — одна сессия провайдера, исполняющая эту задачу. Дочерний агент находится внутри execution. Поэтому задача остаётся одной и той же после смены провайдера или native session.
Видеть работу, не прерывая её
Экран Now ставит Needs You выше обычной активности. Полезный статус называет провайдера, компьютер, рабочую папку, последнее значимое событие и состояние доставки. Он не превращает каждый вызов инструмента в уведомление. Телефон и Watch нужны для быстрого взгляда, ограниченного решения и короткого продолжения; coding runtime остаётся на компьютере.
Если компьютер офлайн, задача должна сообщить об этом. Сообщение в очереди отличается от принятого провайдером, а оба состояния — от проверенного изменения кода. Эти различия важны: успокаивающая зелёная точка иногда хуже честного «неизвестно».

Полномочия рядом с действием
Основные интеграции GrantTap — Claude Code и Codex; Cursor имеет статус Beta, другие провайдеры поддерживаются в более узких, описанных пределах. У каждого остаются собственные сессии и механизмы контроля. Правило Mesh может разрешить, запросить подтверждение или запретить возможность, но выбор правила ещё не доказывает его применение на каждом компьютере. Нужен наблюдаемый ответ хоста.
Relay переносит зашифрованные сообщения. Учётные данные провайдера и локальная среда остаются на компьютере. Это выбор границы исполнения, а не обещание приватности у внешней модельной службы: её трафик регулируется условиями самого провайдера.
Понятная передача работы
Поддерживаемый handoff переносит ограниченные факты Task и git, важные решения, блокеры и явный адрес назначения. Скрытые рассуждения между провайдерами не копируются. Identity репозитория и claims помогают заметить пересечение работ; receipt показывает, приняло ли следующее execution передачу. Удалённый запуск зависит от провайдера и целевого хоста.
Критерий прост: вернувшись к задаче, можно ли понять, что произошло, что остаётся неизвестным и где нужно ваше следующее решение? Вокруг этого вопроса строится GrantTap — с честным различением текущих возможностей и направления развития.
Телефон должен уменьшать неизвестность
Первый вопрос вдали от рабочего стола часто прост: нужна ли сейчас моя помощь? Лента всех внутренних шагов агента лишь усложнит ответ. Идея центра управления GrantTap начинается со стабильной Task и короткого статуса: текущее execution, компьютер, последнее значимое событие, ожидающее решение и состояние доставки. Когда вопрос требует деталей, человек может открыть широкий контекст на компьютере.
Отсюда следует ограничение уведомлений. Чтение файла агентом не обязательно является новостью. Запрос разрешения, сбой доставки, остановленный handoff или подтверждённый результат — другое дело. Продукт не должен выводить срочность из количества событий. Он различает обычный прогресс и момент, когда решение человека меняет дальнейший путь. Хороший быстрый взгляд позволяет спокойно вернуться к своим делам, если действие не требуется.
Сохраните единицу работы
Сессия провайдера может завершиться по обычной причине: приложение перезапустилось, сменился context window или работа переехала на другой компьютер. Task человека остаётся. GrantTap группирует последовательные executions под этой видимой единицей и оставляет дочерних агентов внутри тех сессий, где они работали. Это предотвращает частую ошибку координации: считать делегированное исследование или новую native session посторонним запросом и потерять цепочку решений.
Стабильная identity не означает одинакового возобновления у каждого провайдера. Поддержка и пути удалённого запуска различаются. Task сохраняет цель и историю, даже когда конкретный маршрут недоступен. Интерфейс сообщает, какое продолжение запрошено, какое принято и какое пока существует лишь как возможность. Преемственность ценна именно тогда, когда честно переживает ограничения, а не делает вид, будто все executions взаимозаменяемы.

Полномочие относится к действию
Человек может выбрать allow, ask или deny для capability, но главный вопрос безопасности — где правило применяется. Coding-действие выполняет локальный компьютер, и он должен проверять подконтрольные маршруты. Правило на телефоне не доказывает, что неизвестный native путь провайдера был заблокирован. GrantTap поэтому различает выбранную policy, применение на host и наблюдаемый вызов.
Такое разделение помогает и обычной диагностике. Если инструмент есть в списке, но не инициализируется, человеку нужен ответ host, а не ещё одна общая кнопка одобрения. Если действие разрешено, но инструмент не вызывался, usage нельзя считать потраченным только по approval. Честные границы позволяют центру управления быть полезным без ложного обещания всеобъемлющего корпоративного policy layer.
Локальная работа использует внешние сервисы
Среда разработки и credentials провайдера остаются на компьютере, а relay GrantTap переносит зашифрованные сообщения между разрешёнными устройствами. Такое устройство ограничивает данные, которые нужен relay. Оно не меняет поток между coding-провайдером и его модельным сервисом. Выбирая процесс, следует читать правила приватности и хранения самого провайдера. Локальный контроль описывает расположение инструментов и полномочий, а не обещает, что никакие данные не покидают компьютер.
Соединение также отличается от результата. Relay может передать сообщение, пока целевой провайдер остановлен. Компьютер бывает online, а интеграция — не готова. Провайдер может принять prompt, но не создать проверенное изменение кода. Центр управления показывает эти переходы по отдельности, чтобы удалённый пользователь не выводил успех только из доступности сети.
Один день такого процесса
Допустим, вы запустили coding Task на ноутбуке и ушли на встречу. На телефоне видно, что агент запрашивает разрешение на одну конкретную команду. Запрос называет Task, компьютер, capability и действие. Можно разрешить, отказать или дождаться возможности изучить больше контекста. Позже receipt показывает доставку решения на host; следующее событие может показать вызов и протестированный результат. Каждая строка отвечает на отдельный вопрос.
Если ноутбук потеряет связь на середине работы, Task сохранится и покажет прерывание. После возвращения компьютера можно продолжить поддерживаемым способом или выбрать явный handoff в другое execution. Продукт не должен тайно менять цель на произвольную машину. Сгенерированные картинки выше иллюстрируют отношения концептуально; скриншот Now ниже сделан на детерминированных данных. Evidence вашей работы — живая Task, состояние host и проверенный итог.
Как выглядит успех
Успех — не панель с максимальным числом счётчиков. Он в том, что человек знает, чем занят агент, какое решение ему разрешено принять и как проверить результат. Сообщение «неизвестно» должно вести к действию: возможно, host offline, провайдер не сообщает usage или инструмент не инициализирован. Ясная неизвестность лучше придуманного нуля и зелёного бейджа завершения без доказательств.
Граница продукта GrantTap — Personal сценарий локальных coding-агентов. Claude Code и Codex основные пути, Cursor в Beta; другие возможности описываются лишь в реально поддерживаемых пределах. Центр управления должен становиться точнее через существующие Task, execution, capability и usage, а не через новые декоративные слои. Доверие появляется, когда решение можно проследить до компьютера, который его применил, и до работы, которая последовала.
Проверить эту идею можно на обычном рабочем дне. Выберите две Task на разных компьютерах и одно действие, требующее решения. После короткого взгляда на телефон попробуйте без догадок назвать, где работает каждая Task, какое действие ждёт вас и какое событие уже подтверждено. Если для ответа приходится открывать несколько несвязанных логов, компактный экран ещё не выполнил свою задачу. Улучшать стоит не число карточек, а ясность существующих состояний.
