A Bancada do Agente — Handbook | Agentic Development

Visão Geral

O Agent Workbench é o ambiente de execução isolado, seguro e descartável onde os AI agents realizam suas tarefas. Cada execução de agent tem sua própria micro-virtual machine provisionada, pré-carregada com a base de código, ferramentas e contexto necessários. Quando a tarefa é concluída, o workbench é destruído. Esta página aborda a arquitetura do workbench, o Enterprise Tool Registry que equipa os agents com capacidades curadas, opções de deploy e o modelo de segurança que torna a execução autônoma segura em escala empresarial.

O Workbench

Um Agent Workbench é uma microVM efêmera provisionada sob demanda para uma única tarefa de agent. Ele contém tudo o que o agent precisa — uma cópia limpa da base de código relevante, dependências pré-instaladas, ferramentas configuradas e o context slice definido pela Live Spec da tarefa — e nada que não precise.

Ciclo de Vida

Provisionamento — Quando uma tarefa é despachada, a plataforma inicializa uma nova microVM em segundos. O workbench é pré-carregado com o snapshot da base de código, contexto relevante do Context Index e as ferramentas especificadas na configuração da tarefa.
Execução — O agent opera dentro do workbench: lendo arquivos, executando comandos, chamando APIs e produzindo artefatos. Todas as ações são sandboxed — o agent não pode acessar sistemas de produção, outros workbenches de agents ou infraestrutura compartilhada.
Extração de artefatos — Quando o agent sinaliza a conclusão (ou a execução atinge o tempo limite), a plataforma extrai os outputs: alterações de código, resultados de teste, logs e traces de avaliação.
Teardown — O workbench é destruído. Nenhum estado persiste. Nenhuma credencial permanece. A próxima tarefa começa do zero.

Este ciclo de vida elimina toda uma classe de riscos operacionais. Os agents não podem acumular estado obsoleto, vazar segredos entre tarefas ou criar efeitos colaterais persistentes que corrompam futuras execuções.

Garantias de Isolamento

Cada workbench oferece:

Isolamento de Filesystem — O agent vê apenas seu próprio workspace. Ele não pode ler ou gravar arquivos fora de seus diretórios designados.
Isolamento de Rede — O acesso de rede outbound é restrito a uma allowlist explícita: registros de pacotes aprovados, fontes de documentação e API endpoints. Todo o outro egress é bloqueado por padrão.
Isolamento de Processos — Os processos do agent são executados em seu próprio namespace. Eles não podem observar ou interagir com processos de outros workbenches ou do sistema host.
Limites de Recursos — CPU, memória e tempo de execução são limitados. Um agent descontrolado não pode consumir recursos ilimitados ou ser executado indefinidamente.

Segurança por Design

A infraestrutura efêmera torna a segurança uma propriedade estrutural do sistema, em vez de uma política que deve ser aplicada manualmente.

Contenção de Blast Radius

Se um agent fizer algo errado — interpretar mal uma spec, escrever um comando destrutivo ou ser vítima de um ataque de Prompt Injection — o dano é contido em um ambiente descartável. O pior cenário é uma execução de workbench desperdiçada, não um banco de dados de produção corrompido.

Gerenciamento de Segredos

Segredos e credenciais são injetados no workbench em tempo de execução através de uma integração de cofre seguro e nunca são persistidos em disco. Quando o workbench é destruído, os segredos desaparecem com ele. Os agents nunca mantêm credenciais, tokens ou session keys de longa duração. Isso significa que um agent comprometido não pode ser usado como uma ponte para movimento lateral através de sua infraestrutura.

Redação de Segredos

Todo o output do workbench — logs, output do terminal, código gerado — passa por uma camada de redação antes de sair do sandbox. Esta camada detecta e mascara automaticamente:

API keys e tokens
Database connection strings
Informações de identificação pessoal (PII)
Private keys e certificados

Mesmo que um agent inclua inadvertidamente um segredo em seu output, a camada de redação o detecta antes que ele chegue a um pull request, um agregador de logs ou um revisor humano.

Integração RBAC

Os controles de acesso do Workbench se integram à sua infraestrutura de identidade existente. Através do Active Directory, LDAP ou federação OIDC, as organizações podem aplicar:

Quais equipes podem provisionar workbenches
Quais conjuntos de ferramentas estão disponíveis para quais roles
Quais repositórios e context slices os agents podem acessar
Requisitos de aprovação para invocações de ferramentas de alto privilégio

Isso garante que o princípio do menor privilégio se estenda de seus engenheiros humanos para seus AI agents.

O Enterprise Tool Registry

Agents são tão capazes quanto as ferramentas que podem invocar. O Enterprise Tool Registry é um catálogo curado e governado de ferramentas que os agents podem usar durante a execução do workbench.

O Que Entra no Registry

O registry contém ferramentas de várias categorias:

API wrappers — Clientes pré-configurados para serviços internos, third-party APIs e recursos de provedores de nuvem. Cada wrapper lida com autenticação, rate limiting e tratamento de erros para que o agent não precise fazê-lo.
Integrações MCP — Conexões a servidores Model Context Protocol que expõem capacidades estruturadas: database queries, file system operations, search e muito mais. O MCP fornece uma interface padronizada que os models podem invocar de forma confiável.
Módulos Infrastructure-as-Code — Módulos Terraform, templates CloudFormation e manifests Kubernetes que os agents podem aplicar através de caminhos de execução controlados. Esses módulos são pré-aprovados e testados, garantindo que os agents provisionem a infraestrutura com segurança.
Development tools — Linters, formatters, test runners, build tools e utilities de static analysis. Estas são as mesmas ferramentas que seus engenheiros humanos usam, empacotadas para invocação de agent.
Observability tools — Log queriers, metric dashboards e trace explorers que os agents podem usar para diagnosticar problemas e validar seu próprio trabalho.

