A infraestrutura de agência e o novo backend

spinny:~/writing $ less agentic-infrastructure-stack.md

1 
2Muitas vezes falamos sobre estruturas de agência. LangGraph, CrewAI, AutoGen, vários SDKs, loop, chamada de ferramenta, memória, planejador, crítico, supervisor. Todas palavras úteis, pelo amor de Deus. Mas quanto mais observo os agentes realmente utilizados, mais me parece que a parte interessante deslocou-se para baixo do nível da estrutura.
3 
4A questão não é mais apenas: qual biblioteca devo usar para fazer um modelo passo a passo pensar?
5 
6A verdadeira questão é: onde mora esse agente quando deixa de ser um demo?
7 
8Porque um agente sério não é uma função que chama um modelo e retorna texto. É um pequeno sistema distribuído. Ele deve ler o contexto, usar ferramentas, executar código, mexer em arquivos, lembrar de decisões, pedir permissão, falhar bem, reiniciar, deixar logs, não queimar o orçamento e não virar uma escavadeira dentro do repositório de produção.
9 
10A estrutura é o volante. A infraestrutura é a estrada, os freios, a garagem, o seguro e quem sabe onde estão as chaves.
11 
12## Porque se fala muito sobre isso agora
13 
14Em 2023 e 2024 a conversa foi muito centrada no modelo. Qual LLM? Quanto contexto? Quanto custa isso? Quão bom ele é em programação?
15 
16Em 2025 e 2026 a conversa mudou. Os modelos são bons o suficiente para realizar trabalho real, mas é por isso que as partes chatas se tornam visíveis: tempo de execução, segurança, conectores, identidade, observabilidade, execução de código, implantação, reversão.
17 
18É a transição natural da magia para a engenharia.
19 
20Quando um agente precisa apenas gerar uma resposta, basta um chat. Quando você precisa abrir uma solicitação pull, consultar um banco de dados, chamar um CRM, iniciar um trabalho, navegar em um site, ler o Slack, compilar código e atualizar um documento, você precisa de um sistema operacional em torno disso.
21 
22Não no sentido literal. No sentido organizacional.
23 
24## A primeira parte: um tempo de execução onde o agente pode durar
25 
26Um agente geralmente trabalha em etapas. Observe o estado, escolha uma ação, use uma ferramenta, observe o resultado, atualize o plano, repita.
27 
28Se esse loop residir dentro de uma única solicitação HTTP, você terá um problema imediatamente. Algumas ações são lentas. Alguns aguardam a contribuição humana. Alguns falham e devem ser tentados novamente. Alguns devem sobreviver a uma implantação ou tempo limite.
29 
30É aqui que entram em jogo fluxos de trabalho duráveis, filas, históricos de trabalho e máquinas de estado. Eles não são glamorosos, mas são a diferença entre um agente que parece inteligente na demonstração e aquele que você pode deixar trabalhando enquanto vai tomar um café.
31 
32Para mim, o tempo de execução da agência deve responder a perguntas muito concretas:
33 
34- onde salvo o estado entre uma etapa e outra?
35- o que acontece se o processo morrer no meio?
36- posso fazer uma pausa e pedir aprovação?
37- posso repetir uma corrida para entender por que ele fez essa escolha?
38- posso limitar a duração, a memória, as ferramentas e o custo?
39 
40A Vercel está se esforçando bastante nessa frente com SDKs de IA, funções, fluxos de trabalho e ferramentas para construir agentes em aplicações web. Mas a questão não é apenas Vercel. A questão é que o agente precisa de um local operacional, não de um único terminal.
41 
42## A segunda peça: sandbox, pois o agente deve conseguir se sujar sem quebrar
43 
44Assim que um agente escreve código ou executa comandos, é necessária uma sandbox.
45 
46Parece uma palavra técnica, mas a ideia é doméstica: você dá uma bancada para ele. Ele pode abrir arquivos, instalar dependências, executar testes, fazer experimentos, gerar resultados. Se ele errar, você conteve o dano. Se funcionar, promova o resultado.
47 
48Um sandbox agente deve ter algumas propriedades:
49 
50- sistema de arquivos isolado;
51- CPU, memória e limites de tempo;
52- rede controlada;
53- segredos montados somente quando necessário;
54- registros completos;
55- possibilidade de exportar artefatos;
56- reinicialização limpa entre execuções, quando necessário.
57 
58O Vercel Sandbox vai exatamente nessa direção: ambientes isolados para executar código, instalar dependências, trabalhar com arquivos e produzir artefatos sem executar tudo no tempo de execução da aplicação principal.
59 
60Essa coisa é mais importante do que parece. Muitos protótipos agentes saltam diretamente do modelo para o sistema real. O modelo pode chamar tool. As ferramentas podem fazer coisas. Tudo parece elegante até o primeiro comando errado, a primeira dependência instalada no lugar errado, o primeiro token que vai parar em um log.
61 
62A caixa de areia é a forma adulta de dizer: vá em frente, mas aqui.
63 
64## A terceira peça: MCP e o problema do conector
65 
66O Model Context Protocol tornou-se uma das partes mais interessantes do ecossistema porque tenta padronizar algo que de outra forma rapidamente se tornaria incontrolável: como um modelo descobre e usa ferramentas externas.
67 
68Sem um padrão, cada integração é uma pequena ilha. Um conector para GitHub feito de uma maneira, um para Slack feito de outra, um para bancos de dados com semântica diferente, um para automação de navegador que parece nada.
69 
70O MCP propõe uma linguagem comum entre cliente e servidor: ferramentas, recursos, prompts, autorizações, transporte, descoberta. Não resolve magicamente a governança e a segurança, mas fornece uma gramática.
71 
72E a gramática é importante. Quando um agente pode se conectar a muitas ferramentas, a questão não é apenas “ele consegue fazer isso?”. O problema é “ele entende o que pode fazer, com quais limites, em nome de quem e deixando quais rastros?”.
73 
74Para mim, o MCP não é exagero porque "faz chamadas de ferramentas". Nós já fizemos isso. É um exagero porque muda o centro de gravidade da integração única para o catálogo operacional de ferramentas.
75 
76Em uma boa arquitetura agêntica, o MCP se torna uma espécie de patch panel:
77 
78- GitHub para código e problemas;
79- Slack para contexto conversacional;
80- Linear ou Jira para trabalhos planejados;
81- banco de dados somente leitura para análises;
82- navegador ou raspador controlado para sites externos;
83- armazenamento de documentos;
84- ambientes de execução isolados;
85- sistemas internos expostos com permissões estritas.
86 
87A parte complicada é que um catálogo de ferramentas sem políticas é apenas uma forma mais elegante de criar o caos.
88 
89## A quarta peça: identidade e permissões
90 
91Esta é a área onde muitas demonstrações fecham os olhos.
92 
93Um agente atua em nome de alguém. Portanto, deve ficar claro quem é o sujeito da ação.
94 
95Está usando permissões de usuário? De uma conta de serviço? De um espaço de trabalho? Você tem acesso temporário ou permanente? Você consegue ler tudo ou apenas alguns recursos? Você pode escrever? Você pode cancelar? Ele pode enviar mensagens para pessoas reais?
96 
97Se você não responder bem a essas perguntas, mais cedo ou mais tarde construirá um assistente com as chaves de casa e sem memória de quem as deu a ele.
98 
99A regra que gosto é esta: o agente deve ser capaz de fazer menos que o humano, e não mais que o humano. E quando ele tem que fazer algo mais arriscado, ele tem que parar e perguntar.
100 
101Isso significa OAuth, escopo de token, gerenciamento de segredos, log de auditoria, política de ferramentas, lista de permissões, etapa de aprovação. Coisas não muito românticas. Coisas necessárias.
102 
103## A quinta peça: memória e contexto, mas sem acumular lixo
104 
105Os agentes precisam de memória, mas a memória é perigosa quando se transforma num sótão.
106 
107Existem pelo menos três tipos de memória:
108 
109- memória de execução: o que aconteceu nesta execução;
110- memória de projeto: convenções, decisões, restrições;
111- memória pessoal ou de equipe: preferências, tom, rituais, processos.
112 
113Colocar tudo no prompt é o atalho. Funciona até não funcionar mais. A memória útil deve ser cuidada: indexada, atualizada, expirada, verificada, tornada citável.
114 
115Um agente que se lembra mal é pior do que um agente que não se lembra. Porque ele fala com confiança.
116 
117Portanto, a infra-estrutura deve incluir recuperação, arquivos de instruções, base de conhecimento, incorporação quando necessário, mas também limpeza. Precisamos de uma cultura da memória: o que entra, quem aprova, quando decai, como faço para corrigir.
118 
119## A sexta peça: observabilidade, avaliação e repetição
120 
121Se um agente cometer um erro, o log “chamado de modelo” não será suficiente.
122 
123Você quer ver a rota. Que contexto ele recebeu? Quais ferramentas estavam disponíveis? Qual ferramenta você escolheu? Com que argumentos? Que resposta você obteve? Quanto custou? Onde ele ficou preso? O humano aprovou alguma coisa? O erro é um erro de modelo, ferramenta, prompt, dados ou permissão?
124 
125Aqui os agentes são mais parecidos com sistemas distribuídos do que chatbots.
126 
127Você precisa de rastreamentos legíveis, não apenas de registros de texto. Você precisa ser capaz de reproduzir uma corrida. É necessário comparar duas versões do mesmo agente em tarefas conhecidas. Precisamos medir as regressões: não apenas "responde melhor", mas também "fecha o ticket certo sem tocar em arquivos não solicitados".
128 
129As avaliações de agente são mais difíceis do que as avaliações de texto porque incluem ações. Não é suficiente comparar uma string esperada. É preciso observar as sequências, os efeitos colaterais, a qualidade do artefato, o tempo, o custo, o número de intervenções humanas.
130 
131O engraçado é que sempre voltamos lá: engenharia de software. Testes, ambientes, rastreamentos, reversões. Só que o código agora também decide o que fazer a seguir.
132 
133## A sétima peça: interfaces humanas
134 
135O agente não precisa apenas viver em um chat.
136 
137Alguns agentes precisam de um conselho. Outros uma página com status e log. Outros de um botão "aprovar". Mais comentários embutidos. Ainda outros de uma CLI.
138 
139A IU muda o comportamento. Se a única maneira de controlar um agente for escrever uma mensagem longa, o usuário dará instruções vagas ao agente. Se, no entanto, ele vir o plano, as diferenças, as fontes, os riscos e a próxima ação, ele poderá intervir com precisão.
140 
141Uma infraestrutura de agente decente inclui superfícies de controle:
142 
143- situação atual;
144- plano editável;
145- artefatos produzidos;
146- diferença;
147- solicitações de aprovação;
148- cronologia;
149- botão parar;
150- botão de tentar novamente;
151- permissões visíveis.
152 
153Parece trivial, mas não é. A diferença entre “IA assustadora” e “assistente confiável” geralmente é apenas que o último mostra onde está as mãos.
154 
155## A pilha mental
156 
157Se eu comprasse hoje, o stack mínimo do agente seria este:
158 
1591. Modelo: raciocínio, geração, chamada de ferramenta, multimodal se necessário.
1602. Orquestração: loop, etapa, planejador, política, humano no circuito.
1613. Tempo de execução durável: fluxo de trabalho, fila, nova tentativa, pausa, retomada.
1624. Sandbox: execução de código, sistema de arquivos isolado, limitações, artefatos.
1635. Camada de ferramentas: MCP, API interna, navegador, banco de dados, repositório.
1646. Camada de identidade: OAuth, escopo, segredo, auditoria, política.
1657. Camada de memória: contexto do projeto, recuperação, instruções, expiração.
1668. Observabilidade: métricas de rastreamento, repetição, avaliação, custo e qualidade.
1679. Superfície do produto: converse quando for suficiente, painel quando necessário, revise quando for importante.
168 
169A estrutura de agência cobre principalmente os pontos 2 e uma parte do ponto 1. O resto é o verdadeiro trabalho.
170 
171## O que eu faria na prática
172 
173Se uma equipe me dissesse “queremos agentes em produção”, eu não começaria com dez agentes.
174 
175Eu começaria com um fluxo de trabalho pequeno, repetitivo e observável. Por exemplo: abrir PRs de manutenção, atualizar a documentação de problemas fechados, preparar uma revisão semanal, fazer triagem de bugs duplicados, gerar testes para arquivos afetados.
176 
177Então eu estabeleceria limites muito claros:
178 
179- não é permitido escrever sem ramificações ou sandbox;
180- sem segredos no prompt;
181- ferramentas na lista de permissões;
182- aprovação humana para ações externas;
183- registro e rastreamento obrigatórios;
184- orçamento por execução;
185- saída sempre inspecionável.
186 
187Só então eu expandiria.
188 
189Os agentes não falham só porque os modelos erram. Eles falham porque os colocamos em ambientes vagos, com permissões confusas e expectativas teatrais.
190 
191## Minha leitura
192 
193A infraestrutura agente é entediante da melhor maneira.
194 
195Não é a parte que te faz bater palmas na demo. É a parte que permite que você realmente use a demonstração na manhã de segunda-feira, com pessoas reais, dados reais e consequências reais.
196 
197O futuro dos agentes não será decidido apenas por quem tiver o melhor modelo. Será decidido por quem construir o melhor lugar para fazê-lo trabalhar: isolado quando experimenta, conectado quando necessário, sempre observável, autorizado com critério e humilde o suficiente para parar quando não sabe.
198 
199É aí que os agentes deixam de ser um brinquedo e passam a ser infraestrutura.
200 
201## Fontes
202 
203- [Vercel: Como construir agentes de IA com Vercel e o AI SDK](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)
204- [Documentos Vercel: Sandbox](https://vercel.com/docs/sandbox)
205- [Vercel Docs: Trabalhando com Sandbox](https://vercel.com/docs/sandbox/working-with-sandbox)
206- [Documentos Vercel: MCP](https://vercel.com/docs/mcp)
207- [Protocolo de Contexto do Modelo: Especificação](https://modelcontextprotocol.io/specification)
208- [OpenAI: Novas ferramentas para agentes de construção](https://openai.com/index/new-tools-for-building-agents/)
209- [Blog da Cloudflare: Agentes na Cloudflare](https://blog.cloudflare.com/agents-on-cloudflare/)
210

:A infraestrutura de agência e o novo backendlines 1-210 (END) — press q to close

2Muitas vezes falamos sobre estruturas de agência. LangGraph, CrewAI, AutoGen, vários SDKs, loop, chamada de ferramenta, memória, planejador, crítico, supervisor. Todas palavras úteis, pelo amor de Deus. Mas quanto mais observo os agentes realmente utilizados, mais me parece que a parte interessante deslocou-se para baixo do nível da estrutura.

4A questão não é mais apenas: qual biblioteca devo usar para fazer um modelo passo a passo pensar?

6A verdadeira questão é: onde mora esse agente quando deixa de ser um demo?

8Porque um agente sério não é uma função que chama um modelo e retorna texto. É um pequeno sistema distribuído. Ele deve ler o contexto, usar ferramentas, executar código, mexer em arquivos, lembrar de decisões, pedir permissão, falhar bem, reiniciar, deixar logs, não queimar o orçamento e não virar uma escavadeira dentro do repositório de produção.

10A estrutura é o volante. A infraestrutura é a estrada, os freios, a garagem, o seguro e quem sabe onde estão as chaves.

12## Porque se fala muito sobre isso agora

14Em 2023 e 2024 a conversa foi muito centrada no modelo. Qual LLM? Quanto contexto? Quanto custa isso? Quão bom ele é em programação?

16Em 2025 e 2026 a conversa mudou. Os modelos são bons o suficiente para realizar trabalho real, mas é por isso que as partes chatas se tornam visíveis: tempo de execução, segurança, conectores, identidade, observabilidade, execução de código, implantação, reversão.

18É a transição natural da magia para a engenharia.

20Quando um agente precisa apenas gerar uma resposta, basta um chat. Quando você precisa abrir uma solicitação pull, consultar um banco de dados, chamar um CRM, iniciar um trabalho, navegar em um site, ler o Slack, compilar código e atualizar um documento, você precisa de um sistema operacional em torno disso.

22Não no sentido literal. No sentido organizacional.

24## A primeira parte: um tempo de execução onde o agente pode durar

26Um agente geralmente trabalha em etapas. Observe o estado, escolha uma ação, use uma ferramenta, observe o resultado, atualize o plano, repita.

28Se esse loop residir dentro de uma única solicitação HTTP, você terá um problema imediatamente. Algumas ações são lentas. Alguns aguardam a contribuição humana. Alguns falham e devem ser tentados novamente. Alguns devem sobreviver a uma implantação ou tempo limite.

30É aqui que entram em jogo fluxos de trabalho duráveis, filas, históricos de trabalho e máquinas de estado. Eles não são glamorosos, mas são a diferença entre um agente que parece inteligente na demonstração e aquele que você pode deixar trabalhando enquanto vai tomar um café.

32Para mim, o tempo de execução da agência deve responder a perguntas muito concretas:

34- onde salvo o estado entre uma etapa e outra?

35- o que acontece se o processo morrer no meio?

36- posso fazer uma pausa e pedir aprovação?

37- posso repetir uma corrida para entender por que ele fez essa escolha?

38- posso limitar a duração, a memória, as ferramentas e o custo?

40A Vercel está se esforçando bastante nessa frente com SDKs de IA, funções, fluxos de trabalho e ferramentas para construir agentes em aplicações web. Mas a questão não é apenas Vercel. A questão é que o agente precisa de um local operacional, não de um único terminal.

42## A segunda peça: sandbox, pois o agente deve conseguir se sujar sem quebrar

44Assim que um agente escreve código ou executa comandos, é necessária uma sandbox.

46Parece uma palavra técnica, mas a ideia é doméstica: você dá uma bancada para ele. Ele pode abrir arquivos, instalar dependências, executar testes, fazer experimentos, gerar resultados. Se ele errar, você conteve o dano. Se funcionar, promova o resultado.

48Um sandbox agente deve ter algumas propriedades:

50- sistema de arquivos isolado;

51- CPU, memória e limites de tempo;

52- rede controlada;

53- segredos montados somente quando necessário;

54- registros completos;

55- possibilidade de exportar artefatos;

56- reinicialização limpa entre execuções, quando necessário.

58O Vercel Sandbox vai exatamente nessa direção: ambientes isolados para executar código, instalar dependências, trabalhar com arquivos e produzir artefatos sem executar tudo no tempo de execução da aplicação principal.

60Essa coisa é mais importante do que parece. Muitos protótipos agentes saltam diretamente do modelo para o sistema real. O modelo pode chamar tool. As ferramentas podem fazer coisas. Tudo parece elegante até o primeiro comando errado, a primeira dependência instalada no lugar errado, o primeiro token que vai parar em um log.

62A caixa de areia é a forma adulta de dizer: vá em frente, mas aqui.

64## A terceira peça: MCP e o problema do conector

66O Model Context Protocol tornou-se uma das partes mais interessantes do ecossistema porque tenta padronizar algo que de outra forma rapidamente se tornaria incontrolável: como um modelo descobre e usa ferramentas externas.

68Sem um padrão, cada integração é uma pequena ilha. Um conector para GitHub feito de uma maneira, um para Slack feito de outra, um para bancos de dados com semântica diferente, um para automação de navegador que parece nada.

70O MCP propõe uma linguagem comum entre cliente e servidor: ferramentas, recursos, prompts, autorizações, transporte, descoberta. Não resolve magicamente a governança e a segurança, mas fornece uma gramática.

72E a gramática é importante. Quando um agente pode se conectar a muitas ferramentas, a questão não é apenas “ele consegue fazer isso?”. O problema é “ele entende o que pode fazer, com quais limites, em nome de quem e deixando quais rastros?”.

74Para mim, o MCP não é exagero porque "faz chamadas de ferramentas". Nós já fizemos isso. É um exagero porque muda o centro de gravidade da integração única para o catálogo operacional de ferramentas.

76Em uma boa arquitetura agêntica, o MCP se torna uma espécie de patch panel:

78- GitHub para código e problemas;

79- Slack para contexto conversacional;

80- Linear ou Jira para trabalhos planejados;

81- banco de dados somente leitura para análises;

82- navegador ou raspador controlado para sites externos;

83- armazenamento de documentos;

84- ambientes de execução isolados;

85- sistemas internos expostos com permissões estritas.

87A parte complicada é que um catálogo de ferramentas sem políticas é apenas uma forma mais elegante de criar o caos.

89## A quarta peça: identidade e permissões

91Esta é a área onde muitas demonstrações fecham os olhos.

93Um agente atua em nome de alguém. Portanto, deve ficar claro quem é o sujeito da ação.

95Está usando permissões de usuário? De uma conta de serviço? De um espaço de trabalho? Você tem acesso temporário ou permanente? Você consegue ler tudo ou apenas alguns recursos? Você pode escrever? Você pode cancelar? Ele pode enviar mensagens para pessoas reais?

97Se você não responder bem a essas perguntas, mais cedo ou mais tarde construirá um assistente com as chaves de casa e sem memória de quem as deu a ele.

99A regra que gosto é esta: o agente deve ser capaz de fazer menos que o humano, e não mais que o humano. E quando ele tem que fazer algo mais arriscado, ele tem que parar e perguntar.

100

101Isso significa OAuth, escopo de token, gerenciamento de segredos, log de auditoria, política de ferramentas, lista de permissões, etapa de aprovação. Coisas não muito românticas. Coisas necessárias.

102

103## A quinta peça: memória e contexto, mas sem acumular lixo

104

105Os agentes precisam de memória, mas a memória é perigosa quando se transforma num sótão.

106

107Existem pelo menos três tipos de memória:

108

109- memória de execução: o que aconteceu nesta execução;

110- memória de projeto: convenções, decisões, restrições;

111- memória pessoal ou de equipe: preferências, tom, rituais, processos.

112

113Colocar tudo no prompt é o atalho. Funciona até não funcionar mais. A memória útil deve ser cuidada: indexada, atualizada, expirada, verificada, tornada citável.

114

115Um agente que se lembra mal é pior do que um agente que não se lembra. Porque ele fala com confiança.

116

117Portanto, a infra-estrutura deve incluir recuperação, arquivos de instruções, base de conhecimento, incorporação quando necessário, mas também limpeza. Precisamos de uma cultura da memória: o que entra, quem aprova, quando decai, como faço para corrigir.

118

119## A sexta peça: observabilidade, avaliação e repetição

120

121Se um agente cometer um erro, o log “chamado de modelo” não será suficiente.

122

123Você quer ver a rota. Que contexto ele recebeu? Quais ferramentas estavam disponíveis? Qual ferramenta você escolheu? Com que argumentos? Que resposta você obteve? Quanto custou? Onde ele ficou preso? O humano aprovou alguma coisa? O erro é um erro de modelo, ferramenta, prompt, dados ou permissão?

124

125Aqui os agentes são mais parecidos com sistemas distribuídos do que chatbots.

126

127Você precisa de rastreamentos legíveis, não apenas de registros de texto. Você precisa ser capaz de reproduzir uma corrida. É necessário comparar duas versões do mesmo agente em tarefas conhecidas. Precisamos medir as regressões: não apenas "responde melhor", mas também "fecha o ticket certo sem tocar em arquivos não solicitados".

128

129As avaliações de agente são mais difíceis do que as avaliações de texto porque incluem ações. Não é suficiente comparar uma string esperada. É preciso observar as sequências, os efeitos colaterais, a qualidade do artefato, o tempo, o custo, o número de intervenções humanas.

130

131O engraçado é que sempre voltamos lá: engenharia de software. Testes, ambientes, rastreamentos, reversões. Só que o código agora também decide o que fazer a seguir.

132

133## A sétima peça: interfaces humanas

134

135O agente não precisa apenas viver em um chat.

136

137Alguns agentes precisam de um conselho. Outros uma página com status e log. Outros de um botão "aprovar". Mais comentários embutidos. Ainda outros de uma CLI.

138

139A IU muda o comportamento. Se a única maneira de controlar um agente for escrever uma mensagem longa, o usuário dará instruções vagas ao agente. Se, no entanto, ele vir o plano, as diferenças, as fontes, os riscos e a próxima ação, ele poderá intervir com precisão.

140

141Uma infraestrutura de agente decente inclui superfícies de controle:

142

143- situação atual;

144- plano editável;

145- artefatos produzidos;

146- diferença;

147- solicitações de aprovação;

148- cronologia;

149- botão parar;

150- botão de tentar novamente;

151- permissões visíveis.

152

153Parece trivial, mas não é. A diferença entre “IA assustadora” e “assistente confiável” geralmente é apenas que o último mostra onde está as mãos.

154

155## A pilha mental

156

157Se eu comprasse hoje, o stack mínimo do agente seria este:

158

1591. Modelo: raciocínio, geração, chamada de ferramenta, multimodal se necessário.

1602. Orquestração: loop, etapa, planejador, política, humano no circuito.

1613. Tempo de execução durável: fluxo de trabalho, fila, nova tentativa, pausa, retomada.

1624. Sandbox: execução de código, sistema de arquivos isolado, limitações, artefatos.

1635. Camada de ferramentas: MCP, API interna, navegador, banco de dados, repositório.

1646. Camada de identidade: OAuth, escopo, segredo, auditoria, política.

1657. Camada de memória: contexto do projeto, recuperação, instruções, expiração.

1668. Observabilidade: métricas de rastreamento, repetição, avaliação, custo e qualidade.

1679. Superfície do produto: converse quando for suficiente, painel quando necessário, revise quando for importante.

168

169A estrutura de agência cobre principalmente os pontos 2 e uma parte do ponto 1. O resto é o verdadeiro trabalho.

170

171## O que eu faria na prática

172

173Se uma equipe me dissesse “queremos agentes em produção”, eu não começaria com dez agentes.

174

175Eu começaria com um fluxo de trabalho pequeno, repetitivo e observável. Por exemplo: abrir PRs de manutenção, atualizar a documentação de problemas fechados, preparar uma revisão semanal, fazer triagem de bugs duplicados, gerar testes para arquivos afetados.

176

177Então eu estabeleceria limites muito claros:

178

179- não é permitido escrever sem ramificações ou sandbox;

180- sem segredos no prompt;

181- ferramentas na lista de permissões;

182- aprovação humana para ações externas;

183- registro e rastreamento obrigatórios;

184- orçamento por execução;

185- saída sempre inspecionável.

186

187Só então eu expandiria.

188

189Os agentes não falham só porque os modelos erram. Eles falham porque os colocamos em ambientes vagos, com permissões confusas e expectativas teatrais.

190

191## Minha leitura

192

193A infraestrutura agente é entediante da melhor maneira.

194

195Não é a parte que te faz bater palmas na demo. É a parte que permite que você realmente use a demonstração na manhã de segunda-feira, com pessoas reais, dados reais e consequências reais.

196

197O futuro dos agentes não será decidido apenas por quem tiver o melhor modelo. Será decidido por quem construir o melhor lugar para fazê-lo trabalhar: isolado quando experimenta, conectado quando necessário, sempre observável, autorizado com critério e humilde o suficiente para parar quando não sabe.

198

199É aí que os agentes deixam de ser um brinquedo e passam a ser infraestrutura.

200

201## Fontes

202

203- [Vercel: Como construir agentes de IA com Vercel e o AI SDK](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)

204- [Documentos Vercel: Sandbox](https://vercel.com/docs/sandbox)

205- [Vercel Docs: Trabalhando com Sandbox](https://vercel.com/docs/sandbox/working-with-sandbox)

206- [Documentos Vercel: MCP](https://vercel.com/docs/mcp)

207- [Protocolo de Contexto do Modelo: Especificação](https://modelcontextprotocol.io/specification)

208- [OpenAI: Novas ferramentas para agentes de construção](https://openai.com/index/new-tools-for-building-agents/)

209- [Blog da Cloudflare: Agentes na Cloudflare](https://blog.cloudflare.com/agents-on-cloudflare/)

210