DEV Community: suissAI

A novel concept for Agentic Systems

suissAI — Wed, 15 Jul 2026 09:14:27 +0000

suissAI

Jul 15

H2A2H Manifesto

#ai #webdev #programming #h2a2h

6 min read

H2A2H Manifesto

suissAI — Wed, 15 Jul 2026 08:18:24 +0000

Human-to-Agent-to-Human

The next era of computing will not be defined solely by humans using software. Nor will it be defined solely by agents executing tasks. It will be defined by how humans, agents, organizations, systems, and protocols interact through responsibility, intent, delegation, verifiability, and human accountability.

This is what we call H2A2H.

H2A2H is more than an acronym. It describes a real-world interaction flow that begins with a person, passes through an agent representing that person's intent, traverses other agents, systems, or organizations, and ultimately returns to another person with a result, decision, service, purchase, support request, analysis, validation, or consequence.

The central idea is simple: agents do not exist in isolation. They exist within a chain of human responsibility.

A human initiates an intention. An agent interprets, organizes, validates, or executes that intention. Another agent may represent a company, a service, a domain, a department, or a computational authority. In the end, the outcome reaches another human: a customer, manager, support representative, professional, patient, citizen, teacher, student, lawyer, physician, public servant, or business owner.

The architecture ends with a human because every consequence ultimately belongs to a human.

For decades, computing has been designed around a direct relationship between people and interfaces. Humans opened applications, filled out forms, clicked buttons, navigated menus, and learned the language of machines. The interface was the center of the experience.

With agents, that logic changes.

Humans no longer need to operate every detail themselves. Instead, they declare intent. They specify what they want, under which constraints, in which context, with which permissions, and how far an agent may act on their behalf. The agent is no longer merely a tool; it becomes an operational representation of human intent.

But this creates a new challenge.

If an agent represents a person, who guarantees that it acts within the proper boundaries?

Who proves that the intent originated from an authorized human?

Who determines what may be automated, what requires confirmation, and what must never be delegated?

H2A2H exists to answer these questions.

Its purpose is not to replace humans. Its purpose is to establish an architecture where agents amplify human capability without sacrificing authorship, accountability, consent, or governance.

In H2A2H, an agent is not the owner of a decision. It is the carrier of delegated intent.

In H2A2H, companies no longer communicate only with users. They communicate with agents representing people, contexts, permissions, and operational boundaries.

In H2A2H, a system should never accept an action simply because an agent requested it. It must understand who authorized the request, for how long, under which scope, within which session, under which identity, and according to which policy.

Within H2A2H, identity is more than authentication. Identity includes verifiable behavior, contextual authorization, presence, cryptographic proof, and an auditable trail.

The human authenticates.

The human delegates.

The agent executes.

The system validates.

Another agent responds.

The human receives, approves, rejects, corrects, or assumes responsibility for the outcome.

This is the fundamental difference between traditional automation and responsible agentic architecture.

Traditional automation executes tasks.

H2A2H organizes relationships.

Relationships between humans and agents.

Between agents and companies.

Between companies and agents.

Between systems and domains.

Between intention and execution.

Between autonomy and boundaries.

Between convenience and responsibility.

The future will not consist merely of personal assistants calling APIs.

It will consist of complete agentic chains in which every action carries intent, identity, scope, permissions, proof, state, memory, traceability, and the possibility of human intervention.

This changes commerce.

Consumers will no longer need to browse dozens of websites. They will delegate their goals to an agent: find the best product within this budget, with fast delivery, trusted reputation, and acceptable warranty.

The consumer's agent will negotiate with business agents, compare offers, evaluate alternatives, and return recommendations. But when purchases involve significant financial value or risk, the final approval returns to the human.

This changes customer service.

People will no longer need to repeat their history during every interaction. Their agent will organize the relevant context, route the request, and communicate with the company's agent.

Human representatives will receive concise, structured context instead of fragmented conversations. Agents do not replace human care; they eliminate friction, repetition, and unnecessary loss of information.

This changes organizations.

Companies will no longer consist solely of internal software systems. They will operate domain-specific agents responsible for products, inventory, payments, logistics, support, legal operations, compliance, finance, data, and customer relationships.

These agents remain extensions of organizational responsibility. They operate within defined limits, governed by policies, validation rules, and audit logs.

This changes government.

Citizens will access public services through intent rather than bureaucracy. Their agent will organize documentation, verify eligibility, and communicate with institutional agents.

Yet public decisions, approvals, denials, benefits, and legal consequences must remain transparent, auditable, and reviewable by accountable human authorities.

This changes healthcare.

Patients may rely on personal agents to organize symptoms, medical history, laboratory results, medications, and questions before an appointment.

Agents improve preparation and continuity of care, but diagnosis, prescriptions, and clinical judgment cannot be blindly delegated to autonomous systems. H2A2H requires clear boundaries between assistance, triage, recommendation, and professional medical practice.

This changes education.

Students may have agents that monitor learning progress, identify difficulties, and organize study plans.

Teachers may rely on agents to prepare materials, assessments, and personalized feedback.

Yet education is fundamentally a human relationship involving interpretation, mentorship, and intellectual development. Agents should amplify educators and learners, never replace them.

This changes reputation.

In a world where agents summarize people, organizations, and histories, first impressions may increasingly be produced by machines.

H2A2H demands that digital reputation be treated as an accountable chain of interpretation, provenance, context, updates, and responsibility.

An agent's summary should never be assumed neutral simply because it is generated confidently.

This changes software itself.

Interfaces cease to be the only entry point.

Buttons cease to be the primary mechanism of interaction.

Forms cease to be the primary expression of user intent.

Software must expose capabilities that agents can understand through contracts, intents, permissions, policies, and confirmation mechanisms.

The software of the future will not be used only by humans.

It will also be used by agents acting on behalf of humans.

Therefore, every system must answer new questions.

Who is making this request?

Did it originate from an authenticated human?

Does the agent have permission?

Is that permission still valid?

What financial, legal, operational, or ethical boundaries apply?

Can this action be fully automated?

Does it require explicit human confirmation?

Should this action ever be delegated?

How can the action be proven?

How can it be audited, reversed, or challenged?

These are not implementation details.

They are the foundation of the next digital infrastructure.

H2A2H proposes seven fundamental principles.

First, explicit intent. Systems must understand what is being delegated, not merely the words being transmitted.

Second, verifiable identity. Agents may represent people only when authorization, presence, or delegated authority can be demonstrated.

Third, limited scope. No agent should receive unlimited authority by default. Every delegation must define limits of time, domain, value, operation, and context.

Fourth, risk-based governance. Low-risk actions may be automated. Sensitive actions require confirmation. Critical actions require supervision. Forbidden actions must be blocked.

Fifth, auditability. Every significant action must leave an accountable trail showing who delegated, which agent executed, which system accepted the request, which decision was made, and which human ultimately received the result.

Sixth, reversibility whenever possible. Agentic systems should support correction, dispute resolution, rollback, reprocessing, and supervised self-healing.

Seventh, human return. Every chain that affects people must preserve a clear path back to a human for approval, explanation, challenge, or accountability.

The greatest mistake will be treating agents as ordinary users.

Agents are not ordinary users.

They are operational representatives capable of acting faster, at greater scale, and with less friction. Consequently, they can also propagate mistakes faster, at greater scale, and with greater impact if not properly governed.

Another mistake will be treating agents as autonomous employees.

Agents possess neither legal personhood nor moral responsibility.

They operate under the responsibility of those who create, authorize, configure, or deploy them.

For this reason, H2A2H should be understood as an architecture of responsible delegation.

Whenever a human relies on an agent to purchase, negotiate, analyze, respond, teach, diagnose, operate, or make recommendations, the essential question is not merely:

"Can the agent do it?"

The real questions are:

"Should the agent do it?"

"Is it authorized to do it?"

"Can it prove that it acted correctly?"

"And does it know when control must return to a human?"

That is the true frontier.

The world does not simply need more intelligent agents.

It needs agents that are more accountable, more verifiable, more constrained, more auditable, and more deeply integrated into human responsibility.

H2A2H is a response to that future.

It names the architecture that emerges when humans stop interacting directly with every system and instead delegate intentions to agents that collaborate with other agents before producing outcomes for other humans.

It is the bridge between convenience and responsibility.

It prevents autonomy from becoming abandonment.

It enables agents to exist without removing humans from the origin, the boundaries, or the consequences of every meaningful action.

The future will not be merely Human-to-Computer.

Nor will it be merely Agent-to-Agent.

The future will be Human-to-Agent-to-Agent-to-Human.

Because every intention begins with someone.

Every execution requires boundaries.

Every consequence reaches someone.

And every truly responsible architecture must remember that, at both the beginning and the end, there is still a human.

FullAgenticStack: Semantic Behavior Type: LinearAutoDestroy

suissAI — Wed, 15 Jul 2026 07:56:23 +0000

Existe uma classe inteira de bugs e falhas de segurança que nasce de uma suposição errada: a de que o programador sempre vai lembrar de destruir, invalidar, limpar, revogar ou consumir corretamente um valor sensível depois do seu uso.

Essa suposição é fraca.

Na minha concepção, uma linguagem não deveria depender do programador escrever manualmente todo o código necessário para que um comportamento obrigatório de um tipo aconteça. Se um valor possui uma regra semântica obrigatória, essa regra não deveria viver espalhada em finally, defer, drop, close, destroy, ack, delete, expire, cleanup, revoke ou em qualquer outro ritual manual. Essa regra deveria pertencer ao próprio tipo.

É exatamente essa a motivação do LinearAutoDestroy.

LinearAutoDestroy é um Semantic Behavior Type: um tipo cujo objetivo não é apenas descrever a forma de um valor, mas obrigar a execução de um comportamento semântico associado a esse valor.

Indo na contramão do baixo nível tradicional

Linguagens de baixo nível normalmente partem da ideia de que todo comportamento relevante deve estar explicitamente escrito no código. O programador aloca, move, usa, libera, fecha, destrói, revoga, limpa memória, remove arquivo, apaga segredo, confirma mensagem, descarta payload e assim por diante.

Essa abordagem dá controle máximo, mas também transfere responsabilidade demais para o humano.

O problema não é a linguagem permitir controle. O problema é uma linguagem permitir que comportamentos obrigatórios sejam opcionais na prática.

Se um valor precisa ser destruído após uso, isso não deveria depender da disciplina do programador. Se uma mensagem só pode ser consumida uma vez, isso não deveria depender de um ack manual bem posicionado. Se uma chave efêmera não pode sobreviver depois de um handshake, isso não deveria ser uma convenção de equipe. Se um token de uso único já foi lido, ele deveria carregar no próprio tipo a impossibilidade de continuar existindo como valor válido.

A minha visão vai na direção oposta: transformar o comportamento obrigatório em tipo semântico.

O programador não escreve “destrua isso depois”. O programador escolhe um tipo que já significa “isso será destruído depois do uso”.

Quanto mais simples for declarar esse comportamento, menor a chance de alguém errar. A linguagem, o runtime ou a biblioteca devem executar as ações de baixo nível de forma transparente, porque esse comportamento não é uma escolha estética. É uma propriedade de segurança.

O que é um Semantic Behavior Type

Um Semantic Type tradicional descreve a semântica de uma propriedade.

Por exemplo:

PersonCPF
UserEmail
WhatsAppNumber
PaymentToken
SessionId

Esses tipos dizem: “este valor não é apenas uma string, ele representa algo com significado específico”.

Mas LinearAutoDestroy não é apenas isso.

Ele não é um Semantic Type de propriedade. Ele é um Semantic QuarkBehavior Type.

Isso significa que ele representa um comportamento semântico reutilizável, mínimo e obrigatório.

Um QuarkBehavior é a menor unidade semântica de comportamento. Ele deve ser pequeno, reaproveitável, determinístico e específico o suficiente para ser composto em comportamentos maiores.

No caso de LinearAutoDestroy, o comportamento não existe para transformar dados de negócio, validar CPF, normalizar telefone ou calcular preço. Ele existe para impor uma regra sobre a vida útil de um valor.

A semântica é:

um valor LinearAutoDestroy pode ser usado uma vez;
depois do uso, ele deve ser destruído, invalidado ou tornado inacessível.

Ou seja, o comportamento altera o tipo efetivo do valor ao longo do tempo.

Antes do uso, o valor está disponível.

Depois do uso, ele não deveria mais ser tratável como o mesmo valor. Ele deveria virar algo como:

Consumed
Destroyed
Revoked
Invalidated
Unusable

Essa transição não deveria ser informal. Ela deveria ser parte do modelo de tipos.

O tipo não descreve apenas o que o valor é. Ele descreve o que deve acontecer com ele.

A ideia central é simples:

Value<T> + LinearAutoDestroy => Value<T, usable_once>

Depois do consumo:

Value<T, usable_once> -> Destroyed<T>

Na prática, isso significa que o tipo carrega uma obrigação de runtime.

O valor não é apenas T.

Ele é T com uma política semântica de destruição.

Exemplo conceitual:

LinearAutoDestroy<DPoPNonce>
LinearAutoDestroy<OneTimeToken>
LinearAutoDestroy<QueueMessage>
LinearAutoDestroy<EphemeralPrivateKey>
LinearAutoDestroy<PasswordResetLink>
LinearAutoDestroy<HandshakeCertificate>
LinearAutoDestroy<FileHandle>
LinearAutoDestroy<TemporaryCredential>

Nesses casos, permitir que o valor continue disponível depois do uso cria superfície de ataque.

LinearAutoDestroy existe para fechar essa superfície.

Valores que deveriam existir como LinearAutoDestroy

Alguns valores não deveriam ser tratados como valores comuns. Eles deveriam nascer com prazo semântico de vida extremamente curto.

Exemplos:

one-time password
password reset token
magic link
DPoP nonce
challenge WebAuthn
mTLS ephemeral certificate
private key efêmera
session bootstrap token
queue message com consumo exclusivo
temporary file handle
signed upload URL
signed download URL
refresh token rotacionável
idempotency claim de uso único
ack secret
decryption key temporária

Todos esses valores possuem uma característica comum: continuar existindo depois do uso é perigoso.

Em sistemas tradicionais, o programador precisa lembrar de invalidar esses valores. Em sistemas orientados por Semantic Behavior Types, o programador escolhe um tipo que já contém essa regra.

A diferença é brutal.

No modelo tradicional:

usar valor
lembrar de destruir
esperar que ninguém esqueça
esperar que nenhum erro pule o cleanup
esperar que nenhum retry reutilize o valor
esperar que nenhum log grave o segredo
esperar que nenhuma fila entregue de novo indevidamente

No modelo com LinearAutoDestroy:

declarar valor como LinearAutoDestroy
usar valor
o próprio tipo obriga a destruição

Classes de brechas que esse tipo elimina ou reduz drasticamente

LinearAutoDestroy elimina ou reduz classes inteiras de falhas relacionadas à vida útil incorreta de valores sensíveis.

A primeira é o reuso indevido.

Tokens, nonces, mensagens e certificados temporários não deveriam ser reaproveitados. Se o tipo permite múltiplos usos, ele permite replay. Se o tipo é linear e autodestrutivo, o segundo uso deixa de ser uma operação válida.

A segunda é o vazamento por retenção acidental.

Muitas falhas não acontecem porque o valor foi roubado no momento do uso. Elas acontecem porque o valor continuou existindo em memória, cache, fila, log, storage temporário, arquivo intermediário ou estrutura auxiliar depois que já deveria ter desaparecido.

A terceira é o bug de cleanup incompleto.

Todo sistema que depende de cleanup manual eventualmente terá um caminho de execução onde o cleanup falha: exceção, panic, timeout, cancelamento de contexto, retry parcial, race condition, dead letter, processo morto ou deploy interrompido.

A quarta é o replay.

Se uma mensagem de fila, token ou credencial efêmera pode ser reapresentada, o sistema precisa verificar manualmente se ela já foi usada. Com LinearAutoDestroy, o próprio tipo expressa a regra: depois do primeiro uso, a identidade operacional daquele valor não existe mais como valor válido.

A quinta é a duplicidade de consumo em sistemas distribuídos.

Filas, workers, consumers e brokers frequentemente precisam lidar com mensagens entregues mais de uma vez, consumers concorrentes e confirmações parciais. Um valor semanticamente linear deve ser consumido por apenas um caminho válido. Os demais caminhos precisam receber destruição, invalidação ou rejeição semântica.

A sexta é a falsa confiança em convenção.

Comentários, documentação e boas práticas não impedem bug. Tipo impede bug. Runtime impede bug. Protocolo impede bug. Contrato formal impede bug.

LinearAutoDestroy transforma uma recomendação em uma obrigação executável.

Por que isso é um QuarkBehavior Type

O ponto mais importante é que LinearAutoDestroy não processa dados.

Ele não normaliza.
Ele não valida formato.
Ele não calcula.
Ele não enriquece payload.
Ele não converte string.
Ele não faz parsing.

Ele impõe comportamento.

Por isso ele é um Semantic QuarkBehavior Type.

Ele é um quark porque representa uma unidade mínima de comportamento semântico.

Ele é behavior porque executa uma ação obrigatória.

