Soluções · Orquestração

Orquestração de agentes e processos duradouros

Aprofundamento

Um agente isolado pode resolver uma tarefa. Um sistema orquestrado conserva o trabalho até ao resultado.

Numa página

Sistemas que coordenam agentes, software, ferramentas e pessoas durante processos que devem conservar estado, esperar, recuperar-se e continuar até um resultado verificável.

01O trabalho importante costuma durar mais do que uma resposta. Um agente pode resumir um documento, consultar uma base de dados, preparar uma proposta ou invocar uma ferramenta.
02Uma arquitetura multiagente traz valor quando a especialização compensa a coordenação. A coordenação multiagente é útil quando a especialização, o paralelismo ou a revisão independente compensam o seu custo.
04Desenhar o nível de autonomia por ação. «Autónomo» não deveria ser uma propriedade global do sistema.

O trabalho importante costuma durar mais do que uma resposta

Um agente pode resumir um documento, consultar uma base de dados, preparar uma proposta ou invocar uma ferramenta. Mas muitos processos não terminam nesse passo.

O trabalho continua quando é preciso:

reunir informação adicional;
decidir entre vários percursos;
consultar sistemas diferentes;
esperar uma autorização ou um evento;
executar uma ação;
responder a uma falha;
retomar mais tarde;
verificar o efeito noutro sistema;
conservar aquilo que continua pendente.

Construímos arquiteturas que coordenam esse percurso e mantêm uma responsabilidade única pelo caso completo.

Uma arquitetura multiagente traz valor quando a especialização compensa a coordenação

A coordenação multiagente é útil quando a especialização, o paralelismo ou a revisão independente compensam o seu custo.

Uma operação precisa ainda de:

uma representação do objetivo;
um estado persistente;
ferramentas com contratos e permissões;
software determinista para regras e transações;
políticas de autoridade;
memória com proveniência e retenção;
eventos, prazos e recuperação;
intervenção humana desenhada;
avaliação do percurso;
um sinal de resultado.

Os agentes ocupam um lugar dentro dessa arquitetura. Não substituem o resto.

Repartir responsabilidade sem fragmentar o resultado

Agentes

Interpretam contexto, formulam hipóteses, decompõem trabalho ou escolhem entre ações permitidas. A sua liberdade é limitada por ferramentas, políticas e critérios de escalamento.

Software determinista

Aplica regras, cálculos, validações e transações que devem ser reproduzíveis. Também protege invariantes que não devem depender da resposta de um modelo.

Ferramentas

Ligam o raciocínio a dados e ações reais. Cada ferramenta declara entradas, saídas, efeitos, identidade, erros e permissões.

Workflows duradouros

Persistem o processo, recebem eventos, esperam, repetem, compensam e retomam. Mantêm a continuidade que uma sessão de agente não pode garantir.

Pessoas

Trazem contexto, critério, negociação e autoridade. Podem validar uma inferência, decidir um compromisso, aprovar, corrigir, parar ou redesenhar uma regra.

Orquestração

Conserva o objetivo e coordena as transições. Determina quem tem a responsabilidade seguinte e evita que um componente declare o trabalho terminado apenas porque concluiu a sua parte.

Desenhar o nível de autonomia por ação

«Autónomo» não deveria ser uma propriedade global do sistema.

Uma mesma operação pode conter ações com níveis distintos:

consultar sem autorização;
preparar uma proposta;
recomendar um percurso;
executar alterações reversíveis dentro de limites;
solicitar autorização para uma ação sensível;
proibir determinadas ferramentas ou efeitos;
parar perante informação contraditória;
escalar uma exceção não prevista.

Esta granularidade permite alargar o alcance onde a evidência o justifica e manter controlo onde o custo do erro o exige.

Manter estado durante o tempo real do processo

Um processo pode durar segundos, semanas ou meses. O desenho deve representar o tempo como parte do trabalho:

