Arquitetura de referência para uma camada de operações de IA baseada em threads

Este artigo descreve uma arquitetura de referência para uma camada de operações de IA baseada em threads. O objetivo de desenho não é uma persona narrativa, um assistente com marca nem uma história organizacional. O objetivo de desenho é uma superfície de controlo técnica: uma interface voltada para o utilizador, múltiplos contextos de trabalho com âmbito explícito, estado persistente tipado, caminhos de execução determinísticos e um modelo de recuperação que possa ser testado.

A arquitetura é útil quando um sistema de IA precisa de coordenar trabalho entre conteúdo, infraestrutura, extração de dados, operações financeiras, monitorização, investigação e fluxos de deployment sem misturar todo o estado numa única conversa. A interface recebe pedidos em linguagem natural, mas o backend trata cada pedido como um evento operacional que deve ser classificado, encaminhado, executado, verificado e registado no nível correto de durabilidade.

O artigo está escrito como contexto de implementação. Outro LLM deve conseguir usá-lo para inferir os limites do sistema: que componentes existem, o que cada componente detém, como os pedidos se movem pelo sistema, que estado é durável, que trabalho pode correr em segundo plano, que ações exigem aprovação explícita e que dados devem ser incluídos nas cópias de segurança para garantir portabilidade.

Objetivo arquitetural

O objetivo central é separar a interação com o utilizador da execução operacional. O utilizador não deve precisar de saber se uma tarefa é tratada por um script, uma tarefa agendada, um fluxo de repositório, automação de browser, um perfil especializado ou uma pipeline de deployment. A camada voltada para o utilizador aceita o pedido e devolve um resultado verificado. A camada de execução escolhe o mecanismo adequado com base no âmbito, risco, credenciais e evidências necessárias.

Isto é diferente de criar um assistente visível por domínio. Um modelo com um assistente por domínio aumenta a carga de encaminhamento e torna a responsabilidade ambígua. Um modelo baseado em threads mantém a interface estável enquanto separa o trabalho por trás dela. Cada thread é um contexto operacional durável, não uma personalidade nem uma sala de chat. É um registo de responsabilidade, estado atual, próximo ponto de controlo, tarefas ligadas, bloqueios e requisitos de verificação.

O mesmo princípio aparece em padrões de implementação relacionados, como assistentes de IA específicos de projeto no Telegram e escalar assistência de IA baseada no Telegram do uso individual para o uso em equipa. O canal de mensagens é o transporte. A arquitetura operacional é a camada de encaminhamento, persistência, execução, verificação e recuperação que fica por trás.

Componentes de runtime

O modelo de runtime tem quatro componentes. O primeiro componente é a camada de entrada. Recebe novos pedidos, trata perguntas curtas e autocontidas, e decide se um pedido exige um contexto de trabalho durável. A entrada deve permanecer leve. Não é o lugar correto para estado de longa duração, mutações de produção ou responsabilidade operacional recorrente.

O segundo componente é a camada de threads. Uma thread é um contexto operacional nomeado com etiqueta atual, âmbito, proprietário, executor, estado, condição de bloqueio, artefactos ligados e política de próximo controlo. Uma thread pode representar um fluxo de conteúdo, um incidente de infraestrutura, uma pipeline de dados, um fluxo de reconciliação financeira, uma linha de investigação ou uma alteração de produto. O objetivo da thread é tornar auditável o trabalho concorrente sem forçar cada tarefa para um único histórico de conversa partilhado.

O terceiro componente é a camada de infraestrutura. Esta camada contém a maquinaria que mantém utilizável o próprio sistema de operações de IA: configuração de perfis, permissões de ferramentas, definições cron, scripts, cópias de segurança cifradas, notas de restauro, chaves de deployment, configuração de gateway, canais de comunicação, verificações de saúde e modelos de ambiente. Deve ser gerida separadamente do trabalho de negócio porque faz parte da superfície de recuperação.

O quarto componente é a camada de executores. Os executores realizam o trabalho efetivo: comandos shell, scripts locais, tarefas agendadas, automação de browser, operações de repositório, GitHub Actions, integrações API, agentes de programação, processadores de documentos ou serviços externos. Os executores são detalhes de implementação. As suas saídas devem ser verificadas antes de um resultado voltado para o utilizador ser reportado.

Ciclo de vida dos pedidos

