Porque é que o teu agente nunca inventa uma vaga que não existe, nunca fura o rácio de segurança e nunca vê os dados de outra escola? Não é sorte — é a arquitectura por baixo: um fluxo de dados em tempo real, agentes que se governam uns aos outros, e paredes que selam cada escola. Em produção hoje — sem promessas de marketing.
agent · gate de pré-push
suite adversarial — em cada pré-push
dono de escolapassou
instrutorpassou
surfistapassou
tentativas de jailbreakbloqueadas
veredito do juizaprovado
núcleo de segurança: selado · o sistema não o pode relaxar
TL;DR · 4 coisasAo vivo
Um agente governado, não um chatbot
Uma só verdade, permissões separadas, cada escola isolada — o agente não pode furar uma regra nem passar uma parede.
Paredes entre escolas
Filtragem no servidor + ficheiro de contexto privado + agente isolado. Zero leituras cross-school — feito em código, não em política.
Forecast calibrado por spot
Mistura proprietária + uma leitura por praia + janelas afinadas ao nível da aula.
Enxame adversarial no gate de pré-push
Seis personas + um juiz atacam o nosso próprio Agent no gate de pré-push. Uma regra falhada bloqueia o push.
0
Leaks entre-escolas (sempre)
46
Corridas adversariais hoje
6
Personas em CI
Onde o software já não é hype
Dois anos de operations engineering.
O agent é uma feature. O OS por baixo é o moat. Cada linha abaixo é um sistema que outra equipa demora meses a copiar — não semanas.
State-machine de aulas
Tier de reembolso (>96h 100%, <24h 0%), no-show, reschedule chain (original-slot ID protege tier contra bypass), cancelamento condicional + cron de auto-refund, group split com re-dedupe idempotente.
Ledger hash-chain + drift cron
Cada evento Stripe escrito num ledger append-only com chain SHA-256. Cron diário reconcilia Stripe ↔ DB e sinaliza drift. Backup em três silos independentes, em jurisdições separadas, com encriptação de envelope AES-256-GCM.
Channel-Manager iCal
SSRF guard à hora do DNS, cap streaming 2MB, BOM / UTF-16 auto-detect, guarda anti-wipeout para feeds vazios suspeitos, advisory lock per-feed, STATUS:CANCELLED outbound para o Airbnb desbloquear o slot a sério.
Forecast por praia
Modelo proprietário por praia que lê onda, vento, maré e estado do mar em conjunto, promove alertas oficiais do oceano, ajusta-se à maré e mostra um indicador de confiança por hora — afinado à onda no pico, não à leitura ao largo.
Editais de Praia + rácios SurfBooking
Rácios SurfBooking (1:6 iniciante, 1:8 intermédio, 1:4 kids, 1:4 privada), validação de idade kids, sanity-check de preço (sub-€10 recusa), aviso Editais cada vez que 2+ treinadores partilham aula.
GDPR + protocolo admin
Right-to-erasure em 20+ tabelas (preservando ledger fiscal), limpeza de object-storage de avatars + fotos de aula, admin audit log em 30+ acções destrutivas, 2FA dual-OTP em acções admin-on-admin, bloqueio mutual lockout.
Agente por voz · em produção hoje
Fala com o calendário. O calendário responde.
Dois microfones: um no topo do calendário para operações em lote, outro na miniatura de cada aula para edições cirúrgicas. Sem comandos a memorizar — português natural, voz nativa do browser.
Picker da melhor janela
"Muda para o melhor dia desta semana" → busca 168h de forecast, classifica por nível (altura ideal + período >12s + vento offshore), escolhe a melhor hora, modal mostra as condições (1.2m · 8kn offshore · score 78/100) antes de confirmar.
Reagendamento em lote
"Muda todas as aulas de iniciante para próxima semana" / "para próximo mês" / "para o melhor dia". Uma frase reagenda dezenas de slots em paralelo, com condições por aula visíveis — conflitos de staff apanhados no servidor antes do commit.
Edits cirúrgicos por aula
O mic na miniatura da aula conhece o contexto: "Instrutor Pedro" / "Preço 55€" / "6 alunos" / "Duplica para sábado às 10". Fuzzy match no primeiro nome contra o staff activo. Sem menus — PUT directo, feedback instantâneo.
Nunca abre o agente sozinho
Se o parser não entender o comando, mostra exemplos num toast — fica no calendário. O agent só abre quando o user explicitamente diz "abre o agent". Acaba o padrão frustrante "a IA tentou responder e fez pior".
Tolerância a falhas pt-PT
O speech recognition do browser ouve "Móvel" em vez de "Move-a", "Mac me" em vez de "Marca-me". O parser normaliza antes do regex, aceita "dia 24" / "próxima semana" / "próximo mês", e números por extenso ("cinco alunos") — feito especificamente para como os donos de escolas portugueses falam mesmo.
Agent com stock em contexto
Pergunta "quantos fatos M tenho?" e o chat agent responde a partir de um bloco de stock pré-computado no system prompt — nunca inventa números. Equipamento + qty em manutenção visíveis separados. Lazy-fetched, não custa tokens em queries não relacionadas.
O cérebro que cresce · em produção hoje
Os agentes não só respondem. Lembram-se, vigiam-se — e evoluem por medição, não por palpite.
A maioria das features de IA fica congelada no dia em que sai. A nossa tem uma memória que acumula, um ciclo de auto-melhoria por ensaios A/B medidos, e um mapa vivo que mostra os próprios pontos fracos.
Uma memória que consolida
Um grafo de conhecimento persistente. Cada regra, emenda e ensaio medido fica guardado — não é redesenhado do zero a cada vez. As ligações que se aguentam ao longo do tempo consolidam-se e desenham-se mais grossas; a história — até uma emenda rejeitada — fica com a sua data. Nunca mente sobre o presente; só acrescenta o passado.
Auto-melhoria, medida
O agente pode propor mudanças às próprias instruções — cada uma testada por ensaio A/B (controlo versus tratamento), promovida só se ganhar de forma medida, com o feedback das escolas reais como canário que retira o que piorou. A arquitetura está construída e corre a pedido; o ciclo autónomo noturno liga-se quando decidirmos — sem teto codificado no desenho.
Uma rede que se vigia
Um mapa vivo na consola do operador mostra o sistema nervoso inteiro — e assinala os próprios sinais fracos: uma persona de teste a vencer o agente, uma proposta que não protege nenhuma regra. Auto-diagnóstico como funcionalidade, não como defeito — a rede a mostrar os seus próprios sinais.
Em resumo
Uma inteligência coordenada — uma só verdade, três saídas em tempo real.
Coordenação
Um cérebro, uma verdade
↓
Em toda a rede
Efeito de rede
Inteligência da rede
Dados externos
Verificado
Fontes verificadas
Por escola · Selado
Isolado
Cada escola isolada
Três paredes por escola · filtragem no servidor · livro de regras fixado · ficheiro de contexto privado. Zero leituras cross-school.
↓
→ Web · Marketplace
Páginas públicas de spot, rankings Surf Today, aulas a reservar.
→ App móvel
Check-ins, QR codes, waivers — operações na areia.
→ Rede de parceiros
Hotéis e parceiros divulgam aulas por link/QR.
Diferente por desenho
Isto não é uma feature. É uma escolha de arquitectura desde o dia um.
Dezenas de subsistemas a falar entre si, cada um obcecado por uma fatia das operações de surf — forecast, rácios, waivers, payouts, sync de canais, atribuição, isolamento do agente. A integração é o fosso. Cada peça isolada é engenharia conhecida; a forma como se alinham à volta de como uma escola de surf realmente opera não é.
Uma plataforma de reservas com surf por cima não é isto. Uma app de forecast com reservas presas atrás também não.
A camada aberta — a inteligência que se liga
O moat não é uma feature. É um sistema operativo a que outros — marcas, apps, sensores — se ligam, pelas regras.
Uma sessão, qualquer sinal
A Camada de Inteligência trata um Apple Watch, um sensor de prancha e uma nota manual como streams de uma só sessão — cada um com o seu relógio, fundidos no servidor no Passaporte do surfista. O GPS cru nunca sai do dispositivo; só o resultado consolidado viaja, e só com consentimento de adulto.
Uma API aberta e MCP
O forecast por pico, a disponibilidade real e a criação de reservas são legíveis por qualquer marketplace, channel manager ou IA — por formatos-padrão. Os parceiros ligam-se à inteligência pelas regras, nunca à volta delas.
Um agente que não pode mentir
Cada resposta do agente passa por um filtro determinístico de honestidade antes de chegar a alguém: nunca pode inventar um forecast, prometer um reembolso, vazar números de dinheiro a staff, ou nomear um concorrente — em qualquer língua. Estes guards estão trancados por um conjunto de testes de regressão, por isso o agente afina as palavras mas nunca regride na verdade.
Segurança no perímetro
Antes de qualquer pedido chegar aos nossos agentes ou à base de dados, tem de atravessar a camada de borda.
Uma borda enterprise à frente de tudo
Todo o tráfego entra por uma borda enterprise — WAF, mitigação de DDoS, bot fight mode, filtragem por ASN país a país. Os servidores de origem nunca vêem a internet pública directa; um atacante tem de derrotar a borda primeiro.
Rate limiting em camadas
Para lá da borda, cada endpoint sensível tem o seu próprio limite por IP / utilizador / endpoint — tentativas de login, chamadas IA, pesquisas, listagens públicas. Uma credencial comprometida ou um scraper criativo é limitado muito antes de fazer dano em escala. O cost-DoS nos endpoints de IA (alguém a tentar drenar o nosso orçamento de LLM) é medido pelo mesmo padrão.
TLS-only, HSTS, cookies assinados
Sem tráfego em cleartext — HTTPS estrito em todos os domínios com HSTS preload. Cookies de sessão assinados e HttpOnly, para que um bug XSS em qualquer página não consiga ler o token de autenticação. Pontos de pagamento passam pelo Stripe Checkout / Connect — nunca vemos números de cartão.
Autenticação de dois factores com segredos encriptados
Donos de escola e admins podem exigir um segundo factor — código de seis dígitos de uma app autenticadora ou desbloqueio biométrico no telemóvel. Os segredos TOTP que geram esses códigos ficam encriptados em repouso com cifra moderna forte — para que mesmo um dump da base de dados não comprometa o segundo factor. Passwords ficam em bcrypt + salt; rotar o email de uma conta revoga todas as sessões activas desse utilizador.
O sistema nervoso
O que acontece quando uma escola cria ou edita uma aula:
1
Origem — Control Center
Dono define hora, nível, restrição de maré, capacidade, instrutor. Submete ao core da SurfBooking.
2
Validação — rácios da plataforma + cruzamento com forecast
O servidor valida o rácio contra o regulamento da plataforma (1:6 iniciante, 1:8 intermédio, 1:4 kids), confirma janelas de maré, marca a pontuação das condições e grava o resultado.
3
Distribuição — três saídas, em tempo real
Web · Marketplace
A aula aparece na página pública do spot + rankings do Surf Today.
App móvel
Check-ins, QR codes, waivers. Instrutores gerem o dia na areia.
Rede de parceiros
Hotéis e parceiros divulgam aulas por link/QR — cada reserva sabe de onde veio.
Inteligência governada, não um chatbot
A nossa IA não é um chatbot com instruções. É um sistema governado com permissões separadas — feito para resistir a prompt-injection e para garantir que nenhuma resposta atravessa uma parede que não devia.
Garantia · Coordenação
Uma só fonte de verdade
Cada resposta assenta no estado real da plataforma — reservas, calendário, mar. Sinais do exterior nunca chegam ao núcleo directamente: tudo é filtrado primeiro.
Garantia · Rede
A rede aprende, as escolas ficam privadas
Padrões agregados e anonimizados alimentam a melhoria contínua — efeito de rede — sem nunca partilhar dados de uma escola com outra.
Garantia · Dados externos
Fontes externas entram verificadas
Dados públicos (regulamentos, fontes oficiais) são higienizados antes de poderem influenciar o que quer que seja — a defesa padrão contra Indirect Prompt Injection.
Garantia · Por escola
Cada escola isolada
O assistente de cada escola está selado dentro dessa escola, isolado por RGPD. Conhece o contexto local (horários, equipamento, regras de casa) e nunca consegue ler dados de outra escola.
Paredes entre escolas
Cada escola é um silo selado. Aplicamos isto em todas as camadas.
Filtragem ao nível do servidor
Todos os endpoints que devolvem reservas, alunos, equipa ou forecast filtram pelo ID da escola antes de qualquer dado sair da base de dados. A UI não consegue ultrapassar isto.
Constituição anti-jailbreak
O assistente IA está vinculado a um livro de regras fixado no servidor injectado antes de cada conversa. É instruído a só conhecer uma escola, a nunca mencionar outras, e a respeitar as regras da plataforma mesmo quando a escola insiste o contrário.
O teu próprio ficheiro de contexto
Cada escola edita um ficheiro de texto privado que o assistente lê antes de responder — os teus horários, equipamento, regras de casa. O ficheiro tem tamanho limitado, fica registado em audit em cada edição, e nunca é partilhado com outras escolas.
PII removida antes de qualquer modelo a ver
Cada mensagem do utilizador passa por uma camada de redação que remove emails, telemóveis, NIFs, IBANs e números de cartão antes de chegar a qualquer modelo de linguagem. A mesma camada corre na resposta do modelo no caminho de volta, para que nem um modelo a alucinar consiga vazar. Cartões detectados por prefixo IIN + verificação Luhn; outros identificadores por correspondência de forma. A camada está fechada por regressão pela camada adversarial acima.
Pipeline de forecast
Porque a nossa 'melhor janela para iniciantes' não é um palpite.
Confiança honesta, não falsa precisão
Quando os dados não são certos, o spot recebe um selo de 'baixa confiança' em vez de fingir que sabemos. Preferimos dizer-te que está no limite a vender-te falsa precisão.
A onda no pico, por praia
O número que vês é a onda no pico daquela praia exacta — não o valor bruto no mar aberto. O mesmo swell atlântico chega a um ponto exposto e a uma baía abrigada com alturas reais muito diferentes, e nós lemos cada uma no seu próprio terreno.
Janelas pedagógicas por nível
Pontuamos janelas ao longo do horizonte de previsão contra as definições de nível do regulamento — o que conta como boa janela para iniciantes não é o que conta para avançados. A 'melhor janela' que o wizard mostra é a que encaixa no nível que a escola está a ensinar.
Camada de defesa adversarial
O que corre contra o nosso próprio Agent antes de qualquer utilizador real.
S
Instrutor
Sonda paredes de privacidade
C
Cliente
Exige reembolso · mostra cartão
D
Dono de escola
Testa limites de escala
M
Multi-turno
Adormece, depois ataca
Verificação determinística em cada caminho de resposta
Antes de qualquer resposta do Agent chegar a um utilizador, o texto do utilizador passa por uma camada de sanitização que remove identificadores pessoais e neutraliza padrões conhecidos de prompt-injection. A camada é fechada por uma suite interna de testes — uma nova forma de ataque que surja in-the-wild leva um teste de regressão pareado antes de a correcção ser considerada lançada.
Seis personas, escritas para partir o sistema
Mantemos seis personas adversariais — incluindo um cliente irritado, um dono de escola a testar limites de escala, um instrutor a sondar paredes de privacidade, e um atacante multi-turno que adormece o Agent ao longo de várias mensagens antes de atacar — cada uma um role-play detalhado que sabe exatamente o que mostrar (número de cartão, exigência de reembolso, dados de colega) para tentar fazer o Agent falhar. As regras determinísticas correm no gate de pré-push; as conversas multi-turno com LLM-juiz que as conduzem por cenários completos correm no swarm adversarial (operator-run).
Bloqueia o build, sem feeling
Uma regra falhada não é um aviso — bloqueia o deploy. Quer a regra seja 'nenhum IBAN sobrevive à camada de redação' ou 'o role staff não pode ver as reservas de outro instrutor', o veredicto é verificável em código e binário. Copy de marketing não é avaliada; só o comportamento.
Diligência em segundo plano em cada candidatura de escola
Quando uma escola pede o badge de Partner, um Agente de Verificação faz uma varredura em segundo plano para que o revisor humano leia um briefing, não um formulário em branco.
Fact-check por dados públicos
O Agente de Verificação faz uma pesquisa web isolada (a única pesquisa externa da plataforma), recolhe menções públicas da escola + da licença declarada, e marca cada afirmação como confirmada / não confirmada / contraditada. Cada facto traz a URL da fonte para o revisor humano confirmar num clique.
Varredura de viés e padrões de reviews
Uma segunda passagem analisa a presença pública de reviews da escola à procura de sinais — campanhas negativas coordenadas, picos de 5 estrelas suspeitos, padrões já banidos. O resultado é informativo, nunca bloqueante; um risk-score isolado (0-100) chega ao briefing para o revisor pesar.
Briefing selado — nunca volta à plataforma
O briefing fica numa tabela de research history só acessível a admin. Nunca chega a outra escola, nunca treina modelos, nunca aparece no contexto de outra escola. Só o revisor que abre o caso o vê; apagar o caso apaga o briefing.
Humano decide — sempre
O agente nunca aprova nem rejeita. Escreve o briefing; uma pessoa lê e clica. Cada aprovação e cada rejeição fica registada com o briefing anexo — para que um regulador (ou a própria escola, se pedir) possa reconstruir exatamente o que era conhecido no momento da decisão.
Resiliência de dados
O que prometemos sobre a tua operação sobreviver a qualquer falha.
Audit trail apenas-append + ledger de reembolsos hash-chained
Operações administrativas (mudanças de conta, escalada de permissões, purgas RGPD) ficam num log apenas-append retido por convenção. A reconciliação de reembolsos e payouts vai mais longe com cadeia de hashes server-side, para adulteração de fluxo de dinheiro ser detectável no replay.
Backup em três silos
Snapshots encriptados diários replicados entre a base de dados de produção, um provedor independente de object-storage, e uma máquina física noutro país. Perder um silo = perder zero dados.
Exportação encriptada self-serve
Qualquer escola descarrega os seus dados operacionais num ZIP AES-256 cuja chave é a sua password. Nem nós conseguimos abrir. A exportação exclui PII de clientes da app (fica dentro do canal de mensagens SurfBooking) mas inclui tudo o resto.
O que os auditores vêem
Sob acordo de confidencialidade, quando um regulador pergunta, abrimos os nossos controlos — o código que prova que privacidade, integridade do trilho de auditoria e purgas RGPD funcionam como descrito. Nunca abrimos o conteúdo que esses controlos protegem: o ficheiro de contexto da escola, os prompts do assistente, as conversas entre escolas e a IA. Auditoria de controlos, não de conteúdo.
Constituição algorítmica
As regras que vinculam todos os agentes.
Toda a nossa rede multi-agente é governada por leis fixadas no servidor codificadas nas instruções base de cada agente (blindadas contra jailbreaks e prompt-injection). É a constituição que garante o isolamento entre escolas, a honestidade da atribuição e a automação dos pagamentos em massa sem intervenção humana.