DevRev оновив свої агентні продукти Computer і Operator, додавши GPT-6.1 Sol поряд із GPT-6 Astra, – і головна причина вибору моделі не в "найрозумніша", а в балансі reasoning, швидкості та вартості для enterprise-сценаріїв. Це видно з кейсу, який OpenAI опублікував 4 листопада 2026 року: CTO DevRev Ahmed Bashir прямо каже, що для роботи з клієнтами й співробітниками потрібна модель, яка одночасно "trusted, highly aligned" і достатньо швидка за latency.

Чому це не просто ще один vendor-кейс

Якщо ти пишеш AI-агентів для production – внутрішніх tools, support-ботів, автоматизації workflows – кейс DevRev цікавий не моделлю як такою, а тим, як стартап вирішив три проблеми, які рано чи пізно впираються в кожного:

  • як довіряти діям агента, якщо він працює з живими enterprise-даними;
  • як тестувати модель на реалістичних умовах, а не на синтетичних бенчмарках;
  • який інструмент для розробки коду реально прискорює команду, а не просто виглядає модно в демо.

DevRev відповів на всі три питання власними механізмами, і їх варто розібрати окремо від конкретного стеку OpenAI.

Що саме змінилось: Computer, Operator і Enterprise-Bench

DevRev побудував два продукти – Computer і Operator – для доведення складних клієнтських і employee-запитів до завершення. Ключова деталь: дії агентів reversible, а відповіді вказують на джерело інформації. Це не "агент вирішив і зробив", а "агент зробив дію, яку можна відкотити, і показав, звідки взяв факти".

Під капотом – комбінація кількох моделей OpenAI (GPT-6 Astra і GPT-6.1 Sol) з власним harness DevRev, який відповідає за company knowledge, enforcement permissions і контроль над тим, які дії агент може виконувати. Моделі тестуються разом із цим harness, а не окремо – і саме для цього DevRev побудував власний бенчмарк Enterprise-Bench. Він перевіряє поведінку моделі в умовах, типових для реального enterprise: дані мають кілька версій, інформація розкидана по різних системах, а доступ залежить від ролі користувача. За словами Ahmed Bashir, GPT-6.1 Sol показує гарні результати саме в цих умовах.

Окремо в Agent Studio користувачі можуть описувати поведінку інструменту в розмові з AI, а частину логіки фіксувати жорсткими правилами – тобто природна мова для гнучкої частини, детермінований код для критичної.

І ще один показовий факт із цього ж кейсу: увесь інженерний тім DevRev перейшов на Codex для написання коду і повністю відмовився від ліцензій Cursor. Ahmed формулює це так: "Developers are really just looking for the best tool, and you can't fool them."

Як перенести цей підхід на свого агента

У тебе навряд чи є доступ до Enterprise-Bench DevRev, але сама ідея "бенчмарк під власний domain" – універсальна практика, яку варто застосовувати до будь-якого production-агента. Ось чекліст, який можна використати як відправну точку, коли проєктуєш свого agent:

// Гіпотетичний приклад структури внутрішнього eval-кейсу
// для агента, що працює з ролевим доступом і версіями даних

interface AgentEvalCase {
  scenario: string;
  context: {
    hasMultipleDataVersions: boolean;
    dataSpreadAcrossSystems: boolean;
    accessDependsOnRole: boolean;
  };
  expectedBehavior: {
    mustCiteSource: boolean;
    actionMustBeReversible: boolean;
    maxLatencyMs: number;
  };
}

const evalCases: AgentEvalCase[] = [
  {
    scenario: "Користувач з обмеженою роллю просить скасувати підписку",
    context: {
      hasMultipleDataVersions: true,
      dataSpreadAcrossSystems: true,
      accessDependsOnRole: true,
    },
    expectedBehavior: {
      mustCiteSource: true,
      actionMustBeReversible: true,
      maxLatencyMs: 3000,
    },
  },
];