Ele é type porque modifica a forma como o valor pode ser usado pelo programa.

Ele é semantic porque o motivo da existência dele não é técnico-acidental, mas conceitual: aquele valor só faz sentido se for usado uma vez e destruído depois.

Essa é a diferença entre escrever uma função destroyAfterUse(value) e declarar:

value: LinearAutoDestroy<T>

No primeiro caso, você escreveu uma intenção.

No segundo, você alterou o contrato semântico do valor.

Modelo conceitual

Um LinearAutoDestroy<T> pode ser entendido como uma máquina de estados mínima:

Created -> Armed -> Consumed -> Destroyed

Ou, de forma mais rigorosa:

Created<T>
  -> Available<T>
  -> Used<T>
  -> Destroyed<T>

A operação principal é consume.

consume(LinearAutoDestroy<T>) -> T

Mas essa operação também dispara um efeito obrigatório:

after consume:
  destroy(original_reference)
  invalidate(identity)
  revoke(capability)
  remove_from_store_if_needed
  emit_receipt

O retorno pode entregar o valor para uso imediato, mas a referência original não pode continuar válida.

Em uma linguagem com suporte nativo a tipos lineares, isso poderia ser verificado em compile-time. Em linguagens sem esse suporte, a biblioteca pode aproximar o comportamento usando ownership, wrappers, guards, runtime checks, finalizers, weak references, locks, atomic state, capability tokens ou handles opacos.

O ideal é que cada linguagem implemente o máximo possível dessa garantia de acordo com suas capacidades.

Exemplo simplificado

Em pseudocódigo:

token = LinearAutoDestroy<Token>.create(raw_token)

token.consume(use_token)

token.consume(use_token_again) // erro semântico: token já destruído

O segundo uso não deveria ser tratado como erro comum de aplicação. Ele representa violação de contrato semântico.

A mensagem correta não é apenas:

invalid token

A mensagem correta é algo como:

LinearAutoDestroyViolation:
  value was already consumed and destroyed

Isso permite rastreabilidade, auditoria e prova de que o sistema bloqueou o segundo uso.

Implementação em filas: NATS como exemplo

Um dos primeiros lugares onde esse tipo faz sentido é em sistemas de filas.

Em NATS, uma mensagem pode representar uma intenção, uma entrega de evento, um comando, uma confirmação ou uma unidade de trabalho. Em arquiteturas distribuídas, é comum existir concorrência entre consumers, retries e redelivery.

Quando uma mensagem representa algo que só pode ser consumido uma vez, ela deveria ser tratada como LinearAutoDestroy.

Conceitualmente:

QueueMessage<T> + LinearAutoDestroy

Isso significa:

a mensagem pode ser entregue;
um consumer válido pode consumir;
após o consumo, a mensagem deve ser confirmada, invalidada ou destruída;
qualquer tentativa posterior deve falhar semanticamente.

O fluxo fica assim:

NATS message received
  -> wrap as LinearAutoDestroy<NatsMessage>
  -> consumer attempts consume
  -> payload is processed
  -> ack is emitted
  -> internal handle is destroyed
  -> receipt is generated

Em caso de erro:

NATS message received
  -> wrap as LinearAutoDestroy<NatsMessage>
  -> consumer attempts consume
  -> processing fails
  -> policy decides retry, nak, term or dead-letter
  -> handle is still invalidated according to the semantic rule

O ponto é que o consumer não deve ficar livre para manter aquele handle vivo indefinidamente.

Se a mensagem foi consumida, o wrapper semântico precisa impedir uso posterior.

LinearAutoDestroy no NATS com ACK semântico

Um exemplo prático é tratar o ack não como uma chamada solta, mas como parte do comportamento do tipo.

Modelo tradicional:

msg = sub.next()
process(msg.data)
msg.ack()

Esse modelo depende do programador lembrar de chamar ack.

Modelo semântico:

msg = LinearAutoDestroy<NatsMessage>.from(sub.next())

msg.consume(process)

O consume executa o processamento e amarra a política de destruição:

consume:
  lock message
  expose payload once
  run handler
  ack/nak/term according to policy
  clear payload reference
  invalidate message handle
  emit receipt

O programador não recebe uma mensagem crua. Ele recebe um valor semanticamente armado para autodestruição.

Esse detalhe muda a arquitetura.

A fila deixa de entregar apenas bytes. Ela passa a entregar uma capability de uso único.

Por que isso é replicável para outras filas

O conceito não depende do NATS.

NATS é apenas uma primeira implementação natural porque o modelo de mensagens, subjects, consumers, acknowledgements e redelivery combina muito bem com a ideia de consumo linear.

Mas a mesma semântica pode ser aplicada em:

Redis Streams
Kafka
RedPanda
BullMQ
RabbitMQ
SQS
Pulsar
filesystem queues
in-memory queues

Cada backend terá uma implementação diferente de destruição, confirmação ou invalidação, mas o contrato semântico permanece o mesmo.

A interface conceitual é:

LinearAutoDestroy<QueueMessage<T>>

A implementação específica decide como destruir:

NATS: ack, nak, term, drain, delete consumer state
Kafka: commit offset, transactional consume, tombstone auxiliar
Redis Streams: xack, xdel, claim control
BullMQ: complete job, remove job, fail with policy
RabbitMQ: ack, reject, nack, dead-letter

O tipo semântico não precisa saber todos os detalhes do backend. Ele precisa declarar a obrigação. O adapter executa a obrigação de acordo com o sistema de fila.

Arquivos também deveriam usar esse modelo

Filas são apenas o começo.

Arquivos temporários, handles de upload, buffers criptográficos, certificados efêmeros e chaves temporárias também deveriam ser tratados como LinearAutoDestroy.

Exemplo:

LinearAutoDestroy<TempFile>
LinearAutoDestroy<UploadHandle>
LinearAutoDestroy<PrivateKeyBuffer>
LinearAutoDestroy<DecryptionKey>
LinearAutoDestroy<SignedFileURL>

O uso de arquivos tem várias brechas clássicas:

arquivo temporário esquecido no disco
buffer sensível não zerado
descritor de arquivo mantido aberto
upload URL reutilizada
arquivo descriptografado mantido em cache
conteúdo sensível salvo em pasta temporária
processo morre antes de apagar o arquivo

Um proxy de arquivos baseado em LinearAutoDestroy pode resolver isso no nível correto: não como disciplina de código, mas como contrato semântico de uso.

O programador não deveria abrir um arquivo sensível cru.

Ele deveria receber:

LinearAutoDestroy<FileHandle>

E a única forma de acessar o conteúdo deveria passar pelo comportamento semântico do tipo.

O repositório

A proposta deste repositório é facilitar a adoção prática desse padrão.

A ideia é entregar implementações de LinearAutoDestroy em diversas linguagens, com exemplos diretos de uso, para que qualquer pessoa consiga copiar, colar e aplicar imediatamente nos pontos mais críticos do sistema.

O foco não é criar uma abstração bonita.

O foco é eliminar classes reais de falhas causadas por valores que continuam existindo depois que deveriam ter sido consumidos, destruídos ou invalidados.

O repositório contém implementações e exemplos para diferentes estilos de linguagem:

linguagens com ownership forte
linguagens com garbage collector
linguagens funcionais
linguagens orientadas a objeto
linguagens de scripting
runtimes assíncronos
sistemas de fila
wrappers para arquivos

Cada implementação respeita as limitações da linguagem alvo. Algumas conseguem garantir mais em compile-time. Outras dependem de runtime checks. Outras usam wrappers, estados atômicos e handles opacos.

Mas todas seguem a mesma regra semântica:

um valor LinearAutoDestroy não pode continuar existindo como valor válido após seu consumo.

O que vem depois

A primeira implementação prática usa NATS como exemplo de fila.

A próxima etapa é liberar implementações equivalentes para:

Redis
Kafka
RedPanda
BullMQ

Também vou implementar o mesmo conceito como proxy para manuseio de arquivos, permitindo que arquivos temporários, handles sensíveis e buffers críticos sejam tratados como valores de uso único com destruição obrigatória.

A longo prazo, LinearAutoDestroy não deveria ser apenas uma biblioteca.

Ele deveria ser um padrão de modelagem.

Sempre que um valor tiver uma vida útil semanticamente curta, ele não deveria depender da boa vontade do programador para morrer.

Ele deveria nascer com o seu fim definido no próprio tipo.

Conclusão

LinearAutoDestroy é uma tentativa de mover uma responsabilidade crítica do programador para o tipo.

Em vez de escrever código manual para lembrar de destruir valores sensíveis, declaramos que aquele valor pertence a uma classe semântica cujo comportamento obrigatório é a autodestruição linear.

Isso reduz a superfície de ataque, impede reuso indevido, dificulta replay, diminui vazamento por retenção acidental e remove uma fonte enorme de bugs causada por cleanup manual.

O ponto central é este:

comportamento obrigatório não deveria ser convenção;
comportamento obrigatório deveria ser tipo.

Se um valor só pode ser usado uma vez, o sistema de tipos, o runtime e o adapter de infraestrutura deveriam saber disso.

O programador deveria apenas declarar a intenção semântica correta.

O resto deveria acontecer de forma inevitável.

H2A2H: A Evolução Natural de Sistemas Orientados a Agentes

suissAI — Tue, 14 Jul 2026 22:40:22 +0000

Introdução

A arquitetura H2A2H (Human-to-Agent-to-Human) surgiu como uma consequência natural da evolução de sistemas distribuídos orientados a intenção, protocolos de agentes e interfaces humanas.

Em vez de tratar agentes como simples ferramentas chamadas por humanos, o H2A2H propõe uma mudança de paradigma: o agente passa a ser uma camada intermediária de coordenação, interpretação e execução entre pessoas, sistemas e outros agentes.

O objetivo não é substituir a interação humana, mas criar uma nova forma de colaboração onde humanos expressam intenções, agentes resolvem complexidades técnicas e humanos continuam sendo o ponto final de validação, decisão e confiança.

Atualmente o conceito está em desenvolvimento na versão v0.3. Após a finalização da v1.0, será elaborado um artigo científico formal descrevendo seus fundamentos, propriedades e aplicações.

1. A origem do H2A2H

O H2A2H não foi criado como uma arquitetura isolada. Ele emergiu naturalmente da necessidade de resolver problemas que aparecem quando sistemas modernos começam a possuir:

múltiplos agentes especializados;
diferentes protocolos de comunicação;
execução distribuída;
necessidade de auditoria;
segurança baseada em identidade;
delegação temporária de capacidades;
comunicação multimodal;
automação orientada por intenção.

Arquiteturas tradicionais seguem principalmente o modelo:

Human → Application → Backend → Database

O H2A2H evolui para:

Human
  ↓
Agent
  ↓
Agent Network
  ↓
Human

O agente deixa de ser apenas uma API inteligente e passa a ser um participante formal dentro de um ecossistema de capacidades.

2. Princípio fundamental

O H2A2H possui três elementos principais:

Human

O humano representa:

intenção;
contexto;
autoridade;
decisão final;
aprovação ética e operacional.

O humano não precisa conhecer todos os detalhes técnicos do sistema.

Ele declara o objetivo.

Exemplo:

"Quero comprar um equipamento compatível com meu ambiente e dentro do meu orçamento."

Agent

O agente funciona como uma camada intermediária capaz de:

interpretar intenção;
descobrir capacidades;
negociar execução;
validar regras;
chamar outros agentes;
produzir resultados verificáveis.

O agente não é apenas um chatbot.

Ele possui:

identidade;
capacidades;
permissões;
histórico de eventos;
políticas de execução.

Human

O segundo humano representa o retorno da interação.

O resultado volta para uma pessoa ou organização através de:

explicação;
evidência;
aprovação;
decisão;
colaboração.

O ciclo completo é:

Intenção humana
       ↓
Interpretação do agente
       ↓
Execução distribuída
       ↓
Resultado verificável
       ↓
Decisão humana

3. Componentes do H2A2H

3.1 Agent Identity Layer

Cada agente precisa possuir uma identidade única.

Inclui:

identificação universal do agente;
autenticação;
confiança;
histórico;
reputação.

A identidade permite que agentes sejam tratados como participantes verificáveis de uma rede.

3.2 Capability Layer

Agentes não são definidos apenas pelo código, mas pelas capacidades que oferecem.

Uma capacidade descreve:

o que o agente pode fazer;
quais entradas aceita;
quais resultados produz;
quais restrições possui.

Exemplo:

Capability:
  name: PaymentValidation
  input:
    transaction
  output:
    verified_payment

3.3 Capability Discovery

O sistema precisa descobrir agentes capazes de resolver determinada intenção.

Em vez de chamar uma API conhecida:

POST /payment/check

o modelo passa a ser:

Intent:
"Validar pagamento"

↓

Discovery:

Encontrar agentes
com Capability:
PaymentValidation

↓

Execução

3.4 Agent Communication Layer

O H2A2H depende de comunicação padronizada entre agentes.

Pode utilizar diferentes transportes:

QUIC;
NATS;
gRPC;
WebSocket;
outros protocolos especializados.

O transporte é separado da intenção.

Um agente não precisa saber onde o outro está localizado.

3.5 Intent Layer

A principal diferença do H2A2H é que a comunicação deixa de ser apenas baseada em chamadas técnicas.

Sistemas tradicionais:

Function Call
↓
Response

H2A2H:

Intent
↓
Reasoning
↓
Capability Selection
↓
Execution
↓
Verification

3.6 Trust and Security Layer

Como agentes podem agir em nome de humanos, segurança precisa ser baseada em delegação.

Inclui:

Zero Trust;
autenticação forte;
permissões temporárias;
tokens de curta duração;
auditoria.

O humano não entrega controle permanente.

Ele concede uma capacidade limitada:

Human Authorization

permite:

Agent X
executar
Capability Y

durante
tempo Z

3.7 Event and Memory Layer

O H2A2H evita depender de estado permanente em memória.

A execução pode ser registrada como eventos:

Event 1:
Human requested action

Event 2:
Agent discovered capability

Event 3:
Agent executed operation

Event 4:
Human approved result

Isso permite:

auditoria;
reconstrução;
transparência;
recuperação.

4. O funcionamento completo

Um fluxo simplificado:

┌──────────────┐
│    Human     │
└──────┬───────┘
       │ Intent
       ↓
┌──────────────┐
│ Agent Layer  │
└──────┬───────┘
       │ Capability Discovery
       ↓
┌──────────────┐
│ Agent Mesh   │
└──────┬───────┘
       │ Execution
       ↓
┌──────────────┐
│ Verification │
└──────┬───────┘
       │ Explanation
       ↓
┌──────────────┐
│    Human     │
└──────────────┘

O agente funciona como um coordenador confiável entre intenção e execução.

5. Relação com arquiteturas atuais

O H2A2H surge como uma evolução de conceitos existentes:

APIs → capacidades;
microsserviços → agentes especializados;
autenticação → identidade de agentes;
workflows → intenções;
automação → colaboração agente-humano;
sistemas distribuídos → redes de agentes.

Ele não substitui essas tecnologias.

Ele organiza essas tecnologias dentro de um modelo centrado em agentes.

6. Por que H2A2H é diferente?

Sistemas atuais geralmente assumem:

Usuário sabe qual sistema chamar.

O H2A2H assume:

Usuário sabe o objetivo.
O sistema descobre como realizar.

Essa mudança reduz a necessidade de interfaces complexas e permite que humanos interajam com capacidades digitais através de intenção.

7. Estado atual do projeto

O H2A2H está atualmente em desenvolvimento na versão:

H2A2H v0.3

Nesta fase o foco está na consolidação dos fundamentos:

modelo de agentes;
identidade;
capacidades;
comunicação;
segurança;
armazenamento de eventos;
protocolos de interação.

A versão v1.0 deverá consolidar uma implementação funcional completa.

Após a conclusão da v1.0 será desenvolvido um artigo científico apresentando:

fundamentos formais;
modelo arquitetural;
propriedades emergentes;
comparação com arquiteturas existentes;
casos de uso;
resultados experimentais.

Conclusão

O H2A2H representa uma transição de sistemas centrados em aplicações para sistemas centrados em agentes.

A ideia central é simples:

Humanos possuem intenção.
Agentes possuem capacidade de execução.
Sistemas possuem infraestrutura.

O H2A2H conecta esses três elementos criando uma camada onde humanos e agentes podem colaborar de forma segura, verificável e distribuída.

Ele não nasce como uma substituição das arquiteturas existentes, mas como uma evolução natural delas para um mundo onde agentes passam a ser participantes ativos da computação.

vídeo: Arquitetura H2A2H

FullAgenticStack: eBPF “de verdade” em VPS vs Bare Metal

suissAI — Wed, 08 Jul 2026 21:37:45 +0000

Esse artigo é uma explicação mais detalhada de um conceito que citei nesse artigo: https://dev.to/fullagenticstack/fullagenticstack-minha-arquitetura-basica-ainda-sem-ia-4gbi

Por que o UbiQEdgeWall precisa ser bare metal para XDP nativo, AF_XDP e rota direta da placa de rede para o socket do agente