Definições de Função JSON

Cada ferramenta no registry é encapsulada em uma JSON Function Definition — um schema estruturado que informa ao LLM exatamente como invocar a ferramenta. Uma function definition inclui:

Name e description — O que a ferramenta faz, expresso em linguagem natural que ajuda o model a decidir quando usá-la.
Parameter schema — Um JSON Schema definindo os inputs que a ferramenta aceita, incluindo tipos, constraints, campos obrigatórios e valores padrão.
Return schema — O que a ferramenta retorna em caso de sucesso e falha.
Side effects declaration — Se a ferramenta é read-only ou executa mutations. Isso ajuda a camada de governança a determinar quais invocações exigem aprovação adicional.

Function definitions bem elaboradas são a diferença entre agents que usam ferramentas de forma confiável e agents que alucinam tool calls. A definição é o contrato entre o model e a ferramenta — ambiguidade na definição leva à ambiguidade no uso.

Governança de Tool Calling

Nem todas as ferramentas carregam o mesmo risco. O registry suporta governança em camadas:

Unrestricted tools — Operações read-only como leitura de arquivos, search queries e consulta de documentação. Os agents podem invocá-las livremente.
Monitored tools — Operações com side effects limitados, como gravação de arquivos ou execução de testes. Estas são logadas e auditáveis, mas não exigem pré-aprovação.
Gated tools — Operações de alto impacto, como deploy de infraestrutura, modificação de controles de acesso ou chamadas a payment APIs externas. Estas exigem aprovação explícita através de um checkpoint de Guardrails antes que a execução prossiga.

Este modelo em camadas evita a restrição excessiva de agents (o que mata a produtividade) enquanto mantém o controle sobre operações genuinamente arriscadas.

Arquitetura de Deploy

A plataforma Agent Workbench suporta múltiplos modelos de deploy para acomodar diferentes requisitos organizacionais para soberania de dados, conformidade e latência.

Deploy SaaS

A opção mais simples. A plataforma workbench funciona como um managed service na nuvem do provedor. As organizações conectam seus repositórios e configuram seus tool registries através de uma interface web.

Ideal para: Equipes que desejam começar rapidamente sem investimento em infraestrutura. Adequado quando código e dados podem sair da rede corporativa.

Trade-offs: Os dados transitam por infraestrutura externa. A customização é limitada ao que a plataforma expõe. A latência depende da disponibilidade da região do provedor.

Deploy VPC

A plataforma workbench é executada dentro da Virtual Private Cloud da própria organização. O provedor gerencia o software; a organização possui a rede e o compute.

Ideal para: Organizações com requisitos de conformidade moderados. O código permanece dentro do limite da rede corporativa. A equipe de segurança mantém o controle sobre as políticas de rede e os fluxos de dados.

Trade-offs: Requer expertise em infraestrutura de nuvem para configurar e manter o ambiente VPC. Overhead operacional maior do que SaaS.

Deploy On-Premises e Air-Gapped

Toda a plataforma é executada no próprio hardware da organização, sem dependências de rede externas. Toda a inference do model, execução de ferramentas e armazenamento de artefatos acontecem dentro do perímetro corporativo.

Ideal para: Defesa, serviços financeiros, saúde e qualquer organização onde os dados nunca devem sair das instalações. Suporta ambientes classificados ou altamente regulamentados.

Trade-offs: Maior carga operacional. Requer equipes de infraestrutura dedicadas para gerenciar compute, storage e atualizações da plataforma. A hospedagem do model deve ser tratada internamente, o que limita as opções de models disponíveis.

Escolhendo um Modelo de Deploy

Fator	SaaS	VPC	On-Premises
Time to value	Dias	Semanas	Meses
Data sovereignty	Controlado pelo provedor	Controlado pela organização	Totalmente interno
Compliance	Padrão	Moderado	Máximo
Operational burden	Mínimo	Moderado	Significativo
Customization	Limitado	Moderado	Total
Model availability	Catálogo completo	Catálogo completo	Somente auto-hospedado

A maioria das organizações começa com deploy SaaS ou VPC e migra para on-premises apenas quando os requisitos regulatórios ou de segurança exigem.

Unindo Tudo

O Agent Workbench é a camada de execução que torna todo o resto do Agentic Development Framework possível. Sem ambientes isolados e efêmeros, a execução autônoma de agents seria um risco de segurança inaceitável. Sem um tool registry governado, os agents não teriam as capacidades para fazer um trabalho útil. Sem opções de deploy flexíveis, as organizações não poderiam adotar workflows de agents dentro de suas restrições de conformidade existentes.

O workbench não opera isoladamente. Ele recebe suas instruções do Context Index e Live Specs (abordados na próxima página), e seu output é validado pelo Evaluation Harness antes que qualquer humano o veja. Juntos, esses três componentes — workbench, contexto e avaliação — formam a infraestrutura operacional do agentic development.