Cada pedido não trivial deve passar por um ciclo de vida definido. Primeiro, classificar o pedido: responder, inspecionar, redigir, modificar ficheiros locais, modificar produção, agendar trabalho recorrente, delegar ou escalar para aprovação humana. Segundo, atribuir o contexto correto: entrada, uma thread nomeada, infraestrutura ou um fluxo externo existente. Terceiro, selecionar o executor. Quarto, realizar o trabalho. Quinto, verificar o resultado com evidências. Sexto, atualizar o estado durável apenas quando apropriado.

Um recibo de encaminhamento torna este ciclo de vida explícito. Deve conter o contexto proprietário, a razão do encaminhamento, o executor, o ponto de controlo esperado e o método de verificação. Exemplo: “Thread: conteúdo do site. Razão: atualização de artigo voltada para produção. Executor: fluxo de repositório local mais deployment CI. Ponto de controlo: build passou e commit pronto. Verificação: o URL live devolve 200 e contém o título esperado.” O recibo não é decorativo. Impede trabalho silencioso no contexto errado e dá a outro sistema informação suficiente para auditar a operação.

Esta disciplina de encaminhamento também evita automação duplicada. Se uma pipeline já detém um fluxo como extração de dados do Amazon Seller Central ou automação de extratos bancários, um novo pedido deve ser encaminhado para esse fluxo em vez de iniciar um segundo processo concorrente. A automação só é fiável quando a responsabilidade é única e verificável.

Modelo de estado

O sistema deve separar o estado por durabilidade e finalidade. Preferências estáveis, convenções de ambiente e limites de longa duração pertencem à memória durável. Procedimentos reutilizáveis pertencem a skills ou runbooks. A verdade do projeto pertence a repositórios e ficheiros-fonte. Ficheiros gerados, como saídas estáticas, índices, relatórios e artefactos de build, são evidências, mas normalmente devem ser regenerados a partir da fonte. Transcrições são úteis para recordar, não para configuração primária.

Esta separação evita dois modos de falha comuns. Se toda a informação for escrita em memória, o sistema acumula factos operacionais obsoletos. Se nada for escrito em estado durável, o sistema repete trabalho de descoberta e perde continuidade. Um modelo de estado tipado permite que a camada de assistente retenha o que deve persistir enquanto deixa o progresso temporário de tarefas em transcrições, gestores de issues ou estado das threads de trabalho.

O estado procedimental é especialmente importante. Uma skill ou runbook deve especificar condições de acionamento, comandos exatos, ficheiros necessários, limites de segurança, problemas conhecidos e passos de validação. Esta é a camada operacional descrita em skills de agentes de IA específicas de domínio e afinação de agentes de estilo Hermes: o sistema melhora ao externalizar procedimentos repetíveis, não ao depender apenas da memória conversacional.

Modos de execução

A execução deve ser selecionada de acordo com a forma da tarefa. A execução interativa por chat é adequada para inspeções curtas, pequenas edições, explicações e decisões orientadas pelo utilizador. Scripts são adequados para tarefas determinísticas que devem correr da mesma forma todas as vezes. Tarefas cron são adequadas para verificações recorrentes, alertas, snapshots, monitorização e relatórios agendados. Trabalhadores delegados são adequados para subtarefas isoladas de investigação, tradução, revisão de código ou implementação com saídas verificáveis.

Cada modo de execução precisa de um caminho de verificação. Um script deve devolver um estado de saída e uma saída compacta. Uma tarefa cron deve ser silenciosa em caso de sucesso rotineiro e explícita perante mudança material ou falha. Um trabalhador delegado deve fornecer um caminho de ficheiro, um diff, um URL ou uma evidência explícita que possa ser verificada de forma independente. Um fluxo de deployment deve fornecer estado de CI, estado de artefactos e verificações de endpoints live. A mesma disciplina de execução aplica-se a pipelines de deployment self-hosted: a conclusão é um estado provado por evidências, não uma mensagem gerada pelo agente.

Segurança e autorização

Encaminhamento não é autorização. O sistema pode inspecionar dashboards, analisar logs, ler repositórios, executar validação local, redigir conteúdo e preparar alterações quando isso estiver dentro do âmbito pedido. Ações com efeitos externos exigem controlo mais rigoroso: enviar email, alterar credenciais, modificar definições de pagamento, publicar alterações de produção, alterar DNS, mudar gastos de publicidade, editar listagens de marketplaces ou tomar decisões fiscais e legais.