Resumo: VPS pode rodar eBPF. VPS pode até rodar XDP genérico. Mas a versão realmente forte da arquitetura — o UbiQEdgeWall recebendo pacote cedo, filtrando antes do stack de rede, usando XDP nativo/offload e encaminhando por AF_XDP para um socket de agente — exige bare metal ou uma instância “metal” onde você tenha controle real do kernel, driver e interface de rede.

Este artigo separa o que dá para fazer em VPS, o que exige servidor físico dedicado, quais provedores fazem sentido para testar, e quais preços públicos eu encontrei para os provedores citados.

Os preços mudam por região, estoque, contrato, imposto, setup fee e câmbio. Use este documento como mapa técnico e comparativo inicial, não como orçamento final.

1. A confusão principal: eBPF não é a mesma coisa que XDP nativo

A pergunta correta não é apenas:

“A VPS deixa usar eBPF?”

A pergunta correta é:

“A VPS deixa usar o tipo de eBPF/XDP que minha arquitetura precisa?”

Existem níveis diferentes:

eBPF para observabilidade, tracing, socket, cgroup e TC

Geralmente pode funcionar em VPS Linux, desde que o kernel tenha suporte, as permissões existam e o provedor não bloqueie recursos necessários.
XDP genérico

Pode funcionar em praticamente qualquer interface, inclusive virtual, mas roda mais tarde no caminho do pacote. Ele é útil para MVP, mas não representa o melhor caso de performance.
XDP nativo / driver mode

O programa roda no ponto mais cedo possível do recebimento do pacote no driver da interface. Isso exige suporte do driver e acesso real à interface. É aqui que VPS normalmente falha.
XDP offload

O programa roda na própria placa de rede. Isso exige hardware específico e suporte do driver/NIC. Em VPS comum, praticamente não é o cenário esperado.
AF_XDP / XDP Socket

Permite que um programa XDP redirecione pacotes para sockets otimizados em userspace. Para a ideia do UbiQUIC/UbiQEdgeWall de levar o pacote do plano de rede para o socket do agente clone com o mínimo de overhead, AF_XDP é a peça correta — mas o ganho real depende de driver, NIC, filas, zero-copy e configuração fina.

A documentação de eBPF descreve que programas XDP podem ser anexados a dispositivos de rede e são chamados para pacotes de entrada, podendo dropar, redirecionar, manipular ou permitir o pacote. A grande vantagem de XDP vem do fato de ele atuar antes de partes caras do stack de rede, especialmente antes do caminho tradicional com alocação de sk_buff.¹

A documentação da Red Hat separa os modos de XDP em native/driver, generic e offloaded. Ela também deixa claro que o modo nativo depende do suporte do driver da interface, enquanto o modo genérico funciona de forma mais ampla, mas com overhead maior. O modo offloaded exige hardware específico.²

2. O que uma VPS normalmente permite

Uma VPS comum pode ser suficiente para:

observabilidade com eBPF;
tracing de syscalls, processos, TCP, disco e rede;
filtros em tc ingress/egress;
cgroup eBPF;
socket filters;
nftables, iptables, tc, clsact e políticas de rate-limit;
XDP genérico em alguns cenários;
protótipo de EdgeFilter.

Então a versão barata da arquitetura pode usar uma VPS como:

EdgeFilter VPS

Essa camada já ajuda muito. Ela reduz ruído, aplica filtros, coleta métricas e corta tráfego local antes da aplicação.

Mas ela não deve ser vendida conceitualmente como “eBPF direto da placa de rede”.

Numa VPS, a interface que você vê normalmente é virtualizada. Você enxerga algo como eth0, ens3, virtio_net, ena, gve ou outra interface exposta pela camada de virtualização do provedor. A placa física real, as filas da NIC, parte dos offloads e o hypervisor ficam fora do seu controle.

Por isso, a frase correta é:

VPS serve para EdgeFilter eBPF operacional.

Bare metal serve para UbiQEdgeWall real.

3. O que o UbiQEdgeWall real precisa

O UbiQEdgeWall real é o servidor de borda que faz sentido para a arquitetura final.

Ele precisa controlar:

kernel Linux;
versão do kernel;
driver da NIC;
suporte a XDP nativo;
suporte a AF_XDP;
múltiplas filas RX/TX;
RSS/RPS/XPS;
IRQ affinity;
ethtool;
offloads da NIC;
MTU;
pinning por core;
NUMA;
bpftool;
libxdp;
xdp-tools;
modo zero-copy quando disponível.

O caminho ideal é:

NIC física
  -> driver com XDP native
  -> programa XDP
  -> decisão: drop / pass / redirect
  -> AF_XDP socket
  -> UbiQEdgeWall userspace
  -> UbiQUIC / UbiQ
  -> socket do Agent clone

Esse desenho é o que permite falar, tecnicamente, em algo próximo de:

replicação e encaminhamento operacional em tempo real do plano de rede para o socket do agente clone.

Sem bare metal, você ainda pode simular o fluxo e validar o runtime. Mas a parte “direto da placa de rede” fica conceitualmente enfraquecida.

4. Teste prático: como saber se o servidor presta para UbiQEdgeWall

Depois de contratar o servidor, o teste mínimo é:

uname -r
sudo bpftool feature probe kernel
sudo bpftool feature probe dev eth0
ethtool -i eth0
ethtool -k eth0
ip -details link show eth0

O bpftool feature probe é a forma prática de inspecionar recursos eBPF disponíveis no kernel, tipos de programa, tipos de mapa e helpers.³

Teste XDP nativo:

sudo ip link set dev eth0 xdp obj xdp_pass.o sec xdp

Teste XDP genérico:

sudo ip link set dev eth0 xdpgeneric obj xdp_pass.o sec xdp

Teste XDP offload, se a NIC suportar:

sudo ip link set dev eth0 xdpoffload obj xdp_pass.o sec xdp

Se só xdpgeneric funcionar, o servidor pode servir para MVP, mas não para o UbiQEdgeWall final.

Se xdp nativo funcionar, aí começa a ficar interessante.

Se AF_XDP com zero-copy funcionar, aí começa a ficar realmente forte para o desenho do UbiQUIC/UbiQEdgeWall.

A documentação do kernel define AF_XDP como uma família de sockets otimizada para processamento de pacotes de alta performance.⁴

5. Dois nomes para não confundir a arquitetura

Eu usaria dois nomes diferentes:

EdgeFilter VPS

Versão barata.

Roda:

eBPF possível na VM;
TC ingress/egress;
nftables;
XDP genérico quando disponível;
observabilidade;
rate-limit;
filtros simples;
descarte antes da aplicação.

Serve para MVP, validação, custo baixo e proteção inicial.

UbiQEdgeWall Bare Metal

Versão correta.

Roda:

XDP nativo;
AF_XDP;
controle de driver/NIC;
controle de filas;
IRQ affinity;
RSS/RPS/XPS;
tuning de kernel;
roteamento UbiQUIC;
encaminhamento para socket do agente clone;
política Zero Trust de admissão antes da aplicação.

Serve para produção séria, baixa latência, alto volume, descarte agressivo e arquitetura realmente State-of-the-Art.

6. Provedores citados: preços e especificações públicas

A tabela abaixo resume os provedores citados e o que eu encontrei de preço/especificação em páginas públicas. Em todos os casos, é necessário validar o driver/NIC real depois da contratação, porque preço e CPU não garantem XDP nativo nem AF_XDP zero-copy.

Provedor	Tipo	Exemplo público encontrado	Preço público encontrado	Especificações encontradas	Link de preço/spec	Leitura arquitetural
Hetzner	Dedicated root server	EX44	a partir de €44/mês na página pública de Dedicated Root Server / EX-Line	Intel Core i5-13500, 64 GB DDR4, 2 × 512 GB NVMe, porta 1 Gbit/s, tráfego ilimitado	https://www.hetzner.com/dedicated-rootserver/ex44/	Excelente candidato barato para primeiro UbiQEdgeWall bare metal europeu. Precisa validar NIC/driver/XDP nativo no servidor entregue.
OVHcloud	Dedicated / Bare Metal	Advance-3 / Advance-4 / Scale	Advance-3 2026: a partir de US$236/mês; Scale-a2/linhas superiores: a partir de US$484/mês em exemplos públicos	Advance-3: AMD EPYC 4465P, 12c/24t, 64–256 GB, NVMe, private 25 Gbps, public 1–5 Gbps. Scale/linha superior: até 50 Gbps private e public até 25 Gbps em planos maiores	https://www.ovhcloud.com/en/bare-metal/prices/	Muito bom para edge com rede forte e mitigação de DDoS. Custo maior que Hetzner/Scaleway, mas melhor perfil de rede.
Vultr	Bare Metal	AMD EPYC 9255 / 9354P	Página pública mostra AMD EPYC 9255 a US$1.481/hora e AMD EPYC 9354P a US$2.158/hora; homepage também anuncia Bare Metal a partir de US$120/mês	EPYC moderno, SSD/NVMe, bare metal automatizado; detalhes variam por região/plano	https://www.vultr.com/products/bare-metal/	Bom para multi-região e provisionamento simples. Para UbiQEdgeWall, validar NIC e se XDP/AF_XDP funciona no hardware entregue.
Scaleway	Elastic Metal / Dedibox	EM-B220E-NVMe / EM-I120E-NVMe / Dedibox Start	EM-B220E-NVMe: €119.99/mês; EM-I120E-NVMe: €129.99/mês; Dedibox Start a partir de €4.74/mês com compromisso anual	EM-B220E: AMD EPYC 7232P, 8c/16t, 64 GB, 2 × 1.02 TB NVMe, 1 Gbps até 10 Gbps. EM-I120E: AMD EPYC 8024P, 8c/16t, 64 GB, 2 × 960 GB NVMe, 1 Gbps até 25 Gbps	https://www.scaleway.com/en/pricing/elastic-metal/ e https://www.scaleway.com/en/dedibox/	Um dos melhores candidatos custo/controle na Europa para começar. Linha Elastic Metal é mais coerente para edge do que Dedibox ultra-barato.
Leaseweb	Dedicated servers	HP DL120 G9 / Dell R730XD / High bandwidth	Página pública lista exemplos como €71.80/mês para HP DL120 G9 e promo de Dell R730XD €164.14/mês; há opções high-bandwidth > €1.149/mês	Exemplo: HP DL120 G9, Xeon E5-1620v3, 32 GB, 2 × 480 GB SSD, 30 TB traffic, entrega em 1 hora. Várias regiões: Holanda, EUA, Alemanha, Canadá, Reino Unido, Singapura, Hong Kong, Austrália, Japão	https://www.leaseweb.com/en/c/dedicated-server	Forte por presença global e variedade. Bom para edge geográfico. Precisa validar NIC/driver no modelo exato.
IBM Cloud	Bare Metal Servers	VPC / Classic bare metal	Página oficial descreve preço flexível hourly, monthly e reserved, mas o preço exato depende do configurador	Classic: mais de 11 milhões de combinações e 20 TB de bandwidth incluído; VPC: perfis preset e deployment em regiões multizona	https://www.ibm.com/products/bare-metal-servers/pricing	Bom para ambiente enterprise, compliance e contrato. Para arquitetura barata, provavelmente caro ou burocrático. Para UbiQEdgeWall, validar acesso real a NIC/driver.
AWS	EC2 Metal	m7i.metal-24xl / m7i.metal-48xl	m7i.metal-24xl aparece em agregador de preço como US$4.8384/hora; m7i.metal-48xl como US$9.6768/hora. AWS publica pricing por região no Price List API	AWS docs: m7i.metal-24xl e m7i.metal-48xl são tamanhos bare metal; m7i.metal-24xl tem perfil de 96 vCPUs, 384 GiB RAM e rede alta	Specs: https://aws.amazon.com/ec2/instance-types/m7i/ e https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html. Pricing/API: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/using-the-aws-price-list-bulk-api-fetching-price-list-files-manually.html. Agregador usado para número rápido: https://instances.vantage.sh/aws/ec2/m7i.metal-24xl	Excelente tecnicamente, caro para seu MVP. Pode ser útil se o UbiQEdgeWall precisar estar dentro da AWS. Validar ENA/XDP/AF_XDP no AMI/kernel.
Oracle Cloud Infrastructure	Bare Metal	BM.Standard.E6 / E6 Ax	Oracle Price List mostra Compute - Standard - E6 Ax - OCPU: US$0.0138/OCPU-hora; blog oficial de E6 Standard informa US$0.03/OCPU-hora + US$0.002/GB-hora de memória	Compute Shapes: BM.Standard.E6 / E6 Ax usam AMD EPYC 9J45, base 2.7 GHz, boost 4.1 GHz; shapes bare metal podem ter muitos OCPUs e RAM	Price list: https://www.oracle.com/cloud/price-list/. Shapes: https://docs.oracle.com/iaas/Content/Compute/References/computeshapes.htm. Blog E6: https://blogs.oracle.com/cloud-infrastructure/oci-launches-e6-standard-compute-powered-by-amd	Forte para bare metal grande, mas provavelmente overkill para edge barato. Bom se precisar de muita CPU/RAM e integração OCI.

7. Provedor por papel na sua arquitetura

Para sua arquitetura, eu não escolheria o provedor só por CPU. Eu escolheria por papel.

MVP barato

EdgeFilter VPS: VPS comum com eBPF/TC/nftables/XDP generic
Clones: VPS baratas em provedores diferentes
Crypto workers: VPS mínimas, sem persistência
UbiQ: VPS separada
Persistência: VPS ou servidor com disco melhor

Aqui, o objetivo é validar o runtime, o UbiQ, o QBEQStore, os clones, os workers de crypto e a governança de CPU.

Produção séria

UbiQEdgeWall: bare metal real
Clones: VPS ou bare metal leve, provedores diferentes
Crypto workers: VPS descartáveis ou bare metal barato
UbiQ: VPS forte ou bare metal pequeno
Persistência: servidor separado, idealmente com storage robusto

Aqui, o UbiQEdgeWall precisa ser contratado como servidor físico dedicado ou metal instance.

Produção agressiva

UbiQEdgeWall primário: bare metal com XDP native + AF_XDP
UbiQEdgeWall secundário: outro provedor/continente
Clone A: provedor 1
Clone B: provedor 2
UbiQ: provedor 3
Persistência: provedor 4
Crypto workers: provedores baratos e descartáveis

Aqui, a meta é reduzir blast radius: nenhum provedor, região, rede ou contrato pode derrubar a arquitetura inteira.

8. Por que eu não colocaria Google Cloud como hot path do UbiQEdgeWall

Google Cloud tem Bare Metal Solution, mas ela é apresentada como máquinas bare metal em extensões regionais co-localizadas próximas a regiões Google Cloud, não como o caminho mais simples para montar um edge packet-processing barato e portátil.⁵

Além disso, em arquitetura multi-região e multi-cloud, o custo de tráfego precisa ser tratado como parte do desenho. A página oficial de VPC Network Pricing do Google mostra cobrança de transferência entre regiões por GiB, com valores variando conforme origem e destino.⁶

Então, para essa arquitetura, eu usaria Google apenas com muito cuidado:

clone receptor;
nó passivo;
ambiente de teste;
ponto específico quando o tráfego não precisa sair muito;
integração com algum serviço Google que justifique o custo.

Eu não colocaria Google como centro de fan-out de replicação ou como UbiQEdgeWall principal sem simular custo de egress antes.

9. O ponto técnico que precisa ficar claro no artigo

A frase correta é:

VPS roda eBPF.

VPS pode rodar XDP genérico.

VPS raramente é o lugar certo para XDP nativo/offload real.

UbiQEdgeWall final precisa de bare metal.

E a frase operacional é:

Na arquitetura barata, use EdgeFilter VPS.

Na arquitetura State-of-the-Art, use UbiQEdgeWall Bare Metal.

Essa separação evita vender conceito errado.

10. Checklist antes de comprar o bare metal

Antes de contratar, eu perguntaria ao provedor ou validaria assim que a máquina subir:

Qual é a NIC real?
Qual é o driver Linux?
O driver suporta XDP native?
O driver suporta redirect?
O driver suporta AF_XDP?
Existe suporte a zero-copy?
Quantas filas RX/TX existem?
Consigo alterar IRQ affinity?
Consigo alterar RSS/RPS/XPS?
Consigo usar kernel customizado?
Consigo desabilitar offloads problemáticos?
Existe DDoS protection antes do meu servidor?
Existe limite de PPS?
O provedor limita pacotes UDP?
O provedor filtra tráfego antes de mim?
Existe console remoto/IPMI/KVM?
Existe reinstalação automática?
Existe rescue mode?
Existe custo de tráfego saindo?
Existe cobrança por tráfego interno?
Existe custo para failover IP?
Existe custo para private network?

O servidor barato que não responde bem a essas perguntas pode até ser ótimo para clone, UbiQ ou worker de crypto, mas não necessariamente para UbiQEdgeWall.

11. Comandos de validação inicial

# Kernel
uname -a
uname -r

# Interface e driver
ip -details link show
ethtool -i eth0
ethtool -k eth0
ethtool -l eth0
ethtool -S eth0 | head

# Recursos BPF do kernel e device
sudo bpftool feature probe kernel
sudo bpftool feature probe dev eth0