eventos que ainda não ocorreram;
informação prometida e não recebida;
autorizações pendentes;
prazos e caducidades;
dependências entre tarefas;
retentativas permitidas;
ações que não podem repetir-se;
mudanças de versão durante o processo;
responsáveis que mudam;
perguntas que continuam em aberto.

Persistir o estado evita que uma pessoa ou um agente tenha de reconstruir a história cada vez que o processo é retomado.

Recuperar-se sem ocultar o que aconteceu

As falhas fazem parte da operação: uma API não responde, um evento chega duas vezes, um modelo devolve uma saída inválida, uma autorização caduca ou uma ação conclui-se tecnicamente sem produzir o efeito esperado.

Desenhamos rotas para:

validar antes de atuar;
repetir apenas quando for seguro;
evitar duplicados;
compensar quando existe uma ação inversa;
conservar um estado consistente;
escalar com contexto;
deixar o caso explicitamente em aberto quando não pode ser resolvido;
explicar o que aconteceu e o que falta fazer.

A recuperação preserva a evidência da falha e converte-a em informação para operar e melhorar.

Human in the loop sem converter a pessoa numa fila de erros

A intervenção humana deve responder a uma razão concreta:

falta uma informação que só uma pessoa pode fornecer;
uma inferência precisa de validação de domínio;
existe um compromisso entre objetivos;
a ação exige autoridade;
a situação é nova ou de alto impacto;
o sistema precisa de correção ou de ser parado.

O caso deve chegar com contexto, alternativa, evidência e consequências. Também devem medir-se o tempo de espera, a taxa de correção e a recorrência do mesmo encaminhamento. Se uma pessoa resolve sempre a mesma exceção, talvez o sistema devesse aprender uma regra; se aprova sempre sem rever, talvez o controlo esteja mal desenhado.

Memória com propósito e política de esquecimento

Conservar contexto é essencial, mas armazenar tudo indefinidamente não é.

A arquitetura deve distinguir:

factos do caso;
decisões e autorizações;
contexto transitório;
conhecimento validado reutilizável;
hipóteses pendentes;
informação sensível;
dados sujeitos a caducidade ou eliminação.

Cada memória precisa de propósito, proveniência, acesso, versão e retenção. A capacidade de esquecer de forma controlada faz parte de uma memória responsável.

Avaliar o percurso completo

Uma avaliação de agente pode medir se escolheu uma ferramenta ou produziu uma resposta correta. Uma avaliação operacional deve acrescentar:

o resultado foi concluído?;
o estado permaneceu consistente?;
recuperou-se depois de uma falha?;
a ação foi idempotente?;
a pessoa recebeu um encaminhamento útil?;
o sistema absteve-se quando devia?;
pode explicar-se porque seguiu esse percurso?;
o custo e o tempo são razoáveis?;
que consequências surgiram depois?;
que parte deveria ser otimizada ou redesenhada?

O objeto de avaliação não é apenas o modelo. É a operação completa.

Onde pode aplicar-se

Operações empresariais

Pedidos e processos que atravessam ERP, documentos, aprovações, incidentes e sistemas auxiliares.

Investigação e conhecimento

Agentes especializados que procuram, comparam, estruturam, questionam e revêem evidência mantendo perguntas e proveniência.

Reporting e produção de conteúdos

Coordenação de dados, verificação, estrutura, redação, revisão, voz, legendas e publicação.

Projetos complexos e desenvolvimento de software

Trabalho distribuído entre pessoas e agentes, com decisões, dependências, revisões e execução retomável.

SuperPythagoras é a nossa linha de trabalho para este caso: trata pessoas e bots como participantes do mesmo sistema de trabalho e dá-lhes papéis, contratos de entrega, passagens ordenadas e revisão. SecondOpinion acrescenta uma perspetiva independente sobre cada alteração com consequências, formulada por quem não a escreveu, e deixa evidência do que foi construído e porquê.

Operações físicas de laboratório

Coordenação entre perceção, estimação de estado, planeamento, controlo, segurança e verificação em máquinas e ambientes definidos.

Orquestrar para poder otimizar

