Latência é uma decisão de produto, não de engenharia
Um agent profundo que pensa por três minutos pode parecer um colega ou uma aba travada, e a diferença nunca é a velocidade. É se você contou ao usuário para que serve a espera.
Apollo Space Research
Apollo Space
Faça a um agent raso uma pergunta e a resposta cai em um segundo. Faça a um profundo, do tipo que lê seu company brain, puxa um contrato, checa o calendário, rascunha a resposta e revê o próprio trabalho, e a resposta honesta pode levar três minutos. Três minutos é uma eternidade numa caixa de chat. É nada num dia de trabalho. Os mesmos três minutos parecem um colega pensando, ou uma aba travada que precisa ser fechada, e a espera é idêntica nos dois casos.
O que mudou não foi a latência. Foi o que a tela dizia enquanto você esperava.
Esse é todo o post. A espera não é o problema. A espera inexplicada é o problema. Latência é uma decisão de produto, não de engenharia, e a maioria dos times perde o momento tratando um agent lento-mas-profundo como um lento-mas-raso, e apelando para o spinner.
O reflexo que todo mundo tem, e por que ele falha
O movimento ingênuo é torná-lo mais rápido. Uma requisição leva três minutos; isso parece longo demais; então o instinto de engenharia entra em cena e vamos otimizar. Cachear a retrieval. Paralelizar as chamadas de ferramenta. Trocar o modelo grande por um menor nas pernas baratas. Raspar a cadeia.
É o instinto certo no lugar errado. Você consegue raspar alguns segundos de uma cadeia multi-especialista, e deveria. Mas uma resposta genuinamente profunda, uma que lê quatro fontes, raciocina entre elas, rascunha algo real e o checa, tem um piso. O piso é o trabalho. Você não consegue tornar “ler o contrato, achar a data de renovação, rascunhar o email, verificar que a data está certa” instantâneo, porque nenhum desses passos é enchimento. Cada segundo é um passo que o usuário de fato queria feito. Otimize o quanto quiser; o piso continua sendo um piso.
Então o time que só otimiza bate numa parede e conclui que o produto é lento demais para lançar. Eles estavam medindo a coisa errada. Mediram a duração. O usuário nunca estava reagindo à duração.
Aqui está o experimento que resolve isso. Pegue duas esperas idênticas de três minutos. Na frente da primeira, ponha um spinner. Na frente da segunda, ponha uma linha de texto que atualiza: Lendo o contrato… achei a data de renovação… rascunhando a resposta… checando a data contra o calendário. Mesmos três minutos. Mesma resposta. A primeira parece quebrada pelo segundo quarenta. A segunda parece assistir a alguém competente trabalhar, e as pessoas vão sentar pelos três minutos inteiros sem um lampejo de dúvida.
O gargalo nunca desaparece. Ele apenas se move, de quanto tempo o trabalho leva para o quão bem você o narra.
Três formatos honestos para uma espera
Uma vez que você aceita que a espera é uma superfície de design e não um bug, a pergunta para de ser “como tornamos isto rápido” e vira “que tipo de espera é esta, e como uma honesta se parece”. Há três formatos, e todo o ofício é escolher o certo para o trabalho à sua frente.
A versão ingênua usa um formato para tudo: o spinner, em toda requisição, independentemente de quanto o trabalho vá levar. Um spinner é uma promessa que diz isto está quase pronto. Ponha-o na frente de uma resposta de dois segundos e está tudo bem. Ponha-o na frente de uma de três minutos e ele mente. Pelo segundo trinta o usuário foi avisado “quase pronto” por vinte e oito segundos a mais, e uma promessa que fica quebrando é pior do que nenhuma promessa. O spinner não falhou porque era feio. Ele falhou porque contou a história errada sobre a duração da espera.
Os três formatos honestos mapeiam para três respostas honestas a uma pergunta: quão longo é isto, e você consegue assistir acontecer?
Confirme instantaneamente é para o trabalho que você não consegue mostrar e não consegue apressar. O usuário pede algo que vai levar o suficiente para que até narrá-lo seria uma coisa estranha de encarar, uma rodada de pesquisa, uma síntese multi-documento, uma tarefa que toca uma dúzia de fontes. Você não os faz assistir. Você responde em menos de um segundo com a única coisa honesta que pode dizer: Já estou nisso. Tenho isto para você em alguns minutos, vou te avisar. Aí você entrega o trabalho ao background e cumpre sua palavra. A confirmação não custa nada e muda tudo, porque converte uma espera em aberto numa fechada. O usuário vai e faz outra coisa. O agent volta. Isso não é uma experiência degradada; para trabalho longo, é a única boa.
Transmita o raciocínio é para a espera média, a cadeia de dez-a-noventa segundos onde os passos são legíveis e assisti-los é tranquilizador em vez de tedioso. Este é o formato que faz mais trabalho, porque transforma tempo morto em evidência. Cada passo que você revela, buscando no brain, achei três notas relevantes, rascunhando, checando o número, é simultaneamente uma barra de progresso e um recibo. O usuário não está só esperando; está assistindo a coisa ser feita corretamente, que é exatamente a ansiedade que um spinner deixa sem endereçar. E quando a resposta finalmente cai, ele já confia nela, porque assistiu ela ser construída.
Responda instantaneamente é o caso fácil, e a armadilha é esquecer que ele existe. Nem toda requisição é profunda. “O que tem na minha agenda hoje” nunca deveria transmitir seu raciocínio para você como se estivesse resolvendo um problema difícil, isso é teatro, e teatro erode confiança tão rápido quanto um spinner quebrado. Uma pergunta rasa merece uma resposta rasa, instantânea. A habilidade é saber qual pergunta você está segurando antes de escolher o formato.
A decisão acontece antes de o trabalho começar
Aqui está a parte fácil de inverter. O formato de latência não é algo que você escolhe depois que o trabalho está lento. É algo que você escolhe antes de o trabalho começar, porque na hora em que você sabe que foi lento, o usuário já esteve encarando a coisa errada.
O sistema ingênuo roda o trabalho, nota que está demorando, e então se atrapalha para mostrar algo. Tarde demais. Os primeiros cinco segundos definem a expectativa do usuário para a espera inteira, e você os gastou com um spinner que estava prestes a quebrar sua promessa. Você não consegue recuperar uma sensação de aba-travada adicionando narração no segundo sessenta. A história tem de começar no segundo zero.
Então a versão profunda faz uma decisão barata logo de cara: grosso modo, quanto isto vai levar, e qual dos três formatos serve? Essa estimativa não tem de ser precisa. Tem de ser cedo. Uma requisição para ler uma nota e responder é curta. Uma requisição que vai se ramificar para três especialistas é média-a-longa. Uma rodada de pesquisa é longa. Você não precisa saber se vai ser 47 segundos contra 71; você precisa saber que é do tipo streaming e não do tipo instantâneo, e precisa saber antes de o primeiro segundo de espera do usuário ser gasto.
Acerte a classificação e a espera se explica do primeiro frame. Erre-a e nenhum polimento depois a salva.
Onde os formatos quebram, e a regra que conserta
Mesmo com os três formatos certos, há duas falhas que aparecem na prática, e nomeá-las é como você as evita.
A primeira é a espera que termina em silêncio. Você avisou ao usuário vou te avisar, e então o job de background termina e nada avisa. Agora você ensinou a ele que sua confirmação é uma mentira, e na próxima vez que você disser “já estou nisso”, ele não vai acreditar. Uma promessa assíncrona só vale tanto quanto a notificação que a fecha. Se você não consegue entregar de forma confiável o pronto, você não tem por que oferecer a confirmação instantânea; seria melhor fazê-los esperar onde ao menos podem ver o spinner. O fechamento não é opcional. É a outra metade da promessa.
A segunda é o stream que não diz nada. Transmitir o raciocínio só tranquiliza se o raciocínio é legível. Um feed ao vivo de pensando… pensando… pensando… é um spinner com passos extras, tem movimento mas nenhuma informação, e o usuário aprende tão rápido que o movimento é vazio. Os passos que você revela têm de ser reais e específicos: a fonte que você leu, o rascunho que você fez, a checagem que você rodou. Suponha que uma cadeia rode oito passos internos; você não mostra oito, mostra os quatro que um humano reconheceria como progresso. Narração é um problema de curadoria, não uma mangueira aberta.
Ambas as falhas compartilham uma raiz, e ela nos dá a regra. A espera não é o problema. A espera inexplicada é o problema, e “explicada” significa que o usuário sempre sabe três coisas: que você o ouviu, o que você está fazendo, e quando termina. Erre qualquer uma delas e a melhor engenharia do mundo se lê como quebrada. Acerte as três e uma espera de três minutos se lê como competência.
É por isso que latência é uma decisão de produto. A engenharia decide quão rápido o trabalho pode ir. O produto decide como a espera parece, e o segundo número é o pelo qual o usuário de fato te avalia.
A virada: esperar nunca foi o inimigo
Dê um passo atrás dos agents por um segundo, porque isto não é realmente sobre agents.
Pense na última vez que você confiou algo difícil a alguém. Você não pediu que fosse instantâneo. Você pediu a um empreiteiro para reformar uma cozinha e não esperou que estivesse pronta na hora do almoço, você esperou uma data de início, uma noção dos passos, e uma ligação quando estivesse pronta. Você confiou nele mais pela linha do tempo honesta, não menos. Profundidade leva tempo, e uma pessoa que finge o contrário é uma pessoa em quem você para de acreditar. De alguma forma esquecemos de estender isso ao software, porque o software nos ensinou a esperar tudo num décimo de segundo, e então tratamos qualquer espera como uma falha.
Mas o trabalho mais valioso que um agent pode fazer para a sua empresa é exatamente o trabalho que leva um minuto, o ler-tudo, o rascunhar, o checar. Se insistirmos que tudo isso seja instantâneo, obtemos um agent rápido que faz coisas rasas, e jogamos fora o trabalho profundo porque ele não cabia num spinner. A troca melhor é a humana: deixe o trabalho profundo levar o tempo de que precisa, e gaste cuidado real na espera, para que um minuto de pensamento se leia do jeito que deveria, como alguém bom, fazendo algo que vale a espera.
Essa é a parte à qual continuamos voltando na Apollo: um colega tem permissão para pensar. O trabalho não é tornar toda resposta instantânea. É tornar toda espera honesta, te contar o que o agent está fazendo, e voltar no momento em que termina. Se você já encarou um spinner se perguntando se alguma coisa estava acontecendo, você já sabe que a espera nunca foi a coisa que te incomodou. Foi o silêncio.
A Apollo cuida da operação repetitiva da sua empresa pro seu time não precisar.
Entre na lista de espera: acesso antecipado, preço de usuário fundador e um lugar na primeira fila enquanto a gente constrói.
Entrar na lista de esperaO imposto oculto dos agents em paralelo é um diamante de migrations
Seis agents escrevendo para um schema conflitam no banco de dados, não no código, e a CI morre em "multiple heads".
EngenhariaUm orchestrator que não sobrevive ao próprio crash não é um
Um crash que apaga o raciocínio do orchestrator perde a única coisa que você não consegue reconstruir.
EngenhariaColoque um portão determinístico na frente do seu revisor mais esperto
A pega-defeito mais barata é um script burro que checa se duas branches mergeadas ainda sobem antes de qualquer julgamento.