Це не код DevRev і не реальний API – просто шаблон мислення: якщо твій агент приймає рішення на основі даних, які можуть бути застарілими, розкиданими по кількох джерелах, і діє від імені користувача з певною роллю, то кожен такий кейс варто формалізувати до того, як агент потрапить у продакшн. Детальніше про те, як будувати такі eval-набори системно, – у статті Як тестувати AI-агента: eval dataset, regression tests і метрики замість «ніби працює».

Принцип reversibility і traceability з кейсу DevRev напряму перегукується з тим, що варто вбудовувати в observability свого агента – не просто логувати виклики моделі, а розуміти, яку дію агент виконав, чи можна її відкотити, і скільки це коштувало. Про це – у AI observability: чому агент витратив $8 і все одно викликав не той tool.

Окремо DevRev згадує Decisions API та Ultrafast як спосіб завершувати частину workflows швидко, без глибокого reasoning на кожному кроці – коли логіка складна й дорога для жорстких правил, але не вимагає повноцінного LLM reasoning щоразу. Це та сама ніша, яку розбирали в OpenAI Decisions API vs Jev: «AI-powered if/else» стає окремою категорією – варто порівняти підходи, якщо думаєш про швидкі рішення всередині агентного pipeline.

Якщо хочеш подивитись детальніше саме на модель GPT-6.1 Sol у реальному продукті – вона вже розбиралась у контексті code review в GPT-6.1 Sol у CodeRabbit: security review бачить код за межами одного PR. Цікаво порівняти, як та сама модель поводиться в двох зовсім різних задачах – code review проти enterprise customer service.

Чесні обмеження цього кейсу

Варто тверезо дивитись на те, що це – promotional-кейс від OpenAI про клієнта OpenAI. Жодних конкретних цифр benchmark, latency в мілісекундах чи вартості запиту в матеріалі немає – є лише якісні твердження CTO компанії, яка зацікавлена показати себе в хорошому світлі.

Заява "Codex is far and away the best experience" – суб'єктивна думка однієї команди, яка перейшла з Cursor. Це не означає, що Codex об'єктивно кращий для твоєї команди чи твого стеку: вибір coding-інструменту залежить від мови, розміру кодбази, стилю роботи і безлічі факторів, яких в кейсі просто немає.

Так само Enterprise-Bench – внутрішній бенчмарк DevRev, збудований під їхні конкретні сценарії. Він не публічний, і ти не можеш перевірити GPT-6.1 Sol на ньому самостійно. Це хороший приклад підходу "будуй свій бенчмарк", але не готовий інструмент, яким можна скористатись напряму.

Ще один момент – lock-in. DevRev будує і Computer, і Operator, і внутрішню розробку на одному вендорі (OpenAI). Це спрощує інтеграцію й підтримку, але означає залежність від одного постачальника моделей для критичного production-функціоналу. Якщо твоя команда розглядає подібну архітектуру, варто явно прорахувати, що станеться з reversibility і permissions-шаром, якщо доведеться міняти модель або провайдера.

Коли це варто брати собі

Підхід DevRev має сенс копіювати не через конкретні моделі, а через структуру рішень:

  • якщо агент діє від імені користувача з певними правами – формалізуй permission-шар окремо від LLM, а не покладайся на те, що модель "зрозуміє роль";
  • якщо дії агента незворотні за замовчуванням – додай явний reversibility layer до того, як агент отримає доступ до production-даних;
  • якщо твої дані мають кілька версій і розкидані по системах – побудуй власний мінімальний набір eval-кейсів під ці умови, навіть якщо він на 20 сценаріїв, а не на enterprise-масштаб;
  • якщо вибираєш coding-інструмент для команди – дай розробникам самим спробувати кілька варіантів і подивись, куди вони прийдуть органічно, як і сталось у DevRev з Codex.

Головний практичний висновок з цього кейсу – не "використовуй GPT-6.1 Sol", а "відокремлюй reasoning моделі від control-шару permissions і reversibility". Модель можна поміняти за тиждень, якщо з'явиться краща. Архітектуру контролю над діями агента – ні.