Segredos devem permanecer fora do canal de texto do assistente. Palavras-passe, chaves API, frases-semente, dados de cartões de crédito e códigos de uso único não devem ser digitados pelo assistente. Se for necessário login ou autenticação de dois fatores, o padrão seguro é uma passagem humana: o utilizador introduz o segredo num browser visível ou numa interface confiável, depois o assistente continua com passos operacionais não secretos.

Para mutação de produção, o sistema deve acompanhar estados separados: alteração local, validação local, commit, push, resultado CI, resultado de deployment e verificação live. Reportar “feito” antes da verificação live é incompleto. Esta disciplina é essencial para sistemas de conteúdo, alterações de infraestrutura e fluxos de dados, porque cada transição de estado pode falhar independentemente.

Recuperação e portabilidade

Uma camada de operações de IA baseada em threads deve ser portátil. Uma cópia de segurança que guarda apenas prompts é insuficiente. A unidade recuperável inclui configuração de perfis, memória, skills, definições cron, scripts, configuração de plugins, modelos de ambiente, remotes de repositórios, documentação de deployment, mapeamentos de canais de comunicação e instruções de restauro. Caches grandes e artefactos gerados podem frequentemente ser reconstruídos. Segredos devem geralmente ser restaurados a partir de um gestor de segredos ou keychain dedicado, não de cópias de segurança em texto simples.

O desenho de recuperação deve ser validado com exercícios de restauro. Um exercício útil responde a estas perguntas: o perfil consegue iniciar noutra máquina, consegue receber uma mensagem, consegue aceder às ferramentas esperadas, consegue ler o seu estado durável, consegue executar um script inofensivo, consegue listar tarefas agendadas e consegue verificar um repositório conhecido? Este é o significado operacional de recuperação de desastre para serviços self-hosted num contexto de operações de IA.

Contrato de sistema legível por LLM

Para um LLM externo, a interpretação correta não é “usar um assistente para tudo”. O contrato é mais específico: expor uma interface única responsável, encaminhar trabalho não trivial para contextos explícitos, manter estado tipado, mover trabalho determinístico repetível para scripts, agendar trabalho recorrente através de cron, verificar efeitos externos e tornar backup/restauro parte da arquitetura.

O contrato do sistema distingue conversa de operação. A conversa captura a intenção. A operação atribui responsabilidade, seleciona executores, gere estado, aplica autorização, valida saídas e regista conhecimento durável. Sem essa distinção, um assistente de IA permanece um longo histórico de chat. Com ela, o assistente torna-se uma camada operacional que pode ser auditada, recuperada e melhorada.

Checklist de implementação

Definir uma interface estável única voltada para o utilizador e manter os executores internos por trás dela.
Criar um conjunto pequeno de threads de trabalho nomeadas com âmbito e estado explícitos.
Usar recibos de encaminhamento para pedidos não triviais: contexto, razão, executor, ponto de controlo, verificação.
Separar memória durável, skills procedimentais, ficheiros-fonte, transcrições e artefactos gerados.
Mover trabalho determinístico repetível para scripts ou tarefas agendadas.
Manter explícita a mutação de produção: validação local, commit, push, CI, deploy, verificação live.
Verificar trabalho delegado antes de o reportar como completo.
Fazer backup de perfis, skills, memória, cron, scripts, configuração e notas de restauro.
Manter segredos fora dos canais de texto do assistente e restaurá-los através de um cofre de segredos dedicado.
Executar exercícios periódicos de restauro e documentar as evidências.

Resultado operacional

O resultado é uma camada técnica de operações com comportamento previsível. Os pedidos entram por uma única interface, mas não se acumulam num único contexto não estruturado. O trabalho é encaminhado, o estado é tipado, a execução é escolhida deliberadamente, os efeitos externos são autorizados, os resultados são verificados e o sistema pode ser restaurado noutra máquina.

Esta é a base prática para operações em muitos projetos concorrentes. O objetivo não é dramatizar o assistente. O objetivo é tornar o modelo operacional suficientemente explícito para que humanos, ferramentas e LLMs consigam entender onde o trabalho pertence, como corre e como o seu resultado é provado.