# Teste de attach XDP nativo
sudo ip link set dev eth0 xdp obj xdp_pass.o sec xdp

# Remover XDP
sudo ip link set dev eth0 xdp off

# Teste genérico
sudo ip link set dev eth0 xdpgeneric obj xdp_pass.o sec xdp

# Teste offload, se houver hardware
sudo ip link set dev eth0 xdpoffload obj xdp_pass.o sec xdp

Se o attach nativo falhar e só o genérico funcionar, não é o servidor ideal para UbiQEdgeWall final.

12. Recomendação prática

Para o seu caso, eu organizaria assim:

Fase 1: validar runtime sem gastar muito

Use VPS para EdgeFilter.

Use:

nftables;
tc;
cgroup eBPF;
socket filters;
tracing;
XDP generic se funcionar;
logs de queda;
métricas de PPS;
rate-limit.

Objetivo: validar arquitetura, não performance máxima.

Fase 2: primeiro UbiQEdgeWall real

Contrate um bare metal barato na Europa.

Candidatos iniciais:

Hetzner EX44;
Scaleway Elastic Metal EM-B220E ou EM-I120E;
Leaseweb entry/mid-range;
OVH Advance se quiser rede mais forte.

Objetivo: validar XDP native, AF_XDP, tuning de fila, IRQ affinity e encaminhamento para UbiQ/UbiQUIC.

Fase 3: UbiQEdgeWall multi-provedor

Use dois bare metals de provedores diferentes.

Exemplo:

UbiQEdgeWall A: Hetzner ou Scaleway
UbiQEdgeWall B: OVH ou Leaseweb
Clone A: DigitalOcean
Clone B: Oracle Free / Vultr / outro
UbiQ: provedor separado
Persistência: provedor separado
Crypto workers: VPSs baratas e descartáveis

Objetivo: sobreviver a falha de provedor, região, rota, contrato, DDoS, saturação e incidente operacional.

13. Conclusão

A intuição estava certa:

“Nenhuma VPS deixa usar eBPF de verdade?”

A resposta precisa ser mais precisa:

VPS deixa usar algum eBPF.
VPS pode deixar usar XDP genérico.
VPS geralmente não entrega controle físico real da placa de rede.
Para XDP nativo, AF_XDP forte, filas da NIC, tuning de IRQ e caminho de pacote realmente cedo, o caminho correto é bare metal.

Então a arquitetura deve assumir dois níveis:

EdgeFilter VPS = versão barata, operacional, boa para MVP.
UbiQEdgeWall Bare Metal = versão correta, final, State-of-the-Art.

Essa distinção evita erro conceitual e melhora o desenho do sistema.

O UbiQEdgeWall não é só “um servidor com firewall”.

Ele é a borda programável do runtime.

Ele existe para filtrar, classificar, descartar, redirecionar e preparar o pacote antes que ele vire custo de aplicação.

E para isso, quando o objetivo é o máximo controle possível do caminho de rede, o servidor certo é físico.

Fontes

Fontes de preço e especificação por provedor

Hetzner EX44: https://www.hetzner.com/dedicated-rootserver/ex44/
Hetzner Dedicated Root Server overview: https://www.hetzner.com/dedicated-rootserver
OVHcloud Bare Metal prices: https://www.ovhcloud.com/en/bare-metal/prices/
Vultr Bare Metal: https://www.vultr.com/products/bare-metal/
Vultr pricing overview: https://www.vultr.com/pricing/
Scaleway Elastic Metal pricing: https://www.scaleway.com/en/pricing/elastic-metal/
Scaleway Dedibox: https://www.scaleway.com/en/dedibox/
Leaseweb Dedicated Servers: https://www.leaseweb.com/en/c/dedicated-server
IBM Cloud Bare Metal pricing: https://www.ibm.com/products/bare-metal-servers/pricing
IBM Cloud Bare Metal overview: https://www.ibm.com/products/bare-metal-servers
AWS EC2 M7i instance types: https://aws.amazon.com/ec2/instance-types/m7i/
AWS EC2 instance specifications: https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html
AWS Price List Bulk API docs: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/using-the-aws-price-list-bulk-api-fetching-price-list-files-manually.html
Vantage AWS m7i.metal-24xl quick pricing mirror: https://instances.vantage.sh/aws/ec2/m7i.metal-24xl
Vantage AWS m7i.metal-48xl quick pricing mirror: https://instances.vantage.sh/aws/ec2/m7i.metal-48xl
Oracle Cloud price list: https://www.oracle.com/cloud/price-list/
Oracle Compute Shapes docs: https://docs.oracle.com/iaas/Content/Compute/References/computeshapes.htm
Oracle E6 Standard launch/pricing blog: https://blogs.oracle.com/cloud-infrastructure/oci-launches-e6-standard-compute-powered-by-amd

eBPF Docs — Program Type BPF_PROG_TYPE_XDP: https://docs.ebpf.io/linux/program-type/BPF_PROG_TYPE_XDP/ ↩
Red Hat Documentation — Getting started with XDP and eBPF: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/getting-started-with-xdp-and-ebpf ↩
ebpf-go Documentation — Feature Detection / bpftool feature probe: https://ebpf-go.dev/concepts/features/ ↩
Linux Kernel Documentation — AF_XDP: https://docs.kernel.org/networking/af_xdp.html ↩
Google Cloud Bare Metal Solution docs: https://docs.cloud.google.com/bare-metal/docs ↩
Google Cloud VPC network pricing: https://cloud.google.com/vpc/network-pricing ↩

FullAgenticStack: Minha Arquitetura Básica (ainda SEM IA)

suissAI — Wed, 08 Jul 2026 20:58:38 +0000

Como estou projetando uma arquitetura

Ela é Anti-frágil, Zero Trust e LinearAutoDestroy com Atores, Supervisores, UbiQ(meu sistema de mensageria Zero Trust em Zig com gRPC, Websocket, NATS e QUIC), eBPF, Secret Vault, workers criptográficos, QBEQStore(LocalEventStore para meus agents stateful) e runtime determinístico

Este não é um sistema de agentes de IA.

Esta arquitetura não depende de LLM, não possui agente de IA no runtime e não usa IA para operar produção.

Quando falo “Agent”, não estou falando de agente de IA.

Estou falando de agente operacional especializado: uma unidade de execução com responsabilidade explícita, comportamento previsível, supervisão, limites, métricas, isolamento, política de falha, persistência própria e contrato de execução.

A arquitetura é determinística, distribuída, supervisionada, Zero Trust e LinearAutoDestroy por natureza.

Ela é baseada em atores, supervisores, runtime em Zig, UbiQ, UbiQUIC, eBPF/XDP, Secret Vault, workers criptográficos descartáveis, CPUManagerAgent, CPUSchedulerAgent por core, máquinas de estado, QBEQStore, persistência policromática e políticas formais de resiliência.

A pergunta que guia essa arquitetura é:

como construir uma infraestrutura tão resiliente, escalável e anti-frágil que uma equipe pequena consiga operar algo que normalmente exigiria um time inteiro de DevOps, SRE, backend, segurança, DBA, data engineer e suporte?

Este texto é um pedido aberto de crítica técnica.

Quero conselhos, ataques conceituais, brechas, melhorias e contrapontos de quem entende de sistemas distribuídos, segurança, kernel, runtime, bancos, redes, criptografia, escalabilidade, SRE, BEAM, escalonamento, isolamento de falhas, Zero Trust, event sourcing, mmap, persistência local criptografada e arquitetura anti-frágil.

Não quero validação estética.

Quero saber onde isso quebra.

Quero saber onde existe acoplamento escondido.

Quero saber onde a latência explode.

Quero saber onde o custo explode.

Quero saber onde a migração pode corromper estado.

Quero saber onde o modelo de segredo pode falhar.

Quero saber onde o scheduler pode gerar starvation.

Quero saber onde o UbiQ pode virar ponto único de falha.

Quero saber onde a persistência policromática complica mais do que ajuda.

Quero saber onde o LinearAutoDestroy pode falhar por descuido de runtime, buffer, page cache, stack, heap transitório, log, trace ou cópia residual.

O objetivo não é criar uma arquitetura complexa.

O objetivo é criar uma arquitetura onde a complexidade inevitável esteja no runtime, e não na mão do operador.

1. A tese central

A ideia não é escalar aplicação.

A ideia é escalar comportamento.

Não tratar servidor como máquina fixa.

Tratar servidor como plano operacional.

Não tratar processo como algo preso a um host.

Tratar processo como unidade supervisionada, migrável, pausável e reexecutável.

Não tratar falha como exceção.

Tratar falha como sinal de roteamento, isolamento, degradação, reexecução ou aprendizado operacional.

Não tratar configuração manual como padrão.

Tratar comportamento obrigatório como responsabilidade do runtime.

Se um processo precisa ser supervisionado, migrável, mensurável, pausável, reiniciável e observável, isso não deve depender da disciplina manual do programador.

Deve ser uma propriedade nativa da arquitetura.

2. Zero Trust como princípio estrutural

Esta arquitetura é Zero Trust desde a primeira camada.

Zero Trust aqui não é apenas autenticação forte.

É uma regra estrutural:

nenhum servidor é confiável por padrão;

nenhum clone é confiável por padrão;

nenhum worker de crypto é confiável por padrão;

nenhum provedor é confiável por padrão;

nenhuma rede interna é confiável por padrão;

nenhum payload é confiável por padrão;

nenhuma intenção é confiável por padrão;

nenhum processo migrado é confiável por padrão;

nenhum shard de persistência é confiável por padrão;

nenhum evento é confiável sem integridade, causalidade e autorização.

Tudo precisa provar identidade, autorização, integridade, escopo e causalidade antes de executar, persistir, replicar ou encaminhar.

Na prática, cada comunicação entre clones, UbiQ, workers de crypto, persistência, runtime, agentes operacionais e borda deve ser tratada como comunicação hostil até prova contrária.

O eBPF/XDP filtra antes da aplicação.

O UbiQ não roteia apenas por disponibilidade, mas por autoridade.

O Secret Vault não entrega segredo bruto por conveniência.

Os workers de crypto recebem o mínimo necessário para executar uma etapa computacional e não armazenam nada.

Os clones não confiam um no outro apenas porque são clones.

A persistência não aceita escrita sem validação de intenção, identidade, escopo, integridade, causalidade e idempotência.

A replicação não é apenas cópia de dados. Ela precisa carregar causalidade, versão de schema, versão de política, assinatura, hash de integridade, trace id, idempotence key e autorização explícita.

Zero Trust, nesse desenho, significa que a arquitetura deve funcionar assumindo que qualquer parte pode falhar, atrasar, mentir, vazar, ser comprometida ou se comportar de forma inesperada.

Por isso, cada operação crítica precisa ter:

identidade verificável;
autorização explícita;
escopo mínimo;
payload validado;
assinatura ou prova de integridade;
chave efêmera quando possível;
logs sem segredo;
rastreabilidade;
idempotência;
expiração;
isolamento;
política de revogação;
limite de execução;
observabilidade.

Zero Trust não é uma camada depois da arquitetura.

Zero Trust é a forma como a arquitetura respira.

3. LinearAutoDestroy como natureza da arquitetura

Toda a arquitetura é LinearAutoDestroy por natureza.

Isso significa que nenhum valor sensível, payload, evento, resultado intermediário, segredo, fragmento criptográfico, intenção validada, estado de agente ou dado operacional deve permanecer em memória após o processamento.

A regra é:

processou, destruiu.

Usou, descartou.

Derivou, apagou.

Assinou, limpou.

Persistiu criptografado, removeu da memória transitória.

Isso não significa que a CPU não use registradores, stack, heap transitório, buffers, page cache ou estruturas temporárias durante a execução. Isso seria impossível.

Significa que nenhum Agent, subAgent, worker, processo ou componente do runtime mantém estado em RAM como fonte de verdade após concluir sua etapa.

A arquitetura é Stateful, mas com 0 RAM retida como estado durável.

O estado existe, mas não mora na memória viva do agente.

O estado fica criptografado no QBEQStore.

Os agentes são Stateful(0 RAM): eles têm continuidade de estado, mas essa continuidade vem do log/event store local criptografado, não de objetos vivos em memória.

Cada Agent carrega apenas o mínimo necessário para executar a etapa atual.

Terminou a etapa, o estado transitório é destruído.

A continuidade vem de eventos, snapshots, checkpoints, causalidade e consolidação criptografada.

4. QBEQStore, LocalEventStore e encrypted mmap

O LocalEventStore da arquitetura é o QBEQStore.

Ele é escrito em Zig e funciona como um event store local criptografado, desenhado para agentes Stateful(0 RAM).

O QBEQStore possui duas representações principais:

uma notação de grafo legível;
uma representação binária otimizada para leitura e consolidação de estado.

A notação de grafo legível serve para inspeção, auditoria, debug controlado, documentação operacional e compreensão humana do fluxo.

A representação binária serve para velocidade, consolidação, replay, snapshot, reconstrução de estado e leitura eficiente pelo runtime.

Para os eventos locais, o mecanismo correto é mmap, ou memory-mapped file.

No meu caso, não é mmap comum.

É um encrypted mmap event log.

O arquivo pode ser mapeado pelo sistema operacional para leitura eficiente, mas os dados persistidos continuam criptografados.

O runtime lê janelas específicas, descriptografa apenas o trecho necessário, reconstrói o estado mínimo, executa a etapa e destrói o material transitório.

O QBEQStore não é “RAM de estado”.

Ele é estado durável criptografado com leitura eficiente.

A RAM é apenas meio transitório de execução.

A fonte de verdade é o log criptografado.

A consolidação de estado acontece por replay, checkpoint, snapshot e leitura binária controlada.

A regra do QBEQStore é:

evento persistido: criptografado;

evento lido: descriptografia mínima;

evento processado: memória limpa;

estado reconstruído: apenas pelo tempo necessário;

estado consolidado: volta criptografado;

agente finalizado: 0 estado retido em RAM.

5. A arquitetura básica

Na arquitetura básica, eu parto de uma malha mínima com papéis bem separados:

2 servidores clone;
1 servidor de eBPF/XDP;
1 servidor UbiQ;
1 servidor de persistência;
2 servidores baratos para processamento criptográfico isolado.

Os dois servidores clone rodam a aplicação principal, os agentes operacionais, os supervisores, o runtime, o Secret Vault local e seus respectivos QBEQStores.

Eles não são backups mortos.

Eles são clones vivos.

A ideia é que ambos estejam sempre operacionais, aptos a receber carga, continuar processamento, assumir execução, receber replicação e manter o sistema vivo se um deles cair.

O servidor de eBPF/XDP fica na borda.

Ele não é backend.

Ele é fronteira de kernel.

O objetivo dele é cortar lixo antes que lixo vire custo de aplicação. Tráfego inválido, abuso, flood, padrões indesejados e pacotes que não deveriam subir para o runtime precisam ser filtrados o mais cedo possível.

O servidor UbiQ é o plano de roteamento operacional.

Ele não é apenas um message broker.

Ele decide para onde vai a intenção, qual agente operacional deve receber, qual shard deve ser usado, qual clone está saudável, qual processo pode migrar, qual fluxo precisa de fila, qual operação exige isolamento e qual persistência deve receber determinado tipo de verdade.

O servidor de persistência é separado do runtime.

Ele guarda estado durável e coordena múltiplos tipos de banco, porque dados diferentes têm físicas diferentes.

Relacional, documento, vetor, grafo, event store, timeseries, métricas, logs, cache, busca e analytics não deveriam ser tratados como se fossem a mesma coisa.

Além disso, existem dois servidores baratos dedicados ao processamento criptográfico.

Na versão básica, eu poderia usar uma VPS barata da DigitalOcean apenas para jogar processamento de crypto para lá.

Na arquitetura que pretendo usar de verdade, são duas VPSs mínimas:

uma Oracle Free;
uma DigitalOcean barata, sendo a VPS da DigitalOcean a principal.

Esses servidores de crypto não armazenam nada.

Eles recebem fragmentos de trabalho, executam cálculo criptográfico e devolvem resultado.

O estado sensível fica nos Secret Vaults dos clones e do UbiQ, nunca nos workers descartáveis.

6. Topologia mínima recomendada

A topologia mínima que eu usaria:

Clone principal: DigitalOcean VPS barata;
Clone secundário: Oracle Free ou outro provedor barato;
Crypto worker principal: DigitalOcean VPS mínima dedicada a crypto;
Crypto worker secundário: Oracle Free dedicada a crypto;
UbiQ: provedor separado dos clones;
eBPF/XDP Edge: provedor separado, preferencialmente com boa rede;
Persistência: provedor separado, com disco e backup melhores.

Na versão mais agressiva, cada papel crítico fica em provedor diferente.

Os clones podem ficar no mesmo continente para reduzir latência, mas devem estar em provedores diferentes.

A regra não é usar o provedor mais famoso.

A regra é reduzir dependência, reduzir custo de saída, reduzir blast radius e evitar que uma falha comercial, regional, política ou operacional derrube tudo.

7. Por que separar crypto em servidores próprios

Criptografia não tem a mesma física da lógica de negócio.

Ela pode ser intensiva em CPU.

Pode gerar pico.

