Что взять из архитектуры Palantir для своих ИИ-агентов

В статье «Организация как онтология» я разбирал, зачем людям и ИИ-агентам общий язык компании. Агенту нужно понимать, что считается клиентом, как заказ связан с оплатой и кто имеет право изменить его статус.

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

1. Начните с онтологии

Опишите объекты, с которыми работает агент, их связи и допустимые действия. Например: клиент оформляет заказ, заказ связан с оплатой, возврат относится к конкретному платежу.

Затем дайте агенту инструменты с понятным назначением: проверить оплату, изменить статус заказа, подготовить возврат. Каждый инструмент должен проверять условия выполнения и права доступа. Так общий язык компании становится частью исполняемой логики.

2. Соберите обращения к моделям в одном месте

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

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

3. Предусмотрите смену модели

Отделите выбор модели от бизнес-логики. Тогда для проверки другой модели не придётся переписывать весь процесс.

Само переключение стоит сопровождать проверкой на ваших задачах: одинаковый интерфейс ещё не означает одинаковое поведение.

4. Определите, когда агент начинает работу

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

Правила работы с заказом должны оставаться общими для всех способов запуска.

5. Проверяйте изменения на реальных сценариях

Соберите небольшой набор примеров с ожидаемым результатом. Что делать, если оплата не найдена? Если заказ уже отменён? Если у пользователя нет права на возврат?

Прогоняйте эти сценарии после изменения инструкций, инструментов или модели. Ошибки из реальной работы добавляйте в набор проверок.

6. Сохраняйте историю действий

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

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

Следующий шаг

Организация как онтология: зачем людям и ИИ-агентам общий язык компании

Связанные материалы

Статья: Организация как граф задач: что приходит на смену отделам

Блог: AGENTS.md как операционная дисциплина: десять правил Вайбхава Шристава из OpenAI

База знаний: LiteLLM — модели по подписке вместо API-ключей для ваших агентов

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov