Голос став тією функцією, яку намагається якомога швидше впровадити кожна платформа ШІ-агентів. Очевидним кроком є створення його як окремого каналу — чогось, що існує поруч із вашим вебдодатком, CLI-інструментом або Telegram-ботом. Це здається інтуїтивно зрозумілим. Бачите голос — створюєте голосовий інтерфейс. Але такий інстинкт створює крихку архітектуру. Він дублює роботу, псує ваші логи та поступово викривлює контекст вашого проєкту.

В APC та APX ми обрали інший шлях. Голос — це не канал. Це режим. Він накладається на поверхню, а не замінює її. Саме правильне розуміння цієї відмінності не дає системі розпастися.

Неправильна абстракція

Коли ви сприймаєте голос як окремий канал, ви неявно припускаєте, що розмова з агентом голосом фундаментально відрізняється від розмови через текст. Команди розробників реагують на це розділенням кодової бази. Раптом з'являється CLI-канал і окремий voice-CLI-канал. З'являється веб-канал і паралельний voice-web-канал. Кожен із них потребує власних варіацій промптів, правил форматування та логіки обробки контексту.

Саме тут починається безлад. Будь-яка зміна поведінки агента тепер має бути скопійована в кілька дерев промптів. Якщо команда пропустить одну поверхню, досвід користувача фрагментується. Користувачі отримують один тон у тексті та дещо іншу особистість у мовленні. З часом ці невеликі невідповідності накопичуються, призводячи до системного розходження (drift). Переносний шар контексту перестає бути переносним, бо йому доводиться враховувати вокальну подачу в одній гілці та беззвучний текст в іншій. Абстракція «протікає», і ваше колись єдине визначення проєкту розпадається на набір специфічних для кожного каналу «костилів».

Розділення контексту та середовища виконання (Runtime)

Щоб запобігти цьому, ми розділили обов'язки між двома шарами, які залишаються суворо відокремленими.

APC зберігає контекст проєкту. Він визначає агентів, правила та навички, з яких складається проєкт. Думайте про це як про стабільне значення системи. Він відповідає на структурні запитання: Що цей агент знає? Що йому дозволено робити? Які інструменти він може викликати? APC має залишатися повністю незалежним від того, чи відображається відповідь на екрані, чи надсилається через чат-API, чи транслюється через динамік.

APX керує шаром середовища виконання (runtime). Він керує поверхнями, з якими ви безпосередньо взаємодієте: CLI, вебдодаток, десктопний інтерфейс, Telegram-бот. Коли користувач надсилає запит, APX вирішує, де і як представити відповідь. Вирішення того, чи форматувати відповідь для читання, чи оптимізувати її для мовлення, — це питання середовища виконання. Це належить до APX, а не до APC.

Таке розділення означає, що проєкт, визначений в APC, залишається цілісним незалежно від того, скільки поверхонь відкриває APX. Контракт не змінюється. Змінюється лише шар представлення.

Як насправді працюють режими

У нашій реалізації такі поверхні, як Telegram, CLI та вебдодаток, є каналами. Канал вказує, де відбулася взаємодія. Голос накладається через метадані каналу як режим. Режим вказує, як має поводитися відповідь.

Побудовник промптів (prompt builder) дотримується цієї межі. Він бере дані з контексту проєкту в APC, а потім перевіряє метадані каналу. Якщо десктопна поверхня працює в голосовому режимі, побудовник додає цільові інструкції лише в цей момент. Можливо, він дає моделі вказівки щодо коротших речень, чіткішої пунктуації для синтезу мовлення або правил вимови чисел. Якщо та сама десктопна поверхня працює в текстовому режимі, ці голосові інструкції взагалі не потрапляють у промпт.

Результатом є єдине дерево промптів для кожної поверхні. Немає окремої гілки voice-desktop. Немає варіанта whisper-web. Модифікатор застосовується лише тоді, коли його запитує середовище виконання, і лише в останній відповідальний момент. Основний промпт залишається незмінним.

Що ви отримуєте

Ця архітектура окупається трьома конкретними способами.

Нижчі витрати на обслуговування. Якби голос був окремим каналом, кожна поверхня потребувала б свого двійника. Вам довелося б підтримувати CLI-канал і voice-CLI-канал, Telegram-канал і voice-Telegram-канал тощо. Щоразу, коли ви коригуєте системний промпт, виправляєте помилку форматування або уточнюєте опис навички, вам довелося б поширювати цю зміну в обох деревах. Пропустите одну — і користувачі помітять розрив. Використовуючи режим, ви зберігаєте одне дерево промптів на кожну поверхню. Голос стає умовним накладенням, а не розгалуженням на шляху, тому ваше навантаження залишається лінійним при додаванні нових способів взаємодії.

Accurate logging. Channels record where an interaction happened. Modes record how the reply was delivered. A desktop interaction remains a desktop interaction whether the user read it or heard it. When your team traces a bug or reviews analytics, they do not have to reconcile "desktop-voice" against "desktop-text" as if they were different product surfaces. The channel identifier stays clean, and the mode flag sits neatly beside it in the metadata. Your logs stay honest, and debugging stays straightforward because location and behavior are not tangled together.

Clean project context. APC defines the contract. It should not care if a reply is spoken, whispered, or rendered in monospace font. Those are runtime concerns. By keeping voice formatting inside APX, we preserve APC's portability. You can lift an APC project definition and drop it into an entirely new runtime environment without dragging along voice-specific formatting assumptions or speech-optimization cruft. The boundary holds, and the project meaning remains stable.

Proof on the Desktop

Our own desktop path demonstrates this in daily use. Desktop is the surface. When a user enables speech, the system runs that same desktop surface in voice mode. Because voice lives in the mode layer, the desktop channel retains its full context and behavior. It does not become a different product with different rules. The prompt builder simply notices the flag and adds voice instructions only when necessary. When the user switches back to text, those instructions disappear entirely. The underlying project context never shifted. The desktop was always the desktop.

The Real Takeaway

The core idea is simple. APC describes stable project meaning. APX describes runtime execution. Voice is a modifier on a surface, not a replacement for one. Treat it that way, and your prompts stay small. Your logs stay clear. Your