Quando o sistema conserva estados, decisões, tempos, exceções e resultados, pode aprender-se onde está a complexidade real.

A otimização pode modificar:

o reparto entre regras, modelos, agentes e pessoas;
a ordem e o paralelismo das tarefas;
os limiares de autorização ou escalamento;
a seleção de ferramentas ou modelos;
a informação preparada para uma decisão;
os prazos, prioridades e atribuições;
a forma de recuperar de uma falha;
o nível de autonomia de uma ação.

A orquestração é a estrutura que permite observar o trabalho como um sistema e melhorá-lo conservando a responsabilidade pelo resultado completo.

Onde continua esta explicação

Esta página explica as operações duradouras a partir do problema do cliente: que trabalho deve conservar-se, durante quanto tempo, com que autoridade e até que resultado.

A capacidade técnica — agentes, ferramentas tipadas, grafos e percursos, memória delimitada, workflows duradouros, sistemas multiagente, encaminhamento de modelos, orçamentos, critérios de paragem e avaliação de percursos — vive em Agentes e orquestração.

O enquadramento geral da operação completa vive em Inteligência operacional.

O que o sistema deve conservar

01ObjetivoQue resultado completo se procura e que condições permitem declará-lo concluído, parcial ou não resolvido.
02EstadoO que se sabe, o que se decidiu, o que se executou, o que está pendente e quem tem a responsabilidade seguinte.
03FunçõesO que corresponde a regras, software, modelos, agentes, otimização, ferramentas e pessoas.
04AutoridadeQue ações estão permitidas, quais exigem autorização e quem pode corrigir ou parar.
05Tempo e eventosComo se gerem esperas, prazos, eventos externos, retentativas e retomas.
06Memória e proveniênciaQue contexto deve conservar-se, de onde procede e que informação deve esquecer-se ou caducar.
07Resultado e melhoriaQue sinal demonstra o efeito e que rastos permitem avaliar e otimizar o percurso.

Resultado

Uma arquitetura operacional que mantém uma visão única do caso e coordena raciocínio, execução, esperas, pessoas e verificação.

O nível de autonomia pode variar por ação e evoluir com a evidência: desde preparar trabalho e recomendar até executar dentro de políticas e limites definidos.

Quando um agente isolado deixa de ser suficiente

01quando o trabalho deve continuar depois da conversa
02quando intervêm várias aplicações, agentes ou equipas
03quando algumas ações são irreversíveis ou precisam de autorização
04quando o processo espera eventos ou informação durante horas ou dias
05quando uma falha exige recuperar o estado e não repetir efeitos
06quando o contexto deve manter-se sem o reenviar manualmente
07quando o sistema deve explicar porque escolheu um percurso
08quando o resultado deve ser verificado num sistema diferente daquele que executou a ação

O sistema por dentro

Maturidade · Avaliação

Como se organiza: O processo é modelado como um conjunto de estados, transições, ferramentas, políticas e papéis. Os agentes interpretam e escolhem dentro de limites; o software determinista executa regras e transações; o workflow persiste, espera e recupera; e as pessoas intervêm com funções e autoridade explícitas.
O que pode examinar-se: Pode examinar-se uma execução completa, o estado antes e depois de cada transição, as ferramentas disponíveis, as políticas de autorização, a memória conservada, uma intervenção humana, uma falha com recuperação e o sinal utilizado para encerrar o caso.
Como se verifica: Avaliamos percursos completos e não apenas respostas: conclusão, consistência do estado, recuperabilidade, idempotência, qualidade de decisões, percentagem e utilidade dos escalamentos, tempos de espera, custo, rastreabilidade e efeito verificado. Também simulamos ferramentas indisponíveis, eventos duplicados, contexto contraditório e mudanças de modelo.

Condições e limites

A orquestração não corrige uma definição ambígua do resultado nem uma política organizativa inexistente. Os agentes continuam a depender da qualidade das suas ferramentas, contexto e avaliação. As ações de alto impacto precisam de permissões, limites e capacidade de intervenção proporcionais ao risco.