Pode travar runtime se for mal escalonada.

Pode ser quebrada em etapas.

Pode ser tratada como máquina de estados.

Não precisa conhecer o domínio inteiro.

Não precisa armazenar dado durável.

Não deveria ter acesso ao contexto completo da aplicação.

No meu desenho, os servidores clone e o UbiQ possuem Secret Vault.

Quando precisam cifrar, decifrar, assinar, verificar, derivar chave, recriptografar payload, aplicar envelope encryption ou trabalhar com chave efêmera, eles não precisam necessariamente gastar CPU local.

Eles quebram esse processo em etapas e reenviam as partes computacionais para servidores de crypto.

Esses servidores recebem tarefas pequenas, executam e devolvem.

Eles não ficam com chave durável.

Não persistem payload sensível.

Não têm banco.

Não conhecem o domínio completo.

Não têm motivo para armazenar nada.

O modelo é:

Vault mantém autoridade;
Crypto worker executa cálculo;
UbiQ roteia;
Supervisor observa;
EventStore registra;
Política decide se pode executar.

O objetivo é reduzir blast radius.

Se um servidor de crypto cai, outro assume.

Se um worker é comprometido, ele não deveria ter material suficiente para reconstruir segredo completo.

Se a carga sobe, adiciono workers baratos.

Se a latência piora, o UbiQ muda a rota.

O servidor de crypto deve ser burro de propósito.

Quanto menos ele sabe, melhor.

Quanto menos ele guarda, melhor.

Quanto menos contexto ele tem, menor o impacto de comprometimento.

8. Actor/Supervisor em Zig como base operacional

A base do runtime é um modelo de Ator/Supervisor em Zig.

A escolha de Zig é intencional: controle de memória, binário pequeno, previsibilidade, baixo overhead, boa relação com processos, sockets, buffers, rede e integração com camadas próximas do sistema operacional.

Cada unidade operacional é um ator.

Cada ator possui supervisor.

Cada supervisor conhece política de restart, retry, timeout, isolamento, backoff, migração, degradação e encerramento.

O ponto mais importante é que eu já consigo escalar processos direto de uma imagem Docker para outro servidor sem escrever uma linha de configuração, porque isso já é padrão do meu runtime.

A imagem Docker não é apenas empacotamento.

Ela vira unidade operacional migrável.

O runtime sabe que aquele processo pode ser movido, recriado, pausado, reiniciado ou escalado em outro host conforme política do supervisor.

O desenvolvedor não precisa escrever YAML para cada caso.

O comportamento é do runtime.

Essa é uma das premissas mais importantes da arquitetura: comportamento obrigatório não deve depender da disciplina manual do programador.

Se um processo precisa ser supervisionado, migrável, mensurável, pausável, reiniciável e observável, isso não deve ser um favor do código da aplicação.

Deve ser uma propriedade nativa do runtime.

9. CPUManagerAgent e CPUSchedulerAgent por core

A parte mais crítica da escalabilidade local é o gerenciamento de CPU.

Eu uso a ideia de um CPUManagerAgent, que gerencia um CPUSchedulerAgent por core.

A inspiração vem da VM BEAM: processos leves, supervisão, isolamento e a ideia de que o runtime não pode deixar uma unidade de trabalho sequestrar a máquina.

Cada core tem um scheduler lógico.

Cada função ou processo recebe um orçamento máximo de ciclos.

Cada execução é medida.

Cada tipo de função possui benchmark próprio.

O runtime sabe quanto aquela função costuma custar.

O sistema mede todas as funções e define um limite máximo de ciclos onde mais de 99% dos processos conseguem finalizar.

Quando uma função ultrapassa esse limite, isso deixa de ser surpresa.

Ela passa a ser classificada como carga anômala, pesada, quebrável, migrável ou candidata a fila.

A política é:

se passou do limite, pausa;
se pode continuar em outro core, migra;
se precisa aguardar, vai para fila;
se é processo longo, quebra antes;
se é recorrente, atualiza o perfil da função;
se é perigoso, isola;
se afeta SLA, envia para outro servidor;
se pode virar máquina de estados, o runtime deve preferir esse formato antes da execução.

Isso evita que uma única função prenda CPU.

Uma operação de crypto, parsing, compressão, vetorização, snapshot, indexação ou persistência pesada não pode derrubar a responsividade do agente inteiro.

10. Limite máximo de ciclos e quebra antecipada

O ponto principal não é apenas pausar depois que travou.

O ponto é medir antes.

Eu defino um limite máximo de ciclos de CPU onde mais de 99% dos processos conseguem finalizar.

Esse limite não é arbitrário.

Ele vem de benchmark.

Cada função do sistema é medida.

O runtime observa quantas vezes aquela função ultrapassa o limite.

Se uma função ultrapassa pouco, ela pode continuar como está.

Se ultrapassa com frequência, ela muda de classe.

Se ultrapassa demais, o runtime já não deveria enviá-la inteira para execução.

Ela deve ser quebrada antes.

Isso transforma o sistema em algo mais previsível.

O runtime não espera a função se tornar um problema em produção.

Ele aprende o perfil de custo daquela função e passa a tratá-la conforme o comportamento real dela.

Uma função que sempre passa do limite não é uma função “normal”.

Ela é uma sequência de estados mal declarada.

11. Máquina de estados para processamento pesado

Todo processamento pesado deve ser quebrável.

Crypto, compressão, hashing grande, parsing, transformação de documentos, indexação vetorial, atualização de grafo, replicação de eventos e reconstrução de snapshot são candidatos naturais.

Em vez de executar uma função monolítica, o runtime transforma o processo em uma máquina de estados:

receber tarefa;
validar autorização;
separar fragmentos;
executar etapa 1;
registrar checkpoint;
executar etapa 2;
registrar checkpoint;
devolver resultado parcial;
agregar resultado;
validar integridade;
assinar resultado;
descartar material temporário.

Cada estado pode ser pausado, retomado, migrado, repetido ou descartado.

Esse é o segredo para rodar em servidores baratos sem depender de uma máquina grande.

Não é sobre ter CPU infinita.

É sobre nunca deixar uma tarefa indivisível sequestrar a CPU.

12. Como os servidores se comportam

Na arquitetura distribuída, cada servidor tem uma responsabilidade explícita.

Os clones rodam aplicação, agentes operacionais, Secret Vault, supervisores, runtime principal e QBEQStore local.

Eles podem assumir carga um do outro e recebem replicação em tempo real.

O eBPF/XDP atua antes da aplicação.

Ele filtra pacotes, aplica regras de admissão, reduz ruído, corta abuso e protege a entrada.

O UbiQ roteia intenções, eventos, agentes operacionais, shards, processos e replicação.

Ele decide onde escrever, onde processar, onde isolar, onde degradar e onde mover carga.

A persistência guarda estado durável, mas separa cada tipo de dado conforme sua natureza:

relacional;
documento;
vetor;
grafo;
evento;
métrica;
log;
cache;
busca;
analytics;
timeseries.

Os servidores de crypto executam carga CPU-bound sem armazenar estado sensível.

O CPUManagerAgent controla orçamento de CPU.

O CPUSchedulerAgent por core evita starvation.

O SupervisorAgent decide restart, retry, isolamento, migração e fallback.

O Intent Dynamic Validator impede que payload inválido avance.

O pipeline de recuperação tenta corrigir falhas recuperáveis por regras explícitas e políticas determinísticas.

O Human-in-the-Loop entra quando uma correção altera sentido, dinheiro, entidade, autorização, persistência ou efeito colateral.

13. Fluxo operacional de uma intenção

Um fluxo típico funciona assim:

A intenção chega.
O eBPF/XDP filtra o que é claramente inválido.
O UbiQ recebe ou coordena o roteamento.
O Intent Dynamic Validator valida estrutura e semântica.
O agente operacional correto recebe a intenção.
O CPUManagerAgent estima custo.
O CPUSchedulerAgent agenda a execução no core adequado.
Se houver crypto, o clone ou UbiQ consulta o Secret Vault.
Apenas a etapa computacional permitida é enviada para os workers de crypto.
O worker executa sem persistir nada.
O resultado volta.
O worker destrói material transitório.
O agente continua a máquina de estados.
O agente destrói o estado transitório da etapa.
O UbiQ decide o shard correto de persistência.
O EventStore registra o fato de forma criptografada.
O QBEQStore local registra o evento criptografado.
Os bancos derivados são atualizados conforme política.
O clone recebe replicação.
A observabilidade mede tudo sem vazar segredo.
Se algo falha, o supervisor decide: retry, restart, migração, fila, degradação, isolamento ou intervenção humana.

Nenhuma decisão crítica de runtime depende de agente de IA.

Nenhum componente de IA é necessário para esse fluxo existir.

14. Regra de ouro da arquitetura

A regra de ouro é:

nenhum processo pode ser grande demais para ser pausado;
nenhum estado pode ser importante demais para existir em apenas um lugar;
nenhum servidor pode ser confiável demais para não ter substituto;
nenhuma função pode ser crítica demais para não ter benchmark;
nenhum segredo pode ser exposto por conveniência;
nenhuma falha deve ser tratada como caso inesperado para sempre;
nenhum comportamento obrigatório deve depender de configuração manual repetitiva;
nenhuma correção automática deve alterar intenção, dinheiro, autorização ou persistência sem validação adequada;
nenhum servidor é confiável por padrão;
nenhum worker recebe segredo completo;
nenhuma rede interna é considerada segura;
nenhum payload avança sem validação;
nenhuma escrita acontece sem autoridade explícita;
nenhuma replicação é aceita sem integridade, causalidade e idempotência;
nenhum agente operacional mantém estado em RAM após concluir sua etapa;
nenhum evento fica persistido em claro;
nenhum QBEQStore armazena dado descriptografado;
nenhum dado sensível deve sobreviver em memória após uso.

Falhou uma vez: incidente.

Falhou duas vezes: padrão.

Falhou três vezes: o runtime precisa aprender.

15. Anti-fragilidade prática

Anti-fragilidade não é apenas alta disponibilidade.

Alta disponibilidade tenta continuar funcionando apesar da falha.

Anti-fragilidade tenta melhorar por causa da falha.

Na prática, cada erro precisa alimentar o sistema:

erro de rota melhora o roteador;
erro de payload melhora o validator;
erro de CPU melhora o scheduler;
erro de crypto melhora a fragmentação;
erro de persistência melhora o sharding;
erro de latência melhora o roteamento;
erro de provedor melhora a política multi-cloud;
erro de função longa melhora o benchmark;
erro de correção perigosa chama humano e melhora a política de recuperação;
erro de memória residual melhora a política LinearAutoDestroy;
erro de replay melhora o QBEQStore;
erro de mmap melhora o modelo de leitura criptografada;
erro de replicação melhora a causalidade entre clones.

O sistema não apenas se recupera.

Ele incorpora a falha como dado operacional.

Essa é a diferença entre um sistema apenas resiliente e um sistema anti-frágil.

O resiliente volta ao normal.

O anti-frágil volta com uma política melhor.

16. Manual operacional final

A arquitetura deve seguir estes princípios.

Primeiro: todo processo precisa ser supervisionado.

Processo sem supervisor não entra no runtime.

Segundo: toda função crítica precisa de benchmark.

Função sem perfil de custo não entra no hot path.

Terceiro: todo segredo precisa passar pelo Secret Vault.

Worker descartável não guarda segredo.

Quarto: toda tarefa pesada deve ser quebrável em máquina de estados.

Se não pode ser quebrada, precisa ir para fila isolada.

Quinto: todo servidor precisa ter função explícita.

Clone não é persistência.

Worker de crypto não é banco.

UbiQ não é aplicação genérica.

eBPF não é backend.

Sexto: toda persistência precisa respeitar a física do dado.

Relacional para transação.

Documento para flexibilidade.

Vetor para semântica.

Grafo para correlação.

EventStore para verdade histórica.

Timeseries para tempo.

Métricas e logs para observabilidade.

Cache para aceleração.

Busca para descoberta.

Analytics para leitura derivada.

Sétimo: toda correção precisa preservar intenção.

Se a correção muda significado, dinheiro, entidade, autorização, persistência ou efeito colateral, entra Human-in-the-Loop.

Oitavo: toda replicação precisa ser observável.

Clone quente sem métrica é ilusão.

Nono: todo limite precisa gerar dado.

Se uma função ultrapassa ciclos, isso entra no perfil dela.

Décimo: toda falha recorrente vira política de runtime.

Décimo primeiro: tudo deve ser Zero Trust por padrão.

Nada executa apenas porque está na rede interna.

Nada persiste apenas porque chegou ao banco.

Nada replica apenas porque veio de um clone.

Tudo precisa provar identidade, autorização, integridade, escopo e causalidade.

Décimo segundo: tudo deve ser LinearAutoDestroy por padrão.

Nenhum agente operacional, subAgent, worker ou processo deve reter estado em memória após processar.

Estado durável fica criptografado.

Estado transitório é destruído.

Estado reconstruído existe apenas pelo tempo necessário.

17. Política de CPU

Cada função recebe uma classe:

hot path;
normal;
pesada;
crypto;
I/O-bound;
CPU-bound;
migrável;
pausável;
não pausável;
idempotente;
com efeito colateral;
precisa de fila;
precisa de humano.

O CPUManagerAgent usa essa classificação para decidir como executar.

O CPUSchedulerAgent por core aplica orçamento.

Se a função termina dentro do limite, segue.

Se ultrapassa uma vez, registra.

Se ultrapassa frequentemente, muda de classe.

Se ultrapassa o limite máximo, pausa.

Se pode migrar, migra.

Se pode quebrar, quebra.

Se não pode quebrar, isola.

Se ameaça o runtime, mata e reexecuta via supervisor.

Se altera intenção, chama humano.

18. Política de crypto

Crypto nunca deve ser tratada como chamada comum.

Ela deve seguir política própria:

entrada mínima;
escopo mínimo;
tempo máximo;
sem persistência local;
sem log de segredo;
memória limpa após uso;
chave efêmera;
resultado assinado;
execução rastreável;
worker descartável;
checkpoint seguro;
falha recuperável;
reexecução idempotente quando possível.

Se uma operação de crypto precisa de material sensível demais, ela não deve sair do Vault.

Nesse caso, o Vault executa localmente ou divide a operação de outro modo.

O servidor de crypto deve ser burro de propósito.

Quanto menos ele sabe, melhor.

Quanto menos ele guarda, melhor.

Quanto menos contexto ele tem, menor o impacto de comprometimento.

19. Política de QBEQStore

O QBEQStore é o estado local criptografado dos agentes operacionais.

Ele existe para permitir agentes Stateful(0 RAM).

A política do QBEQStore é:

todo evento é criptografado;
todo evento possui causalidade;
todo evento possui integridade verificável;
todo evento possui versão de schema;
todo evento possui versão de política;
todo evento possui idempotence key quando aplicável;
todo evento pode ser consolidado;
todo estado pode ser reconstruído;
nenhum estado precisa ficar vivo em RAM após a execução;
nenhuma leitura deve descriptografar mais do que o necessário;
nenhuma consolidação deve manter material sensível em claro;
nenhum snapshot deve ser salvo sem criptografia;
nenhum replay deve vazar segredo em log, métrica ou trace.

O QBEQStore possui uma forma legível em grafo e uma forma binária otimizada.

A forma legível facilita inspeção e entendimento.

A forma binária acelera replay e consolidação.

O encrypted mmap permite leitura eficiente sem transformar o arquivo de eventos em estado vivo da aplicação.

O arquivo é mapeado.

O trecho necessário é lido.

O dado é descriptografado de forma mínima.

O estado é reconstruído temporariamente.

A etapa é executada.

O material transitório é destruído.

O novo evento ou snapshot é persistido criptografado.

20. Política de replicação

A replicação entre clones deve carregar o mínimo necessário para continuidade:

eventos;
idempotence keys;
estado de ator;
posição da máquina de estados;
sessão operacional;
snapshot quando necessário;
metadados de execução;
hashes de integridade;
versão de schema;
versão de política;
trace id;
causalidade.

O clone não deve depender de reconstrução manual.

Se o principal falha, o secundário já deve saber o suficiente para continuar ou retomar com perda mínima.

Clone quente não é backup.

Clone quente é continuidade operacional.

A replicação precisa respeitar Zero Trust e LinearAutoDestroy.

Ou seja:

clone não confia em clone;
evento replicado precisa provar integridade;
estado replicado precisa provar causalidade;
payload replicado precisa estar criptografado;
material transitório precisa ser destruído após aplicação;
divergência precisa ser detectável;
replay precisa ser idempotente;
conflito precisa virar evento, não silêncio.

21. Política de persistência

O UbiQ não deve persistir tudo no mesmo lugar.

Ele deve shardear por domínio, tipo de dado, criticidade e padrão de acesso.

Pedido, pagamento e estoque não têm a mesma física.

Log, métrica e evento não são a mesma coisa.

Embedding vetorial não é transação relacional.

Grafo de correlação não é documento.

EventStore não é cache.

A arquitetura correta aceita múltiplos bancos porque aceita que dados diferentes têm naturezas diferentes.

