A voz tornou-se o recurso que todas as plataformas de agentes de IA correm para lançar. O movimento óbvio é construí-la como um canal independente, algo que reside ao lado do seu web app, da sua ferramenta CLI ou do seu bot do Telegram. Parece intuitivo. Você vê voz, você cria uma interface de voz. Mas esse instinto cria uma arquitetura frágil. Ele duplica o trabalho, corrompe seus logs e, lentamente, desfigura o contexto do seu projeto.

No APC e no APX, escolhemos uma rota diferente. A voz não é um canal. É um modo. Ela reside sobre uma superfície em vez de substituí-la. Acertar essa distinção é o que impede o sistema de sofrer uma deriva.

A Abstração Errada

Quando você trata a voz como um canal próprio, assume implicitamente que falar com um agente é uma conversa fundamentalmente diferente de digitar para um. As equipes de engenharia respondem dividindo a base de código. De repente, há um canal CLI e um canal separado voice-CLI. Há um canal web e um canal paralelo voice-web. Cada um exige suas próprias variações de prompt, regras de formatação e lógica de manipulação de contexto.

É aqui que a bagunça começa. Um ajuste no comportamento de um agente deve agora ser copiado por várias árvores de prompt. Se a equipe esquecer uma superfície, a experiência se fragmenta. Os usuários recebem um tom via texto e uma personalidade ligeiramente diferente via fala. Com o tempo, essas pequenas inconsistências se acumulam em uma deriva do sistema. A camada de contexto portátil deixa de ser portátil porque precisa considerar a entrega vocal em um ramo e o texto silencioso em outro. A abstração vaza, e sua definição de projeto, antes unificada, se esgarça em uma coleção de soluções improvisadas específicas de cada canal.

Separando o Contexto do Runtime

Para evitar isso, dividimos as responsabilidades entre duas camadas que permanecem estritamente separadas.

O APC detém o contexto do projeto. Ele define os agentes, as regras e as habilidades que compõem um projeto. Pense nele como o significado estável do sistema. Ele responde às perguntas estruturais. O que este agente sabe? O que ele tem permissão para fazer? Quais ferramentas ele pode chamar? O APC deve permanecer completamente agnóstico sobre se uma resposta é renderizada em uma tela, enviada por uma API de chat ou transmitida por um alto-falante.

O APX lida com a camada de runtime. Ele gerencia as superfícies que você realmente toca: a CLI, a aplicação web, a interface desktop, o bot do Telegram. Quando um usuário envia uma solicitação, o APX escolhe onde e como apresentar a resposta. Decidir se deve formatar uma resposta para leitura ou otimizá-la para fala é uma preocupação de runtime. Isso pertence ao APX, não ao APC.

Essa separação significa que um projeto definido no APC permanece intacto, não importa quantas superfícies o APX exponha. O contrato não muda. Apenas a camada de apresentação muda.

Como os Modos Realmente Funcionam

Em nossa implementação, superfícies como Telegram, CLI e o web app são canais. Um canal informa onde uma interação ocorreu. A voz é aplicada através de metadados do canal como um modo. Um modo informa como uma resposta deve se comportar.

O construtor de prompts respeita esse limite. Ele extrai informações do contexto do projeto no APC e, em seguida, inspeciona os metadados do canal. Se a superfície desktop estiver rodando no modo de voz, o construtor anexa instruções direcionadas apenas naquele momento. Talvez ele oriente o modelo para frases mais curtas, pontuação mais clara para síntese ou convenções de números falados. Se a mesma superfície desktop estiver rodando no modo de texto, essas instruções vocais nunca entram no prompt.

O resultado é uma única árvore de prompt por superfície. Não há um ramo separado voice-desktop. Não há uma variante whisper-web. O modificador é aplicado apenas quando o runtime solicita, e apenas no último momento responsável. O prompt principal permanece constante.

O Que Você Ganha

Esta arquitetura traz benefícios de três formas concretas.

Menores custos de manutenção. Se a voz fosse seu próprio canal, cada superfície precisaria de um gêmeo. Você manteria um canal CLI e um canal voice-CLI, um canal Telegram e um canal voice-Telegram, e assim por diante. Toda vez que você ajustasse um prompt de sistema, corrigisse um erro de formatação ou refinasse a descrição de uma habilidade, teria que propagar essa alteração em ambas as árvores. Se esquecer uma, os usuários notarão a lacuna. Ao usar um modo, você mantém uma única árvore de prompt por superfície. A voz torna-se uma sobreposição condicional em vez de uma bifurcação no caminho, de modo que sua carga de trabalho permanece linear à medida que você adiciona novas formas de interagir.

Registro de logs preciso. Os canais registram onde uma interação ocorreu. Os modos registram como a resposta foi entregue. Uma interação de desktop continua sendo uma interação de desktop, quer o usuário a tenha lido ou ouvido. Quando sua equipe rastreia um bug ou revisa métricas, ela não precisa reconciliar "desktop-voice" com "desktop-text" como se fossem superfícies de produto diferentes. O identificador do canal permanece limpo, e a flag de modo fica organizada ao lado dele nos metadados. Seus logs permanecem íntegros e a depuração continua direta, pois a localização e o comportamento não ficam emaranhados.

Contexto de projeto limpo. O APC define o contrato. Ele não deve se importar se uma resposta é falada, sussurrada ou renderizada em fonte monoespaçada. Essas são preocupações de tempo de execução. Ao manter a formatação de voz dentro do APX, preservamos a portabilidade do APC. Você pode pegar uma definição de projeto APC e inseri-la em um ambiente de execução inteiramente novo sem carregar suposições de formatação específicas de voz ou resíduos de otimização de fala. A fronteira se mantém e o significado do projeto permanece estável.

Prova no Desktop

Nosso próprio caminho de desktop demonstra isso no uso diário. O desktop é a superfície. Quando um usuário habilita a fala, o sistema executa essa mesma superfície de desktop no modo de voz. Como a voz reside na camada de modo, o canal de desktop retém todo o seu contexto e comportamento. Ele não se torna um produto diferente com regras diferentes. O construtor de prompts simplesmente percebe a flag e adiciona instruções de voz apenas quando necessário. Quando o usuário volta para o texto, essas instruções desaparecem completamente. O contexto subjacente do projeto nunca mudou. O desktop sempre foi o desktop.

A Principal Conclusão

A ideia central é simples. O APC descreve o significado estável do projeto. O APX descreve a execução em tempo de execução. A voz é um modificador de uma superfície, não um substituto para ela. Trate dessa forma, e seus prompts permanecerão pequenos. Seus logs permanecerão claros. Seus