O desenvolvimento de software clássico pensa primeiro em interfaces: lista de clientes, página de projeto, botão de upload, formulário de fatura, visualização de calendário. Para humanos, isso faz sentido. Para AI Agents, automações e sistemas externos, é o modelo de abstração errado.
Um agente não deveria precisar saber em qual página um botão está.
O que um agente realmente precisa
Um agente não navega por interfaces. Ele invoca capabilities. As perguntas relevantes são:
- Quais ações existem?
- Quais inputs uma ação espera, quais outputs ela entrega?
- Quais permissões são necessárias?
- Qual ação é arriscada ou irreversível?
- Quando é necessário consultar o usuário?
- O que é auditado?
O software UI-first não responde nenhuma dessas perguntas. O software MCP-first responde todas.
Klassisch
- Webapp
- Mobile App
- Admin UI
- API
- Automation
- AI-Integration
MCP-first
- Domain Model
- Action Layer
- Permission Layer
- MCP Tools
- MCP Resources
- MCP Workflows
- Audit Layer
- Webapp · Mobile · Admin · API · Automation
Tese 1: AI Agents não usam software como humanos
Humanos clicam, rolam, leem e interpretam. Agentes precisam de capabilities estruturadas que possam ser invocadas de forma direta e segura.
O segundo caminho é determinístico, tipado, com permissões verificadas e auditável. O primeiro produz automação de navegador frágil que quebra a cada atualização de UI.
-
schedule_follow_up(contactId, projectId, datetime, note) -
contacts.search(query, tenantId) -
reminders.create(contactId, datetime, note, assignedTo) -
calendar.find_free_slot(participantIds, duration, after)
Tese 2: A interface do usuário se torna um entre vários clientes
No passado, a UI era o principal acesso ao software. No futuro haverá vários acessos equivalentes, todos usando a mesma Capability Layer:
- Humano via Webapp
- Humano via Aplicativo Móvel
- AI Agent via MCP
- Automação via Worker
- Fornecedor externo via API
- Sistemas internos via Events
- CLI via Action Layer
Quem constrói a webapp primeiro e traz o restante depois, reconstrói a mesma Action Layer várias vezes, cada vez ligeiramente diferente, cada vez com sua própria lógica de permissões.
Tese 3: Software sem capacidade para agentes se torna difícil de integrar
Quando o software só funciona por interfaces, surgem inevitavelmente contornos frágeis:
- Automação de navegador e screen scraping
- Importações CSV e processos manuais de copiar e colar
- Workflows semiautomáticos
- Soluções específicas por cliente ou projeto de integração
Esses contornos quebram com mudanças na UI, não escalam e não podem ser auditados. O MCP-first elimina a razão para sua existência, tornando o sistema estruturalmente controlável desde o início.
Tese 4: A melhor interface para muitas tarefas não é uma interface
Muitas tarefas são dialógicas, contextuais e baseadas em workflow, elas não precisam mais de uma página:
“Crie um resumo de todos os negócios em aberto.” “Quais clientes devo contactar hoje?” “Verifique se faltam documentos para este funcionário.” “Crie um relatório sobre todos os projetos com risco.” “Compare os dois últimos ciclos de folha de pagamento.”
Para essas tarefas, um agente conversacional com acesso a uma Capability Layer é mais eficiente do que qualquer página com filtros e tabelas. O pré-requisito: as capabilities são bem modeladas, tipadas e com níveis de risco definidos.
Low Gerar resumo, Medium Criar documento, Critical Exportar folha de pagamento, essas diferenças o sistema deve conhecer.
Tese 5: MCP-first reduz o desenvolvimento duplicado
Quando uma funcionalidade é construída primeiro como Action, cada cliente pode usar a mesma Action, sem implementação duplicada:
create_project(name, templateId, ownerId, tenantId)Esta única Action pode ser usada por:
- Webapp
- Aplicativo Móvel
- Admin UI
- MCP Agent
- CLI
- Worker
- Processo de Importação
- Integração
- Suite de Testes
Isso não apenas reduz esforço, elimina inconsistências entre os clientes que de outra forma se acumulam ao longo do tempo.
Tese 6: MCP-first força uma arquitetura melhor
Quem constrói MCP-first precisa automaticamente modelar de forma mais limpa. Cada capability precisa:
- Domain Actions claras com intenção inequívoca do usuário
- Schemas de Input e Output tipados
- Permissões claras e tratamento de erros
- Side Effects definidos
- Audit Events e níveis de proteção
Isso obriga a atribuir claramente a responsabilidade de negócio antes de uma linha de código de UI ser escrita.
-
Input Schema, tipado, validado -
Output Schema, determinístico -
Permission Scopes, qual papel pode invocar -
Risk Level, low / medium / high / critical / forbidden -
Side Effects, impacto externo, sim ou não -
Audit Event, o que é registrado -
Confirmation Policy, autônomo ou aprovação humana
API-first era para desenvolvedores. MCP-first é para agentes.
Software construído primeiro como um sistema de capabilities totalmente descrito, com permissões verificadas e auditado é, ao mesmo tempo, melhor para humanos, melhor para agentes e melhor para tudo que está entre eles.