O erro é transformar Postgres, Mongo, Redis, Neo4j, Qdrant, ClickHouse ou qualquer outro banco em religião.

Banco é ferramenta física para um tipo de verdade.

22. Critério de sucesso

Essa arquitetura começa a funcionar de verdade quando:

um servidor cai e o sistema continua;
um processo trava e o core não fica preso;
uma função fica lenta e o runtime aprende;
um worker de crypto morre e outro assume;
uma rota falha e o UbiQ redireciona;
um payload vem errado e o validator segura;
uma correção é perigosa e chama humano;
um banco degrada e o shard muda;
um clone assume sem ritual manual;
um deploy novo não exige reescrever configuração;
um erro recorrente vira política;
uma função pesada é quebrada antes de travar;
um processo ultrapassa ciclos e é pausado, migrado ou enfileirado;
a arquitetura continua funcionando sem depender de agente de IA;
um agente operacional termina sem reter estado em RAM;
um evento é persistido criptografado;
um replay reconstrói estado sem manter dado vivo desnecessário;
um mmap acelera leitura sem virar vazamento de plaintext;
uma falha de memória residual vira melhoria de LinearAutoDestroy;
uma falha de confiança vira endurecimento de Zero Trust.

O objetivo não é nunca falhar.

O objetivo é falhar pequeno, falhar isolado, falhar medido, falhar recuperável e, quando possível, sair da falha com uma política melhor do que antes.

23. Onde quero críticas

Quero conselhos principalmente nestes pontos:

Como melhorar o isolamento real dos servidores de crypto?
Como garantir que o worker de crypto nunca receba material suficiente para reconstruir segredo?
Como desenhar melhor o protocolo entre Vault, UbiQ e crypto workers?
Como provar que a migração de processo entre servidores não quebra invariantes?
Como medir corretamente ciclos de CPU em ambientes virtualizados?
Como evitar que o benchmark fique viciado em cenário ideal?
Como definir limite de ciclos sem matar tarefas legítimas de cauda longa?
Como decidir quando pausar, migrar, quebrar ou enfileirar?
Como evitar que uma recuperação automática resolva o sintoma e corrompa a intenção original?
Como validar semanticamente antes e depois de uma correção?
Como fazer replicação em tempo real entre clones sem criar inconsistência silenciosa?
Como desenhar o sharding policromático entre documentos, relacional, vetor, grafo, timeseries, métricas e event store?
Como evitar custo invisível de egress entre provedores e regiões?
Como testar falhas reais de provedor, DNS, rota, storage, CPU steal, clock drift, fila, rede e disco?
Como impedir que o UbiQ vire ponto único de falha?
Como impedir que o scheduler crie starvation?
Como saber quando a persistência policromática ajuda e quando ela complica mais do que deveria?
Como provar LinearAutoDestroy em stack, heap, buffers, page cache, logs, traces e snapshots?
Como usar mmap sem transformar leitura eficiente em risco de plaintext residual?
Como garantir que QBEQStore criptografado continue rápido o suficiente para agentes Stateful(0 RAM)?
Como consolidar estado sem criar acúmulo de material sensível em memória?
Como auditar eventos criptografados sem vazar payload?
Como detectar divergência entre clones sem comparar plaintext?

24. Pedido final de revisão

Quero que pessoas melhores que eu em kernel, BEAM, sistemas distribuídos, criptografia, cloud, bancos, escalonamento, segurança ofensiva, SRE, linguagens, runtimes, mmap, event sourcing e armazenamento criptografado me ajudem a quebrar essa arquitetura.

Não quero validação estética.

Quero crítica técnica.

Quero pressão real sobre o desenho.

Quero encontrar as brechas antes que a produção encontre.

Porque a meta não é criar uma arquitetura complexa.

A meta é criar uma arquitetura onde a complexidade inevitável esteja no runtime, não na mão do operador.

Onde falha vire dado.

Onde processo seja migrável.

Onde CPU seja governada.

Onde crypto seja isolada.

Onde persistência respeite a natureza do dado.

Onde agente operacional não seja improviso.

Onde supervisor seja padrão.

Onde escalar não dependa de escrever configuração manual para cada caso.

Onde cada servidor tenha uma função explícita.

Onde cada função tenha perfil de custo.

Onde cada correção preserve intenção.

Onde cada segredo tenha escopo mínimo.

Onde cada falha recorrente vire política.

Onde Zero Trust seja padrão estrutural.

Onde LinearAutoDestroy seja comportamento nativo.

Onde eventos sejam criptografados por padrão.

Onde QBEQStore dê estado aos agentes sem transformar RAM em fonte de verdade.

Onde mmap acelere leitura sem virar vazamento.

Onde cada Agent seja Stateful(0 RAM).

E onde uma equipe pequena (se for eu pode ser 1 pessoa só, já trabalho como FullStack Web Dev Senior há 16 sanos, então é ÓBVIO que sei escalar e deployar qualquer sistema e NENHUM que já trabalhei chegar perto dessa Arquitetura) consiga operar uma infraestrutura que, em arquiteturas tradicionais, exigiria um time inteiro apenas para manter viva.

Sobre o uso de eBPF para Edgewall (antes do Firewall)

Eu escrevi uma explicação mais detalhada aqui FullAgenticStack: eBPF “de verdade” em VPS vs Bare Metal

Psicologia Sem Querer: BehaviorID - Como a Busca por Eficiência em IA Me Levou à Topografia da Decisão

suissAI — Wed, 01 Jul 2026 11:13:12 +0000

Eu não comecei tentando criar uma arquitetura de psicologia comportamental.

Comecei tentando resolver um problema técnico, pragmático e bastante concreto: como hiper-personalizar uma interação com IA usando o mínimo possível de dados, tokens e contexto.

Em sistemas de IA, existe uma tendência quase automática de jogar mais dados no problema. Mais histórico. Mais memória. Mais embeddings. Mais contexto. Mais inferência. Mais custo. Só que, para mim, isso sempre pareceu um desperdício arquitetural. Se a decisão humana deixa rastros, talvez o ponto não seja armazenar tudo. Talvez o ponto seja descobrir quais sinais realmente importam.

Foi aí que percebi que o valor não estava apenas no que a pessoa dizia. Estava no movimento entre uma fala e outra.

O sentimento isolado era pouco. Dizer que uma mensagem é “positiva”, “negativa” ou “neutra” parecia uma fotografia congelada de algo que, na prática, é dinâmico. A decisão humana não acontece como um ponto fixo. Ela acontece como deslocamento: curiosidade, dúvida, comparação, resistência, aceitação, abandono, confiança.

A pergunta deixou de ser: “qual é o sentimento do usuário agora?”

E passou a ser: “qual foi a transição cognitiva que trouxe o usuário até aqui?”

Sentimento é superfície. Transição é trajetória.

A análise de sentimento tradicional costuma olhar para uma interação como se ela fosse um estado final. Mas uma pessoa não decide apenas porque está positiva ou negativa. Ela decide porque atravessou uma sequência de microestados.

Um cliente pode começar curioso, depois ficar hesitante, depois comparar alternativas, depois voltar a se engajar e finalmente aceitar. Outro pode começar engajado, perceber risco, entrar em resistência e abandonar.

Esses dois casos não podem ser tratados apenas como “positivo” ou “negativo”. Eles possuem topografias diferentes.

Foi dessa percepção que nasceu a ideia de SemTempo: uma combinação entre semântica e temporalidade. O tempo não é só metadado. A latência de resposta não é só atraso. A ordem das mensagens não é só histórico. Tudo isso carrega sentido.

Uma resposta imediata pode indicar impulso, reflexo, familiaridade ou reação emocional. Uma resposta demorada pode indicar comparação, esforço cognitivo, dúvida ou deliberação. Em termos simples, o tempo de resposta ajuda a diferenciar uma reação mais automática de uma decisão mais refletida.

O que eu estava tentando otimizar era IA. Mas, sem querer, eu estava começando a desenhar uma arquitetura de leitura comportamental.

A regra das três mensagens

Para não depender de histórico infinito, criei uma heurística simples: olhar para três pontos.

Estado anterior.
Transição.
Estado atual.

Essa tríade se tornou uma unidade mínima de leitura comportamental. Em vez de tentar compreender toda a vida do usuário, o sistema observa o deslocamento recente.

Não é necessário saber tudo. É necessário saber o suficiente para entender a direção da mudança.

Por exemplo:

HES → Confirmação → ACE

Esse fluxo representa uma pessoa que começou em hesitação, passou por algum mecanismo de validação interna e terminou em aceitação.

Outro exemplo:

CUR → Exploração → ENG

Aqui, a curiosidade se transforma em engajamento.

Ou ainda:

ENG → Objeção → RES

Nesse caso, o engajamento inicial encontrou algum atrito e se converteu em resistência.

Essa estrutura virou o que chamei de BehaviorID.

BehaviorID = INITIAL — COGTRANSITION — FINAL

O BehaviorID não é uma etiqueta emocional. Ele é uma impressão digital de transição. Ele descreve não apenas onde a pessoa está, mas como ela chegou ali.

Do RAG tradicional ao Cognitive Behavior SemTempo Graph RAG

O RAG tradicional recupera fatos.

Ele responde perguntas como: “quais informações são semanticamente parecidas com esta consulta?”

Isso é útil, mas limitado quando o problema envolve decisão humana. Em vendas, educação, atendimento, saúde, suporte ou assistentes pessoais, o ponto mais importante nem sempre é recuperar o fato mais parecido. Muitas vezes, é recuperar a trajetória mais parecida.

O que aconteceu antes de uma conversão parecida?

Qual foi o padrão que antecedeu uma desistência?

Que tipo de intervenção reduziu resistência sem gerar manipulação?

Qual sequência de perguntas ajudou um aluno a sair da dependência e alcançar domínio?

O Cognitive Behavior SemTempo Graph RAG nasce dessa diferença. Ele não trata memória como um depósito de chunks. Trata memória como um grafo vivo de trajetórias comportamentais.

Enquanto um RAG tradicional olha para similaridade semântica, esse modelo olha para transição, causalidade e ordem.

O dado deixa de ser apenas “o que foi dito”. Passa a ser:

o que foi dito
quando foi dito
em que estado a pessoa parecia estar
qual transição ocorreu depois
qual foi o efeito da intervenção
qual novo estado apareceu

Isso muda completamente a forma de pensar personalização.

A linguagem corporal digital

No mundo físico, uma pessoa hesita com o corpo. Ela pausa. Desvia o olhar. Reorganiza a fala. Muda o tom. No digital, esses sinais aparecem de outra maneira.

Eles aparecem no tempo de resposta, na quantidade de texto, na escolha das palavras, na mudança de estrutura, no nível de detalhe, no retorno a perguntas já feitas, no excesso de justificativas ou na súbita redução de engajamento.

Essa é a linguagem corporal digital.

Alguns estados comportamentais básicos podem ser modelados assim:

CUR = Curiosidade
ENG = Engajamento
HES = Hesitação
COM = Comparação
RES = Resistência
ACE = Aceitação
NEG = Negação
DEP = Dependência
MAS = Domínio / Mastery

Esses estados não devem ser tratados como diagnóstico psicológico. Eles são estados operacionais de interação. Servem para orientar uma arquitetura, não para rotular uma pessoa.

Esse ponto é essencial.

Uma arquitetura comportamental responsável não tenta invadir a mente do usuário. Ela tenta respeitar melhor o momento da interação.

A física das transições humanas

Quando comecei a modelar essas transições, percebi que algumas mudanças eram leves e naturais, enquanto outras exigiam muito mais esforço.

Sair de curiosidade para engajamento é relativamente fácil. A curiosidade já possui energia interna. Basta oferecer um caminho claro.

Mas sair de negação para aceitação é difícil. Envolve defesa, identidade, risco percebido, reinterpretação e confiança.

Por isso, comecei a pensar em pesos de transição.

CUR → ENG = baixo custo cognitivo
HES → ACE = custo médio
RES → ACE = alto custo
NEG → ACE = custo máximo

Essa matriz de custo é uma forma de representar o esforço psicológico necessário para mover alguém de um estado a outro.

Em vendas, isso ajuda a evitar abordagens burras. Se uma pessoa está em resistência, não adianta empurrar conversão. O sistema precisa reduzir ameaça, aumentar segurança e talvez oferecer comparação, prova ou tempo.

Em educação, essa mesma lógica muda completamente.

O fork pedagógico: LearnerID

A arquitetura que nasceu para decisão comercial acabou abrindo um caminho pedagógico.

Em vendas, a tendência é reduzir fricção. Se o usuário está hesitando, você tenta remover a dúvida. Se está comparando, você tenta mostrar valor. Se está resistindo, você tenta diminuir risco.

Na educação, o objetivo não é remover toda fricção. Pelo contrário. Aprender exige atrito cognitivo.

A dúvida, que em vendas pode ser risco de churn, em pedagogia pode ser sinal de crescimento.

Foi daí que surgiu o LearnerID.

O LearnerID é uma adaptação do BehaviorID para trajetórias de aprendizagem. Ele não busca apenas conversão. Busca autonomia.

Em vez de levar o aluno rapidamente para uma resposta, o sistema precisa observar se ele está em luta produtiva ou em bloqueio real.

Se o aluno está perto de compreender, a IA não deve entregar a resposta pronta. Ela deve sustentar o andaime. Fazer uma pergunta melhor. Dar uma pista. Reduzir apoio aos poucos. Aplicar fading.

O objetivo não é dependência. É agência epistêmica.

Uma IA pedagógica ruim cria alunos dependentes. Uma IA pedagógica boa ajuda o aluno a pensar sem ela.

Agentes determinísticos, IA probabilística e responsabilidade

Esse modelo também reforçou outra convicção minha: IA não deve ser confundida com agente.

A IA pode interpretar ambiguidade. Pode sugerir. Pode resumir. Pode classificar. Pode inferir.

Mas o agente precisa ter identidade, política, contrato, rastreabilidade e responsabilidade.

Em uma Full Agentic Stack, a IA não é o núcleo soberano da execução. Ela é uma camada cognitiva dentro de um ecossistema mais amplo. O agente determinístico executa o que pode ser auditado. A IA apoia onde existe ambiguidade.

Isso é importante porque sistemas comportamentais são poderosos. Se um sistema consegue identificar hesitação, resistência, curiosidade ou vulnerabilidade, ele também pode ser usado de forma manipulativa.

Por isso, a arquitetura precisa nascer com limites.

Não basta perguntar: “isso converte mais?”

É preciso perguntar:

isso respeita a intenção do usuário?
isso preserva autonomia?
isso reduz confusão ou explora fragilidade?
isso é auditável?
isso pode ser explicado?
isso pode ser contestado?

A arquitetura comportamental só faz sentido se for acompanhada por governança.

Psicologia sem querer

O mais curioso dessa jornada é que eu não comecei pela teoria.

Eu comecei pela restrição.

Queria gastar menos tokens.
Queria depender de menos dados.
Queria criar uma arquitetura mais eficiente.
Queria que a IA entendesse melhor o momento da pessoa.
Queria evitar que o sistema tratasse todo usuário como se estivesse no mesmo estado.

Ao tentar resolver isso, acabei chegando em conceitos que dialogam com psicologia comportamental, teoria cognitiva, aprendizagem, tomada de decisão e interação humano-computador.

Mas a ordem foi importante.

Eu não parti da psicologia para encaixar tecnologia nela.

Eu parti de um problema técnico e encontrei a psicologia no caminho.

Isso, para mim, é o valor da abordagem Solution-First: primeiro você encosta no problema real, sente a restrição, constrói uma solução mínima, observa o comportamento emergente e só depois nomeia o que foi descoberto.

A topografia da decisão

Hoje, eu vejo essa arquitetura como uma tentativa de mapear a topografia da decisão.

Não para controlar pessoas.

Não para reduzir o humano a um vetor.

Não para transformar psicologia em automação barata.

Mas para criar sistemas que reconhecem que uma decisão tem relevo. Tem subida, descida, atrito, pausa, retorno, hesitação e avanço.

A maioria dos sistemas digitais ainda trata o usuário como um evento isolado. Clicou. Não clicou. Comprou. Não comprou. Respondeu. Sumiu.

Mas existe uma camada muito mais rica entre o estímulo e a ação.

Existe a transição.

E talvez seja nela que more a parte mais importante da inteligência aplicada.

O futuro das interfaces inteligentes não está apenas em entender palavras. Está em entender mudanças.

Não basta saber o que o usuário disse.

É preciso entender de onde ele veio, para onde está indo e qual responsabilidade o sistema assume ao tentar influenciar esse caminho.

Buscando otimizar meu Agent de CRM acabei criando 1 conceito de modelagem cognitivo-comportamental do último estado do lead e só depois que finalizei achei todo o embasamento teórico que o valida,

suissAI — Sun, 28 Jun 2026 17:11:59 +0000

suissAI

Jun 26

The Accidental Architect: How Bot Optimization Led to a Behavioral Trajectory Framework - BehaviorID

11 min read

O Programador Pragmático: como aplico seus conceitos mais de duas décadas depois da primeira leitura

suissAI — Sun, 28 Jun 2026 10:11:20 +0000

Eu li O Programador Pragmático, de Andrew Hunt e David Thomas, há mais de duas décadas.

