Para agentes

Agentes

Um agente deveria conseguir entregar a alguém um banco de dados funcionando sem que nenhuma pessoa abra um painel. Aqui está tudo o que publicamos para isso.

o prompt de bootstrap

Configure um banco de dados Postgres da CapyDB para este projeto. Baixe https://capydb.dev/agents.md e siga as instruções do seu ambiente. Você vai precisar de mim uma vez só: para aprovar o acesso em uma aba do navegador. O resto é com você.

Funciona com Claude Code, Cursor, Copilot e cia. Uma aprovação sua no navegador e pronto: conta, banco e variáveis de ambiente resolvidos.

01O que acontece depois

Cole. Aprove uma vez.

O prompt tem três linhas de propósito. As instruções de verdade ficam em capydb.dev/agents.md, versionadas com o produto: o que o agente segue está sempre atual, e um prompt copiado meses atrás não apodrece.

01O que acontece depois
awaiting signal

01

A premissa

Uma parcela crescente dos projetos é iniciada por um agente e apenas revisada por uma pessoa. Esse agente precisa de três coisas de um provedor de banco de dados: um jeito de descobrir o que o produto é, um jeito de agir sobre a conta e um jeito de devolver ao humano algo que funcione.

Publicamos os três. Nada disso é superfície de demonstração: o servidor MCP e a CLI chamam a mesma API que o painel, com as mesmas permissões e a mesma trilha de auditoria.

02

Descoberta

  • -/llms.txt - o índice que um assistente lê primeiro e que aponta para tudo o mais
  • -/agents.md - instruções executáveis para provisionar um banco em nome de uma pessoa
  • -/pricing.md, /about.md, /changelog.md - espelhos em markdown das páginas de marketing, gerados das mesmas fontes que o HTML
  • -/webmcp.md - a superfície de ferramentas de navegador que o painel publica
  • -O site de documentação publica índice próprio e um corpus completo para recuperação
  • -Um feed RSS do changelog, para que um agente atento a mudanças incompatíveis não precise ficar consultando uma página

03

Agir sobre uma conta

Duas superfícies, a mesma API. O servidor MCP é o certo quando o agente vive num editor ou cliente de chat; a CLI é a certa quando o agente tem um shell.

Ambos autenticam com uma chave de API restrita à organização, ou por um login de dispositivo que a pessoa aprova no navegador. Um agente nunca precisa - e nunca deve receber - uma senha.

# In a shell
capydb login
capydb create --name my-app
capydb env pull

# In an editor, over MCP
npx -y @capydb/mcp

04

Agentes no navegador

O painel publica uma superfície de ferramentas para agentes de navegador que a suportam, de modo que um agente conduzindo a página aja por ferramentas nomeadas em vez de adivinhar o DOM. Ferramentas destrutivas pedem confirmação pela mesma interface que uma pessoa veria.

A superfície publicada está documentada em /webmcp.md e é deliberadamente um subconjunto: restaurações que sobrescrevem produção não são expostas a um agente de forma alguma.

05

Salvaguardas

  • -Um UPDATE ou DELETE sem WHERE, ou um TRUNCATE, enviado pelo servidor MCP é recusado antes de rodar, e a recusa diz ao agente para delimitar as linhas ou ensaiar em um preview
  • -Restauração que sobrescreve produção não é exposta como ferramenta de agente em nenhuma superfície
  • -Chaves de API são restritas a uma organização e podem ser revogadas no painel assim que uma execução sai do rumo
  • -Bancos de preview têm tempo de vida, para que um experimento não vire silenciosamente uma fatura
  • -Toda ação de um agente aparece no log de auditoria do workspace, sob a chave que a executou

06

Por que aqui é fácil

Porque não há API de dados proprietária a aprender. O agente provisiona uma célula, obtém uma URL PostgreSQL padrão e depois usa o driver que o projeto já tem. Tudo o que um agente já sabe sobre Postgres se transfere sem mudança - e essa é a diferença entre uma tarefa que funciona na primeira tentativa e outra que exige três rodadas de consulta à documentação.