Unified Context™ é a tecnologia e o padrão da Secretar.AI para conectar informações, interações e eventos da mesma entidade entre sistemas integrados. Entre agentes de IA, sua proposta é apoiar a continuidade da compreensão enquanto especialistas diferentes trabalham sobre essa entidade. Compreensão compartilhada não exige prompts idênticos nem acesso irrestrito a todos os registros.
Este artigo é voltado a equipes que projetam fluxos de agentes. Ele explica uma aplicação conceitual do Unified Context por meio de uma passagem hipotética de atendimento. A sequência descreve responsabilidades de projeto e critérios de avaliação; não especifica comportamento de runtime já lançado nem garante interoperabilidade entre quaisquer agentes.
Comece pela entidade e depois pela tarefa
Imagine agentes de vendas, agendamento e suporte ajudando o mesmo cliente em momentos diferentes. Vendas precisa da proposta aceita. Agendamento precisa do serviço contratado e dos horários disponíveis. O suporte depois precisa compreender um pedido de alteração do compromisso.
Encaminhar toda a conversa de vendas aos três agentes transfere texto, mas deixa perguntas abertas. Qual cadastro é a referência do cliente? A proposta foi aceita ou apenas discutida? O compromisso mudou desde a atuação do agente anterior?
Nesse exemplo, o ponto de partida proposto é uma referência estável ao cliente, acompanhada das referências à proposta e ao compromisso específicos. O escopo da organização também precisa ser explícito e verificado, independentemente de os identificadores serem globalmente únicos. São requisitos de implementação, não propriedades que um modelo pode inferir com segurança a partir de nomes parecidos.
Uma sequência conceitual de passagem
| Etapa | Informação necessária | Condição a verificar |
|---|---|---|
| Vendas conclui a tarefa | Referências do cliente e da proposta aceita | O aceite vem de uma fonte apropriada |
| Agendamento começa | Serviço, restrições e disponibilidade atual | A proposta pertence ao mesmo cliente e contratação |
| A reserva é registrada | Referência do compromisso e estado confirmado | A operação de agendamento realmente foi concluída |
| Suporte recebe uma alteração | Compromisso atual e histórico relevante | A reserva original ainda não foi alterada |
Nesse desenho, a passagem carrega informação suficiente para localizar os registros e compreender a tarefa pendente. Deve distinguir trabalho concluído de intenção. “Cliente pediu terça-feira” não pode se tornar “terça-feira está reservada” apenas porque o segundo agente leu um resumo.
Um consumidor de contexto poderia usar MCP para consultar registros, mas sua arquitetura de hosts, clientes e servidores descreve conexões, não esse fluxo específico de negócio. A relação precisaria ser implementada explicitamente. Visão geral da arquitetura MCP.
Preserve evidências ao produzir resumos
Resumos ajudam na orientação: o cliente quer um horário à tarde, a proposta cobre determinado serviço e uma conversa explicou os preparativos. Eles devem continuar distinguíveis dos registros que estabelecem o estado contratual ou operacional.
Proveniência descreve a origem e a produção de informações. A família PROV do W3C oferece modelos para representar essas relações. É uma referência útil para pensar evidências de contexto, sem implicar que Unified Context implemente PROV. Visão geral do W3C PROV.
Na passagem hipotética, preserve a referência à proposta aceita que sustenta o resumo da venda. Quando o suporte explicar por que existe um compromisso, deveria ser possível examinar o resultado da reserva em vez de depender da lembrança de um agente sobre a mensagem de outro.
Preserve também a incerteza. Se a integração não confirma o aceite, essa ausência deve permanecer visível ao agente seguinte. Reescrever uma afirmação incerta com mais confiança não é uma atualização da fonte.
Contexto compartilhado pode gerar visões diferentes
O agente de agendamento pode precisar apenas do serviço e das restrições de reserva. O suporte pode precisar do compromisso atual e de um relato breve da solicitação. Nenhuma das tarefas necessariamente exige todos os documentos tratados por vendas.
Uma implementação deveria definir quais registros e campos cada consumidor pode acessar e qual subconjunto é relevante à tarefa atual. São decisões distintas: um registro pode ser permitido e irrelevante. Afirmar que um sistema aplica esses limites exige revisão e testes desse sistema.
Isso também separa contexto e memória do agente. Um especialista pode manter notas de trabalho próprias enquanto registros de origem oferecem referências compartilhadas. A comparação Unified Context vs Agent Memory detalha essa distinção.
Trate mudanças antes de agir
Suponha que o suporte consulte um compromisso às 14h enquanto a recepcionista o move para 15h. Uma resposta posterior baseada no registro anterior pode ser coerente e desatualizada. O projeto precisa de uma regra para atualizar o contexto antes de uma ação que dependa do estado atual.
Nesse exemplo, o reagendamento deveria consultar o estado atual no sistema responsável pelo compromisso. Se a operação falhar, o agente deve comunicar a falha em vez de registrar sucesso no resumo. Se houver nova tentativa, o fluxo precisa evitar reservas duplicadas.
São perguntas concretas de engenharia para a aplicação consumidora. Unificação de contexto, isoladamente, não oferece controle transacional, garantias de concorrência nem permissão para modificar registros.
Teste a passagem com lacunas deliberadas
Comece com uma passagem bem-sucedida de vendas para agendamento. Repita com identidade não resolvida, proposta inacessível, compromisso desatualizado e fonte indisponível. Examine se o segundo agente percebe a diferença e se o fluxo evita representar uma operação incompleta como concluída.
Peça ao agente que recebe a tarefa para identificar o que permanece desconhecido e quais evidências sustentam o próximo passo. Revise as respostas das fontes junto à resposta gerada. Isso avalia a continuidade mais diretamente do que verificar se dois agentes produzem textos parecidos.
Para a camada de interfaces, leia Unified Context e MCP. Os artigos ajudam a separar conexão de capacidades, preparação de contexto e conclusão de uma operação de negócio.
Perguntas frequentes
Todos os agentes recebem o mesmo contexto?
Não precisam receber. Um projeto útil pode preservar referências compartilhadas da entidade e fornecer informações adequadas à tarefa e às regras de acesso de cada agente. O requisito importante é a consistência sobre os registros relevantes, representando informações ausentes ou restritas com clareza, sem preenchê-las por inferência.
Encaminhar a conversa é suficiente?
Pode ajudar o destinatário a compreender o diálogo, mas não estabelece o estado atual de registros externos. No exemplo da reserva, o destinatário também precisa saber se o aceite e o agendamento aconteceram. Conversa, resumo e registro confirmado têm papéis diferentes como evidência para a tarefa.
Contexto compartilhado garante ações corretas?
Não. Ações corretas também dependem de instruções, permissões, comportamento das ferramentas e estado atual das fontes. Este artigo descreve como Unified Context pode orientar a continuidade de informação entre agentes. Correção e isolamento precisam ser demonstrados pela implementação e pelos fluxos que a utilizam.