Na época, muita coisa parecia apenas “boa prática”. Hoje, depois de anos programando, quebrando sistemas, refatorando ideias, criando arquiteturas, automatizando fluxos e tentando transformar código em infraestrutura confiável, eu vejo esse livro de outra forma.

Para mim, ele não é apenas um livro sobre programação.

Ele é um livro sobre postura.

É sobre como um programador pensa quando assume responsabilidade real sobre o que constrói. É sobre parar de tratar código como uma sequência de arquivos e começar a enxergar software como um organismo que precisa ser mantido, observado, corrigido, automatizado e melhorado continuamente.

Depois de mais de 20 anos, eu não uso os conceitos do livro como uma lista de regras. Eu uso como uma lente para resolver problemas.

Responsabilidade pessoal: o código tem autor

Um dos pontos mais fortes do livro é a ideia de responsabilidade pessoal.

Programador pragmático não terceiriza culpa.

Se o sistema que eu construí falhou, eu preciso entender por quê. Não adianta colocar a culpa no framework, na linguagem, no banco, no servidor, no usuário ou no cliente antes de investigar tecnicamente o problema.

Isso não significa assumir culpa por tudo de forma ingênua. Significa assumir autoria.

Quando eu desenho uma arquitetura, escrevo uma regra, defino uma DSL, crio um fluxo de autenticação, monto um pipeline de agentes ou especifico um contrato de sistema, eu parto do princípio de que aquilo precisa ser explicável, testável e auditável.

Se algo quebra, a pergunta não é:

“De quem é a culpa?”

A pergunta é:

“Qual suposição do sistema estava errada?”

Essa mudança é brutal.

Porque a partir do momento em que você para de procurar culpados e começa a procurar suposições falsas, você começa a evoluir como arquiteto.

Teoria das Janelas Quebradas: gambiarra tolerada vira cultura

A teoria das janelas quebradas é uma das ideias mais importantes para qualquer sistema de software.

Um bug óbvio ignorado vira normalidade.

Um código ruim aceito vira padrão.

Uma variável hardcoded deixada “só por enquanto” vira dependência invisível.

Uma configuração manual vira ritual.

Uma exceção sem tratamento vira comportamento esperado.

Esse conceito me influenciou muito na forma como penso sistemas. Hoje, eu não enxergo uma gambiarra apenas como uma gambiarra. Eu enxergo como um sinal cultural dentro do código.

Quando um sistema aceita sujeira demais, ele começa a educar os próximos programadores a também aceitarem sujeira.

Por isso eu tento transformar tudo que é frágil em uma estrutura explícita: configuração, contrato, manifesto, schema, teste, regra, evento, pipeline, validação, spec executável, política de segurança ou documento técnico.

Não é perfeccionismo.

É contenção de entropia.

Aproveitar mudanças: sistemas rígidos morrem cedo

Outra ideia central do livro é não lutar contra mudanças.

Software muda.

Regra de negócio muda.

Cliente muda.

Interface muda.

Banco muda.

Framework muda.

Modelo de IA muda.

Protocolo muda.

A pior arquitetura é aquela que depende da ilusão de estabilidade eterna.

Na minha forma de programar, isso aparece na tentativa de separar responsabilidades em camadas bem definidas: intenção, validação, autenticação, transporte, persistência, evento, observabilidade, automação e política.

Eu tento evitar sistemas onde uma mudança pequena causa um efeito cascata imprevisível.

Se trocar o banco quebra a interface, tem algo errado.

Se mudar uma regra de negócio exige mexer em dez arquivos sem relação direta, tem algo errado.

Se alterar uma configuração exige recompilar código, tem algo errado.

Se uma decisão operacional está escondida dentro de uma variável no meio do código, tem algo errado.

A mudança precisa ser esperada, não tratada como acidente.

DRY: eu repito antes de abstrair

O princípio DRY — Don't Repeat Yourself — costuma ser interpretado de forma superficial como “não repita código”.

Eu não penso assim.

Para mim, o DRY verdadeiro é:

Não duplique conhecimento consolidado.

Isso é muito diferente de “nunca repetir nada”.

Na etapa inicial de uma ideia, eu repito muita coisa de propósito.

Eu repito estruturas.

Repito fluxos.

Repito validações.

Repito formatos.

Repito padrões parecidos em cenários diferentes.

Mas eu faço isso não por descuido. Eu faço para observar.

Antes de transformar algo em padrão, eu quero saber se aquilo realmente é um padrão.

Muita abstração nasce cedo demais. E abstração prematura é uma das formas mais perigosas de acoplamento.

Quando você abstrai antes de entender, você congela uma hipótese como se fosse arquitetura.

Então eu prefiro repetir no começo, comparar os casos reais, entender o que muda, entender o que permanece e só depois consolidar.

O DRY, para mim, acontece depois da validação do comportamento. Eu gosto que chamar DRYS! Quase um DRY + KISS, mas é Don´t Repeat Yourself Stupid! Mas não é amaioria dos programadores que enxerga padroes facilmente e prefere criar um padrão genérico reusável

Primeiro eu observo a repetição.

Depois eu identifico o conhecimento duplicado.

Depois eu transformo em contrato, DSL, manifesto, schema, função, componente, pipeline ou regra.

DRY não é medo de repetir.

DRY é maturidade para saber quando uma repetição virou conhecimento reutilizável.

Everything as Code extremo: desde 2025 eu não escrevo mais valor de variável no código

Um dos pontos em que mais radicalizei minha prática foi no conceito de Everything as Code.

Desde 2025, eu passei a levar isso ao extremo: não escrevo mais nenhum valor de variável diretamente no código.

Valor não pertence ao código.

Valor pertence à configuração, ao ambiente, ao manifesto, ao schema, ao contrato, ao arquivo declarativo, ao secret manager, ao pipeline ou à política.

O código deve expressar comportamento.

A configuração deve expressar contexto.

Quando você coloca valor direto no código, você mistura duas coisas que deveriam ficar separadas:

O que o sistema faz.
Em qual contexto ele está rodando.

Essa separação muda tudo.

Uma URL não deve estar perdida dentro de uma função.

Um token não deve estar no código.

Um nome de instância não deve estar hardcoded.

Um tempo de sessão não deve estar escondido numa constante arbitrária.

Um limite operacional não deve depender de alguém lembrar onde alterar.

Quando tudo vira código declarativo, versionável e auditável, o sistema fica mais fácil de testar, migrar, revisar e automatizar.

Esse é um dos pontos onde minha leitura do Programador Pragmático evoluiu muito. O livro fala sobre automação, ferramentas e responsabilidade. Hoje, para mim, Everything as Code é a consequência natural desses princípios.

Não é apenas infraestrutura como código.

É política como código.

Configuração como código.

Contrato como código.

Validação como código.

Documentação como código.

Teste como código.

Segurança como código.

Intenção como código.

Operação como código.

Quanto menos decisão invisível existe dentro do sistema, mais pragmático ele se torna.

Ortogonalidade: cada coisa precisa quebrar sozinha

Ortogonalidade é uma ideia simples, mas difícil de manter.

Um sistema ortogonal permite que uma parte mude sem destruir outra.

Na prática, isso significa que banco, interface, autenticação, fila, agente, regra de negócio, transporte e observabilidade não deveriam estar misturados como se fossem uma única massa.

Eu tento pensar sistemas como planos separados.

O plano de escrita não é o plano de leitura.

O plano de identidade não é o plano de transporte.

O plano de intenção não é o plano de execução.

O plano de configuração não é o plano de comportamento.

O plano de segurança não é um detalhe no final.

Quando essas coisas ficam misturadas, qualquer mudança vira medo.

Quando ficam separadas, mudança vira manutenção.

Ortogonalidade não é apenas organização bonita de pastas. É capacidade real de alterar o sistema sem gerar colapso.

Programação por coincidência: “funcionou” não é explicação técnica

Um dos vícios mais comuns na programação é aceitar que algo está certo porque funcionou uma vez.

Isso é programação por coincidência.

Rodou localmente.

Passou no teste manual.

Funcionou no meu ambiente.

O usuário clicou e não quebrou.

Mas isso não prova entendimento.

Para mim, código bom precisa ser explicável. Eu preciso saber por que funciona, quais suposições ele faz, quais entradas aceita, quais estados rejeita e quais falhas são esperadas.

Se eu não consigo explicar o comportamento, eu ainda não tenho arquitetura. Tenho sorte operacional.

Isso se tornou ainda mais importante com agentes, IA, automação e sistemas distribuídos. Quanto mais partes autônomas existem, menos aceitável é depender de coincidência.

Por isso eu gosto de contratos, eventos, logs, traces, validações, testes e formatos declarativos.

Eles reduzem a zona de magia.

Ferramentas básicas: domínio real vem do chão

O Programador Pragmático valoriza muito as ferramentas básicas.

Editor.

Terminal.

Controle de versão.

Scripts.

Debuggers.

Logs.

Testes.

Automação.

Isso continua extremamente atual.

Não importa se hoje usamos IA, agentes, copilotos ou modelos locais. Quem não entende o chão da programação fica dependente demais da camada de abstração.

Eu uso IA, mas não trato IA como substituta de fundamento.

A IA pode acelerar escrita, comparação, geração, revisão e exploração. Mas a responsabilidade técnica continua sendo minha.

O programador ainda precisa entender arquivo, processo, rede, permissão, memória, build, deploy, configuração, protocolo, teste e erro.

Ferramenta poderosa sem fundamento vira gerador de acidente sofisticado.

Automação: se repete, vira pipeline

Automação é um dos pontos mais pragmáticos do livro.

Se algo precisa ser feito mais de uma vez, eu começo a desconfiar que deveria virar script, pipeline, teste, comando, job, agente ou configuração.

Tarefa manual repetitiva é uma fonte permanente de erro humano.

E pior: tarefa manual repetitiva cria dependência tribal. Só uma pessoa sabe fazer. Só uma pessoa lembra a ordem. Só uma pessoa entende o detalhe.

Isso é frágil.

Automatizar é transformar conhecimento operacional em sistema.

Não é apenas ganhar tempo.

É reduzir variação.

É criar rastreabilidade.

É permitir repetição confiável.

É deixar o processo menos dependente de memória humana.

Prototipagem rápida: rascunho não é produto

Eu gosto muito da ideia de prototipagem rápida, mas com uma distinção importante: protótipo não é produto.

Protótipo serve para aprender.

Serve para testar uma hipótese.

Serve para descobrir se uma ideia tem forma.

Serve para identificar limites.

Serve para perceber que uma abstração ainda não deveria existir.

O erro é transformar protótipo em produção sem pagar a dívida técnica.

Eu uso protótipos para validar comportamento antes de consolidar arquitetura. Isso se conecta diretamente com minha visão de DRY: primeiro eu deixo a repetição aparecer, depois eu extraio o padrão.

O protótipo é o laboratório.

A arquitetura é o que sobra depois que a hipótese sobrevive ao teste.

Paranoia pragmática: o sistema precisa desconfiar de si mesmo

Paranoia pragmática não é pessimismo.

É engenharia.

Sistema bom não presume que tudo vai funcionar.

Ele valida entrada.

Verifica estado.

Confere permissão.

Testa contrato.

Rejeita payload inválido.

Trata erro.

Emite evento.

Registra log.

Expõe trace.

Falha de forma controlada.

Essa mentalidade influencia muito minha forma de programar. Eu não gosto de sistemas que apenas “seguem o fluxo feliz”. O fluxo feliz é só uma parte pequena da realidade.

A realidade é timeout, payload incompleto, token expirado, permissão insuficiente, estado inconsistente, retry duplicado, concorrência, ordem errada, usuário confuso, serviço fora, banco lento e integração quebrada.

Código pragmático precisa sobreviver ao mundo real.

Debugging: eliminar suspeitas, não procurar culpados

Depuração é investigação.

Não é raiva.

Não é chute.

Não é superstição.

Quando algo quebra, eu tento reduzir o espaço de incerteza.

Qual foi a entrada?

Qual era o estado anterior?

Qual contrato foi violado?

Qual evento ocorreu antes?

Qual suposição deixou de ser verdadeira?

Qual camada recebeu algo que não deveria receber?

Qual parte do sistema aceitou uma inconsistência cedo demais?

Esse método muda a forma de resolver problemas. Em vez de sair alterando coisas aleatórias até funcionar, você vai eliminando suspeitas.

Debugging pragmático é quase científico: hipótese, observação, teste, eliminação e causa raiz.

Testes ruthless: testar antes que o usuário teste

O usuário não deveria ser o primeiro testador real do sistema.

Quando o usuário encontra o erro, o erro já passou por várias camadas sem ser barrado.

Passou pelo código.

Passou pela validação.

Passou pelo teste.

Passou pelo deploy.

Passou pela observabilidade.

Passou pela revisão.

Por isso eu gosto da ideia de testar com agressividade.

Teste não é enfeite.

Teste é uma forma de definir comportamento esperado.

É uma forma de proteger decisões.

É uma forma de impedir regressão.

É uma forma de documentar o sistema executando.

E, principalmente, é uma forma de humildade técnica.

Quem testa reconhece que pode estar errado.

Melhoria contínua: estudar não é fase, é manutenção profissional

O livro também fala sobre melhoria contínua.

Isso ficou ainda mais importante hoje.

A tecnologia muda rápido demais. Linguagens, runtimes, bancos, IA, protocolos, autenticação, infraestrutura, segurança, ferramentas e formas de construir software mudam o tempo todo.

Mas melhoria contínua não é sair correndo atrás de toda novidade.

É saber estudar com critério.

Eu tento absorver novas tecnologias perguntando:

Que problema real isso resolve?

Que suposição antiga isso quebra?

O que isso torna mais simples?

O que isso torna mais perigoso?

Isso elimina complexidade ou só muda a complexidade de lugar?

Essa postura evita tanto o conservadorismo preguiçoso quanto o hype vazio.

Comunicação efetiva: código também é conversa

Programar é comunicar.

Com o computador.

Com outros programadores.

Com o usuário.

Com o cliente.

Com o futuro mantenedor.

Com você mesmo daqui a seis meses.

Por isso documentação, nomes, contratos, eventos, mensagens de erro e arquitetura importam tanto.

Um sistema mal comunicado vira um sistema difícil de manter.

Eu vejo cada nome como uma decisão semântica. Nome de função, nome de evento, nome de agente, nome de protocolo, nome de DSL, nome de entidade. Tudo comunica uma intenção.

Quando o nome é ruim, o sistema começa a mentir.

Quando o sistema mente, o programador precisa adivinhar.

E quando o programador precisa adivinhar, a programação por coincidência volta.

O que ficou depois de duas décadas

Depois de mais de 20 anos, o que ficou de O Programador Pragmático para mim não foi uma lista de dicas.

Foi uma postura.

Assumir autoria.

Não tolerar sujeira invisível.

Automatizar o repetitivo.

Prototipar antes de cristalizar.

Testar antes de confiar.

Separar comportamento de configuração.

Evitar coincidência.

Criar sistemas que aceitam mudança.

Comunicar intenção com clareza.

E, principalmente, entender que programar não é apenas escrever código.

Programar é criar estruturas que sobrevivem à mudança, ao erro, ao tempo e às pessoas.

Hoje, quando eu levo Everything as Code ao extremo, quando evito valores hardcoded, quando separo configuração de comportamento, quando repito antes de abstrair, quando transformo padrões em contratos e quando tento desenhar sistemas auditáveis, eu vejo uma linha direta com aquela leitura antiga.

O Programador Pragmático envelheceu bem porque ele não era sobre tecnologia da moda.

Era sobre maturidade técnica.

E maturidade técnica continua sendo uma das coisas mais raras e mais valiosas em software.

Movimiento 0deps — Dependencias Locales, Contratos Inmutables y Seguridad por Diseño

suissAI — Sun, 28 Jun 2026 08:06:47 +0000

Durante años, la industria del software adoptó una cultura de instalar decenas o incluso cientos de bibliotecas externas en prácticamente todos los proyectos. Los frameworks modernos suelen depender de miles de dependencias transitivas, lo que significa que una sola aplicación puede terminar dependiendo de código mantenido por cientos de colaboradores desconocidos.

Aunque este ecosistema ha acelerado enormemente el desarrollo de software, también ha introducido una nueva categoría de riesgos: la cadena de suministro de software (Software Supply Chain).

El Movimiento 0deps nace de una pregunta simple:

¿Y si una aplicación dependiera únicamente del código que realmente controla?

El problema de las dependencias

Cada dependencia incrementa la superficie de ataque.

Puede:

Introducir vulnerabilidades de seguridad.
Convertirse en el objetivo de un ataque a la cadena de suministro.
Ser abandonada.
Cambiar su API pública.
Eliminar funcionalidades.
Romper la compatibilidad hacia atrás.
Incorporar nuevas dependencias transitivas.
Publicar versiones incompatibles.

En la práctica, los desarrolladores pierden el control sobre una parte significativa del código que se ejecuta en producción.

Cuanto mayor es el árbol de dependencias, mayor es la superficie potencial de ataque.

La propuesta

En el modelo 0deps, todas las dependencias necesarias se incorporan directamente al repositorio del proyecto.

