Sou Jonathan Troncoso. Há mais de dez anos desenho e conduzo a arquitetura de plataformas críticas no setor financeiro — núcleo bancário, pagamentos, crédito e seguros. Trabalho na fronteira entre a decisão de negócio e a topologia técnica que a sustenta: decomposição de domínio, modernização de legado, plataforma em nuvem e, agora, engenharia orientada a agentes.
Boa parte do custo de um sistema financeiro não vem da tecnologia escolhida, mas da fronteira mal traçada entre domínios. Um limite errado se paga por anos em acoplamento, transação distribuída e mudança que ninguém consegue estimar. Meu trabalho começa antes do código: entender o negócio com profundidade suficiente para saber onde o corte dói menos.
A partir daí, tudo é decisão registrada e consequência assumida — contexto, decisão, trade-off, o que se ganha e o que se perde. Uso DDD para achar as costuras, C4 e BIAN para comunicar em linguagem que negócio e regulador entendem, e contratos explícitos para que a fronteira sobreviva ao time que a desenhou. Depois, garanto que o padrão não fique no documento: ele vira código gerado, teste e verificação automática.
Superfície de decisão
Concebi e construí uma plataforma de engenharia orientada a agentes que cobre o ciclo inteiro: um agente arquiteto lê o escopo de negócio em linguagem natural e devolve um context map DDD com bounded contexts, agregados e integrações; esse mapa vira spec rígida e contract-first; agentes geradores materializam o microsserviço completo — Clean Architecture, vertical slice, camadas de domínio, aplicação, dados e borda, ACL sobre o legado, mensageria com outbox, retry e DLQ; e uma camada de governança valida conformidade arquitetural, contratos e containerização antes de qualquer merge. O que antes dependia da disciplina individual de cada squad virou propriedade executável da plataforma.
Portfólio com dezenas de serviços, times distribuídos e um padrão arquitetural que existia como documento, não como restrição. Cada novo serviço reabria as mesmas discussões e cada squad interpretava o padrão de um jeito. O custo não estava em escrever código: estava em revisar, corrigir e reconciliar divergência estrutural depois que já era tarde.
Codificar o padrão como agentes especializados e determinísticos em vez de treinamento e revisão manual. Decomposição de domínio, síntese de spec, geração de serviço e verificação de conformidade viraram etapas executáveis, versionadas e parametrizáveis por stack — .NET, Java/Spring e Node — com o mesmo modelo arquitetural em todas.
O tempo entre escopo aprovado e serviço rodando com testes, container e pipeline caiu de semanas para horas, e a revisão de arquitetura deixou de ser arqueologia para virar leitura de decisão. Em troca, a plataforma passa a ser um ativo com dono: os agentes precisam evoluir junto com o padrão, e desvio deliberado exige ADR explícito — o que é, na prática, o comportamento desejado.
Clientes e marcas omitidos por acordo. O que interessa aqui não é o logotipo: é a restrição que existia antes, a decisão estrutural que a resolveu e o que essa decisão custou em troca.
O Agent Room não é um produto separado: é a superfície do Arsenale Agentico que mostra como os agentes estão se comportando enquanto executam. Cada agente especializado — decomposição de domínio, síntese de spec, geração de serviço, verificação de conformidade — aparece com o que leu, o que decidiu, em que etapa está e onde travou. O ciclo descrito na seção anterior deixa de ser inferido pelo resultado e passa a ser observado em curso.
Pipeline de agentes é caixa-preta por natureza: você entrega um escopo e recebe um serviço, sem enxergar o meio. Quando a geração diverge do padrão, não dá para saber em qual etapa a interpretação escorregou — e, sem isso, o diagnóstico vira tentativa e erro sobre o resultado final.
O comportamento de cada agente em execução: entrada consumida, decisão tomada, etapa corrente e ponto de parada. Isso torna comparável uma execução com a outra e localiza a etapa exata em que o padrão arquitetural deixou de ser respeitado — que é a informação necessária para corrigir o agente, não o código gerado.
Dois protótipos navegáveis desenhados para decidir arquitetura antes de contratar desenvolvimento. O primeiro percorre a jornada do hóspede de ponta a ponta — pré-check-in em casa com validação documental, placa liberada na cancela, transfer rastreado, chave digital no celular, consumo cashless por pulseira com limite configurável, extrato aberto com contestação, reserva de quadra e checkout expresso por carteira digital. O segundo é o outro lado do mesmo domínio: um único aplicativo que assume seis perfis operacionais — portaria, central de alertas, manutenção, governança, segurança e gerência — servindo a cada crachá apenas a visão que aquele papel precisa, sob menor privilégio.
Em hospitalidade de grande porte a fila de check-in, a contestação de conta e o chamado que não chega ao setor certo são o mesmo problema visto de ângulos diferentes: identidade do hóspede, saldo e ocorrência viviam em sistemas que não conversavam. Discutir isso em slide não converge — a decisão precisava ser vista antes de ser paga.
Fixa as fronteiras do domínio antes da primeira linha de produção: hóspede, estadia, consumo, ocorrência e acesso como contextos próprios, com o app operacional consumindo os mesmos contratos que a jornada do hóspede publica. O protótipo navegável vira o artefato de alinhamento — patrocinador, operação e segurança discutem sobre a mesma tela, não sobre a mesma suposição.
Desenho de solução ponta a ponta para núcleo bancário, pagamentos, crédito, cobrança e seguros: capacidades de negócio mapeadas em domínios, jornadas críticas modeladas, integração com o ecossistema regulado e blueprint C4 que sobrevive à auditoria e ao comitê.
Saída do monólito sem parar o negócio: strangler fig com fronteiras negociadas, anti-corruption layer sobre o núcleo antigo, decomposição por bounded context, contratos versionados e estratégia de dados para conviver com a fonte de verdade durante a transição.
Fundação AWS pensada para carga transacional regulada: landing zone e segregação de contas, malha de rede e postura de segurança, resiliência multi-AZ com objetivo de recuperação declarado, observabilidade acionável e disciplina de custo tratada como requisito de arquitetura, não como relatório mensal.
Data lake e arquitetura de streaming para domínios de alto volume, com linhagem, qualidade e governança tratadas desde o desenho — e a aplicação de agentes de IA onde ela realmente compõe: decomposição de domínio, geração de serviço sob padrão e verificação contínua de conformidade arquitetural.
Leitura do estado atual, mapa de domínios e acoplamentos, riscos estruturais ordenados por custo de permanência e um roadmap de modernização com sequência defensável. Entrego o que está de pé, o que vai quebrar e em que ordem mexer.
Atuação dentro do programa: desenho da solução, condução técnica dos times, negociação de fronteira entre squads e áreas, revisão de design, ADRs e a responsabilidade de manter a coerência do conjunto enquanto o escopo se move.
Implantação da abordagem agêntica no seu contexto: padrão arquitetural codificado, geradores parametrizados para a sua stack, verificação de conformidade no pipeline e transferência de propriedade para o time interno — com a plataforma rodando, não em slides.
Trabalhei majoritariamente em ambientes onde indisponibilidade tem nome, valor e prazo regulatório. Os projetos variam, o denominador comum não: volume transacional alto, integração com sistemas que ninguém pode desligar e um regulador do outro lado da mesa.
DDD · C4 Model · BIAN · ADR · Event Storming · Clean Architecture · Vertical Slice · Hexagonal · CQRS · Saga · Outbox
AWS · EKS · ECS · Lambda · API Gateway · EventBridge · SQS · SNS · Aurora · DynamoDB · S3 · Terraform
Kubernetes · Docker · Kafka · RabbitMQ · Redis · PostgreSQL · OpenTelemetry · Prometheus · Grafana · GitOps
.NET · Java · Spring · Node · TypeScript · Python · OpenAPI · gRPC · contract testing · fitness functions · agentic codegen
Descreva o contexto em três parágrafos — o sistema, a restrição e o prazo. Respondo com uma leitura inicial e o formato de trabalho que faz sentido, sem proposta genérica. E-mail ou WhatsApp, o que for mais direto para você.
contato@jtroncoso.dev