Las dependencias dejan de descargarse dinámicamente mediante gestores de paquetes durante la instalación o el proceso de compilación.

Todo lo necesario para compilar y ejecutar la aplicación ya se encuentra dentro del repositorio desde el momento en que este se clona.

Esto ofrece varias ventajas importantes:

Compilaciones reproducibles.
Menor dependencia de registros de paquetes externos.
Auditoría de seguridad centralizada.
Mayor previsibilidad.
Reducción de la superficie de ataque de la cadena de suministro.

Contratos públicos inmutables

El principio fundamental de 0deps no consiste en hacer que las implementaciones sean inmutables.

Las implementaciones evolucionan.

Los algoritmos evolucionan.

Las correcciones de seguridad evolucionan.

Lo que permanece estable es el contrato público.

Cada biblioteca expone una interfaz pública cuidadosamente diseñada.

Por ejemplo:

authenticate()

createSession()

verifyPasskey()

sendMagicLink()

Estas funciones definen un contrato.

Ese contrato nunca cambia.

La implementación subyacente puede reescribirse por completo.

Los algoritmos pueden cambiar.

Las bibliotecas internas pueden sustituirse.

Los protocolos pueden evolucionar.

Las estructuras de datos pueden rediseñarse.

Ninguno de estos cambios internos afecta la forma en que el resto de la aplicación utiliza la biblioteca.

Actualizaciones de seguridad sin romper aplicaciones

Siempre que se descubre una vulnerabilidad, normalmente surgen dos preocupaciones:

Corregir la vulnerabilidad.
Determinar cuántas aplicaciones dejarán de funcionar después de la actualización.

Dentro de la arquitectura 0deps, la segunda preocupación prácticamente desaparece.

Las actualizaciones se realizan internamente.

La implementación detrás de la interfaz se modifica.

La API pública permanece exactamente igual.

Las aplicaciones continúan funcionando sin necesidad de modificar su código.

En otras palabras, la implementación evoluciona mientras el contrato permanece estable.

Adaptadores internos

Toda integración externa queda aislada detrás de un adaptador interno.

Aplicación
↓
Interfaz pública
↓
Adaptador
↓
Implementación

Si una biblioteca externa deja de existir o queda obsoleta mañana, solo será necesario modificar el adaptador.

Ninguna otra parte de la aplicación se verá afectada.

Este aislamiento reduce drásticamente el impacto de los cambios tecnológicos a lo largo del tiempo.

Versionado invisible

Las aplicaciones construidas bajo el modelo 0deps nunca interactúan directamente con las API de bibliotecas externas.

Se comunican exclusivamente mediante contratos internos estables.

Las versiones de las bibliotecas se convierten en un simple detalle de implementación.

Los mantenedores del framework asumen la responsabilidad de las actualizaciones.

Los desarrolladores de aplicaciones continúan utilizando exactamente la misma interfaz, independientemente de los cambios internos.

Seguridad de la cadena de suministro

El objetivo de 0deps no es afirmar que el software se vuelva invulnerable.

Su propósito es reducir significativamente los riesgos asociados a la cadena de suministro de software.

Al eliminar la instalación dinámica de dependencias durante el proceso de compilación, la arquitectura reduce la exposición a amenazas como:

Publicación de paquetes maliciosos.
Compromiso de registros de paquetes.
Ataques de dependency confusion.
Paquetes de typosquatting.
Cambios inesperados en dependencias transitivas.

Todo el código ejecutable pasa a formar parte del propio proyecto, lo que permite auditoría, control de versiones y revisiones de seguridad centralizadas.

Estabilidad a largo plazo

El mayor beneficio de 0deps se hace evidente años después de que un proyecto entra en producción.

Los proyectos viven durante décadas.

Las bibliotecas desaparecen.

Los frameworks cambian.

Los ecosistemas evolucionan.

A pesar de todo ello, las aplicaciones continúan utilizando exactamente los mismos contratos públicos.

La responsabilidad de adaptarse a la evolución del ecosistema deja de estar distribuida entre todas las aplicaciones y pasa a concentrarse en los adaptadores internos del proyecto.

Las actualizaciones potencialmente disruptivas se convierten en simples sustituciones de implementación.

El Movimiento

El Movimiento 0deps no está en contra del software de código abierto.

Todo lo contrario.

Reconoce el enorme valor del software libre y de código abierto, pero propone un modelo diferente de consumo.

Las bibliotecas dejan de tratarse como dependencias instaladas dinámicamente.

En su lugar, pasan a ser componentes integrados en el proyecto, auditados, versionados y encapsulados detrás de contratos públicos estables.

El resultado es un software más predecible, más resiliente, más fácil de mantener y significativamente menos expuesto a los riesgos de la cadena de suministro.

Las implementaciones pueden evolucionar indefinidamente.

El contrato permanece inalterado.

Y es precisamente esa estabilidad la que permite que las aplicaciones desarrolladas hoy sigan funcionando exactamente de la misma manera durante muchos años.

Mouvement 0deps — Dépendances Locales, Contrats Immuables et Sécurité par Conception

suissAI — Sun, 28 Jun 2026 07:57:19 +0000

Pendant des années, l'industrie du logiciel a adopté une culture consistant à installer des dizaines, voire des centaines, de bibliothèques externes dans presque tous les projets. Les frameworks modernes reposent souvent sur des milliers de dépendances transitives, ce qui signifie qu'une seule application peut finalement dépendre de code maintenu par des centaines de contributeurs inconnus.

Si cet écosystème a considérablement accéléré le développement logiciel, il a également introduit une nouvelle catégorie de risques : la chaîne d'approvisionnement logicielle (Software Supply Chain).

Le Mouvement 0deps naît d'une question simple :

Et si une application ne dépendait que du code qu'elle contrôle réellement ?

Le problème des dépendances

Chaque dépendance augmente la surface d'attaque.

Elle peut :

Introduire des vulnérabilités de sécurité.
Être la cible d'une attaque de la chaîne d'approvisionnement.
Être abandonnée.
Modifier son API publique.
Supprimer des fonctionnalités.
Rompre la rétrocompatibilité.
Ajouter de nouvelles dépendances transitives.
Publier des versions incompatibles.

En pratique, les développeurs perdent le contrôle d'une partie importante du code exécuté en production.

Plus l'arbre des dépendances est grand, plus la surface d'attaque potentielle est importante.

La proposition

Dans le modèle 0deps, toutes les dépendances nécessaires sont intégrées directement au dépôt du projet.

Les dépendances ne sont plus téléchargées dynamiquement par les gestionnaires de paquets lors de l'installation ou de la compilation.

Tout ce qui est nécessaire pour construire et exécuter l'application est déjà présent dans le dépôt dès son clonage.

Cela apporte plusieurs avantages majeurs :

Des compilations reproductibles.
Une dépendance réduite aux registres de paquets externes.
Un audit de sécurité centralisé.
Une meilleure prévisibilité.
Une réduction de la surface d'attaque de la chaîne d'approvisionnement.

Des contrats publics immuables

Le principe fondamental de 0deps n'est pas de figer les implémentations.

Les implémentations évoluent.

Les algorithmes évoluent.

Les correctifs de sécurité évoluent.

Ce qui reste stable, c'est le contrat public.

Chaque bibliothèque expose une interface publique soigneusement conçue.

Par exemple :

authenticate()

createSession()

verifyPasskey()

sendMagicLink()

Ces fonctions définissent un contrat.

Ce contrat ne change jamais.

L'implémentation sous-jacente peut être entièrement réécrite.

Les algorithmes peuvent évoluer.

Les bibliothèques internes peuvent être remplacées.

Les protocoles peuvent évoluer.

Les structures de données peuvent être repensées.

Aucun de ces changements internes n'affecte la manière dont le reste de l'application utilise la bibliothèque.

Des mises à jour de sécurité sans casser les applications

Lorsqu'une vulnérabilité est découverte, deux préoccupations apparaissent généralement :

Corriger la vulnérabilité.
Déterminer combien d'applications seront affectées par la mise à jour.

Dans l'architecture 0deps, cette seconde préoccupation disparaît presque entièrement.

Les mises à jour se font en interne.

L'implémentation derrière l'interface est modifiée.

L'API publique reste exactement identique.

Les applications continuent de fonctionner sans aucune modification de leur code.

Autrement dit, l'implémentation évolue tandis que le contrat demeure stable.

Des adaptateurs internes

Toute intégration externe est isolée derrière un adaptateur interne.

Application

↓

Interface publique

↓

Adaptateur

↓

Implémentation

Si une bibliothèque externe devient obsolète ou disparaît demain, seul l'adaptateur devra être modifié.

Aucune autre partie de l'application ne sera impactée.

Cette isolation réduit considérablement l'impact des évolutions technologiques.

Un versionnement invisible

Les applications construites selon le modèle 0deps n'interagissent jamais directement avec les API des bibliothèques externes.

Elles communiquent uniquement avec des contrats internes stables.

Les versions des bibliothèques deviennent un simple détail d'implémentation.

Les mainteneurs du framework prennent en charge les mises à jour.

Les développeurs d'applications continuent d'utiliser exactement la même interface, indépendamment des changements internes.

Sécurité de la chaîne d'approvisionnement

L'objectif de 0deps n'est pas de prétendre que les logiciels deviennent invulnérables.

Son objectif est de réduire significativement les risques liés à la chaîne d'approvisionnement logicielle.

En supprimant l'installation dynamique des dépendances lors de la compilation, l'architecture réduit l'exposition à des menaces telles que :

La publication de paquets malveillants.
La compromission des registres de paquets.
Les attaques de dependency confusion.
Les paquets de typosquatting.
Les modifications inattendues des dépendances transitives.

Tout le code exécutable fait désormais partie intégrante du projet, ce qui permet un audit, un versionnement et une revue de sécurité centralisés.

Une stabilité à long terme

Le principal avantage de 0deps apparaît véritablement plusieurs années après la mise en production d'un projet.

Les projets vivent pendant des décennies.

Les bibliothèques disparaissent.

Les frameworks évoluent.

Les écosystèmes changent.

Malgré cela, les applications continuent d'utiliser exactement les mêmes contrats publics.

La responsabilité de suivre l'évolution de l'écosystème est centralisée dans les adaptateurs internes du projet plutôt que répartie entre toutes les applications qui en dépendent.

Les mises à jour potentiellement perturbatrices deviennent de simples remplacements d'implémentation.

Le Mouvement

Le Mouvement 0deps n'est pas opposé aux logiciels open source.

Bien au contraire.

Il reconnaît leur immense valeur tout en proposant un modèle de consommation différent.

Les bibliothèques ne sont plus considérées comme des dépendances installées dynamiquement.

Elles deviennent des composants intégrés au projet, audités, versionnés et encapsulés derrière des contrats publics stables.

Le résultat est un logiciel plus prévisible, plus résilient, plus facile à maintenir et significativement moins exposé aux risques de la chaîne d'approvisionnement.

Les implémentations peuvent évoluer indéfiniment.

Le contrat, lui, reste inchangé.

Et c'est précisément cette stabilité qui permet aux applications développées aujourd'hui de continuer à fonctionner exactement de la même manière pendant de nombreuses années.

Movimento 0deps: Dependências Locais, Contratos Imutáveis e Segurança por Design

suissAI — Sun, 28 Jun 2026 07:56:35 +0000

Durante anos, a indústria de software adotou uma cultura de instalar dezenas — ou até centenas — de bibliotecas externas em praticamente todos os projetos. Frameworks modernos frequentemente dependem de milhares de dependências transitivas, o que significa que uma única aplicação pode acabar dependendo de código mantido por centenas de colaboradores desconhecidos.

Embora esse ecossistema tenha acelerado o desenvolvimento de software, ele também introduziu uma nova categoria de risco: a cadeia de suprimentos de software (Software Supply Chain).

O Movimento 0deps nasce de uma pergunta simples:

E se uma aplicação dependesse apenas do código que ela realmente controla?

O problema das dependências

Toda dependência aumenta a superfície de ataque.

Ela pode:

Introduzir vulnerabilidades de segurança.
Tornar-se alvo de um ataque à cadeia de suprimentos.
Ser abandonada.
Alterar sua API pública.
Remover funcionalidades.
Quebrar compatibilidade retroativa.
Introduzir novas dependências transitivas.
Publicar versões incompatíveis.

Na prática, os desenvolvedores perdem o controle sobre uma parcela significativa do código que é executado em produção.

Quanto maior a árvore de dependências, maior a superfície potencial de ataque.

A proposta

No modelo 0deps, toda dependência necessária é incorporada diretamente ao repositório do projeto.

As dependências deixam de ser baixadas dinamicamente por gerenciadores de pacotes durante a instalação ou o processo de build.

Tudo o que é necessário para compilar e executar a aplicação já está presente no repositório desde o momento em que ele é clonado.

Isso proporciona diversos benefícios importantes:

Builds reproduzíveis.
Menor dependência de registries externos.
Auditoria de segurança centralizada.
Maior previsibilidade.
Redução da superfície de ataque da cadeia de suprimentos.

Contratos Públicos Imutáveis

O princípio central do 0deps não é tornar a implementação imutável.

Implementações evoluem.

Algoritmos evoluem.

Correções de segurança evoluem.

O que permanece estável é o contrato público.

Cada biblioteca expõe uma interface pública cuidadosamente projetada.

Por exemplo:

authenticate()

createSession()

verifyPasskey()

sendMagicLink()

Essas funções definem um contrato.

Esse contrato nunca muda.

A implementação por trás dele pode ser completamente reescrita.

Os algoritmos podem mudar.

Bibliotecas internas podem ser substituídas.

Protocolos podem evoluir.

Estruturas de dados podem ser redesenhadas.

Nenhuma dessas mudanças internas afeta a forma como o restante da aplicação utiliza a biblioteca.

Atualizações de Segurança sem Quebrar Aplicações

Sempre que uma vulnerabilidade é descoberta, normalmente existem duas preocupações:

Corrigir a vulnerabilidade.
Descobrir quantas aplicações deixarão de funcionar após a atualização.

Na arquitetura 0deps, essa segunda preocupação praticamente desaparece.

As atualizações acontecem internamente.

A implementação por trás da interface é modificada.

A API pública permanece exatamente a mesma.

As aplicações continuam funcionando sem exigir alterações de código.

Em outras palavras, a implementação evolui enquanto o contrato permanece estável.

Adaptadores Internos

Toda integração externa é isolada por meio de um adaptador interno.

Aplicação

↓

Interface Pública

↓

Adaptador

↓

Implementação

Se uma biblioteca externa deixar de existir ou for descontinuada amanhã, apenas o adaptador precisará ser alterado.

Nenhuma outra parte da aplicação será afetada.

Esse isolamento reduz drasticamente o impacto das mudanças tecnológicas ao longo do tempo.

Versionamento Invisível

Aplicações construídas sobre o modelo 0deps nunca interagem diretamente com APIs de bibliotecas externas.

Elas se comunicam exclusivamente com contratos internos estáveis.

As versões das bibliotecas tornam-se um detalhe de implementação.

Os mantenedores do framework assumem a responsabilidade pelas atualizações.

Os desenvolvedores da aplicação continuam utilizando exatamente a mesma interface, independentemente das mudanças internas.

Segurança da Cadeia de Suprimentos

O objetivo do 0deps não é afirmar que o software se torna invulnerável.

Seu objetivo é reduzir significativamente os riscos da cadeia de suprimentos de software.

Ao eliminar a instalação dinâmica de dependências durante o processo de build, a arquitetura reduz a exposição a ameaças como:

Publicação de pacotes maliciosos.
Comprometimento de registries.
Ataques de dependency confusion.
Pacotes de typosquatting.
Mudanças inesperadas em dependências transitivas.

Todo o código executado passa a fazer parte do próprio projeto, permitindo auditoria, versionamento e revisão de segurança centralizados.

Estabilidade de Longo Prazo

O maior benefício do 0deps torna-se evidente anos após o lançamento de um projeto.

Projetos duram décadas.

Bibliotecas desaparecem.

Frameworks mudam.

Ecossistemas evoluem.

Mesmo assim, as aplicações continuam interagindo exatamente com os mesmos contratos públicos.

A responsabilidade de acompanhar a evolução do ecossistema deixa de estar distribuída entre todas as aplicações e passa a ser centralizada nos adaptadores internos do projeto.

Atualizações potencialmente disruptivas tornam-se simples substituições de implementação.

O Movimento

O Movimento 0deps não é contra o software de código aberto.

Muito pelo contrário.

Ele reconhece o enorme valor do open source, mas propõe um modelo diferente de consumo.

As bibliotecas deixam de ser tratadas como dependências instaladas dinamicamente.

Em vez disso, tornam-se componentes incorporados ao projeto, auditados, versionados e encapsulados por contratos públicos estáveis.

O resultado é um software mais previsível, mais resiliente, mais fácil de manter e significativamente menos exposto aos riscos da cadeia de suprimentos.

As implementações podem evoluir indefinidamente.

O contrato permanece inalterado.

E é justamente essa estabilidade que permite que aplicações escritas hoje continuem funcionando exatamente da mesma forma muitos anos no futuro.