Depois de estruturar o CORE e começar a entender melhor o ON, apareceu uma constatação bastante simples.

Podemos compreender perfeitamente um problema.

• Encontrar as relações.
• Recuperar a memória.
• Consultar documentos.
• Convocar agentes.
• Levantar hipóteses.
• Questionar premissas.
• Chegar a uma ótima conclusão.

E...

nada acontecer.

Isso acontece muito.

Com empresas.

Com projetos.

Comigo.

Talvez principalmente comigo.

E foi aí que o FLOW começou a ganhar outro significado.

01No começo, FLOW parecia automação

Isso era natural.

Eu já trabalhava com automações.

• APIs.
• Webhooks.
• n8n.
• Integrações.
• Formulários.
• CRM.
• E-mail.
• Banco.
• IA.

Então fluxo significava algo parecido com:

• gatilho
• ação
• condição
• outra ação

Continua significando isso em alguns contextos.

Mas começou a ficar pequeno demais.

Porque eu percebi que estava confundindo workflow com fluxo.

Workflow é uma maneira de executar.

FLOW precisava representar uma ideia mais ampla:

algo estava em um estado e alguma coisa fez esse estado mudar.

02Isso parece quase banal

• Uma oportunidade vira venda.
• Um lead vira cliente.
• Uma ideia vira projeto.
• Um projeto vira produto.
• Uma hipótese vira decisão.
• Um documento vira aprovado.
• Uma tarefa vira concluída.
• Uma pessoa muda de função.
• Uma meta sai de saudável para risco.

O sistema inteiro está cheio dessas transições.

• ESTADO A
• EVENTO
• TRANSFORMAÇÃO
• ESTADO B

FLOW começou a morar exatamente aí.

No movimento.

03Foi quando a imagem da onda voltou

Eu gosto dessa imagem.

Já falei dela algumas vezes porque ela realmente me ajudou a pensar o sistema.

Imagine o grafo.

Uma entidade muda.

Essa mudança toca suas relações.

Algumas absorvem o impacto.

Outras propagam.

Uma vibração.

Uma onda atravessando relações.

Não tem misticismo necessário aqui.

É propagação de estado, dependência e consequência.

Mas visualmente...

é lindo.

E combina demais com aquilo que eu queria que o FLOW fosse.

04Porque uma mudança raramente termina onde começou

Um cliente cancela.

Isso é um evento comercial?

Talvez.

Mas pode tocar:

• financeiro;
• meta;
• forecast;
• projeto;
• alocação;
• operação;
• CS;
• marketing;
• produto.

Se o cliente estava relacionado a uma meta importante, o impacto aumenta.

Se era um contrato pequeno, talvez a onda morra rápido.

Se representava 25% da receita, ela atravessa a organização.

O evento é o mesmo tipo.

Essa ideia começou a me fascinar.

05FLOW não precisava apenas executar ações

Ele precisava entender transições permitidas.

Uma proposta não deveria simplesmente receber qualquer status.

Existe uma trajetória possível.

Cada transição pode possuir:

• regra;
• responsável;
• permissão;
• evento;
• automação;
• aprovação;
• efeito.

Agora o fluxo começa a ser parte do DNA da entidade.

06Isso também resolve um problema que sempre me incomodou em sistemas

Botões que aparecem porque alguém programou.

Aprovar

• Por que posso aprovar?
• Quem pode?
• Em qual estado?
• O que acontece depois?
• Pode desfazer?
• Precisa justificar?
• Existe documento obrigatório?
• Qual workflow será iniciado?

Eu queria que uma ação tivesse significado estrutural.

• AÇÃO
• permitida_porREGRA
• alteraESTADO
• geraEVENTO
• pode_dispararWORKFLOW
• deixaHISTÓRICO

Isso é muito mais interessante que um onClick.

07E aí FLOW encontrou OS

Essa separação ficou importante.

FLOW representa movimento.

OS organiza como determinadas execuções acontecem.

Imagine:

Venda aprovada.

FLOW reconhece a transição.

Um workflow do OS pode então executar:

• validar dados;
• gerar contrato;
• solicitar assinatura;
• criar projeto;
• preparar onboarding;
• notificar responsáveis.

FLOW é o movimento da realidade.

Workflow é uma estrutura de execução utilizada para produzir ou responder àquele movimento.

Essa distinção resolveu bastante coisa para mim.

08E ON entra antes, durante ou depois

Uma mudança pode exigir interpretação.

• EVENTO
• ONanalisa contexto
• FLOWdefine movimento
• OSexecuta workflow
• COREpreserva novo estado

Só que isso não precisa ser sempre linear.

Às vezes FLOW executa automaticamente.

Às vezes ON investiga primeiro.

Às vezes um humano decide.

Às vezes um workflow chama ON no meio.

O importante não era criar uma esteira rígida.

Era saber qual responsabilidade pertence a qual camada.

09E o humano continua no fluxo

Isso é fundamental.

Eu não quero desenhar FLOW como:

• IA
• IA
• IA
• IA
• resultado

Pode existir.

Mas não como regra universal.

Talvez seja:

• EVENTO
• AGENTEanalisa
• HUMANOdecide
• WORKFLOWexecuta
• AGENTEvalida
• HUMANOrecebe resultado

Ou:

• EVENTO
• REGRAconhecida
• EXECUÇÃOautomática

O nível de autonomia depende do risco.

10Foi aí que comecei a pensar em autonomia por ação

Não por agente.

Isso faz muita diferença.

Dizer:

Este agente é autônomo.

é amplo demais.

Autônomo para quê?

• Ler?
• Pesquisar?
• Criar rascunho?
• Alterar cadastro?
• Enviar mensagem?
• Publicar?
• Cancelar contrato?
• Movimentar dinheiro?

São coisas completamente diferentes.

Então a pergunta melhor é:

Esta ação, neste contexto, pode ser executada sem aprovação?

Isso permite uma arquitetura muito mais granular.

11E risco pode entrar na equação

Imagine quatro ações.

Não preciso tratar todas da mesma maneira.

Isso também pode mudar por organização.

Uma empresa pode permitir publicação automática.

Outra exige aprovação.

Uma pode permitir desconto até determinado limite.

Acima disso, precisa de responsável.

O FLOW começa a carregar política.

12E então apareceram os gates

Eu gosto bastante desse conceito.

O fluxo anda.

Até encontrar um ponto onde alguma condição precisa ser satisfeita.

• GERAR PROPOSTA
• VALIDAR MARGEM
• [ GATE ]margem >= limite?

Agora automação e governança deixam de ser inimigas.

Eu posso automatizar muito sem retirar controle onde ele realmente importa.

13Isso começou a conversar diretamente com departamentos

Porque processos reais atravessam áreas.

Uma venda não termina no Comercial.

Ela atravessa:

• venda
• Comercial
• →
• Jurídico
• →
• Financeiro
• →
• Operação
• →
• Cliente

Uma contratação:

• contratação
• RH
• →
• Gestor
• →
• Administrativo
• →
• Tecnologia
• →
• Financeiro

Uma campanha:

• campanha
• Estratégia
• →
• Marketing
• →
• Studio
• →
• Aprovação
• →
• Distribuição
• →
• Analytics

Se eu modelar tudo por departamento, essas passagens ficam escondidas.

FLOW mostra o caminho transversal.

14Talvez esse seja um dos maiores problemas das empresas

Essa frase começou a fazer muito sentido para mim.

O cliente não quer saber em qual departamento o pedido está.

Ele quer que aconteça.

FLOW olha para a travessia.

15E isso mudou minha visão de gargalo

Gargalo não é necessariamente:

João está demorando.

Pode ser uma relação ruim entre etapas.

• Informação chega incompleta.
• Aprovação não tem SLA.
• Duas áreas mantêm versões diferentes.
• Existe retrabalho.
• O sistema pede os mesmos dados três vezes.
• Uma decisão não tem responsável.
• Um documento fica esperando sem ninguém perceber.

Esses problemas aparecem quando observamos o movimento, não apenas as entidades.

Foi aí que Toyoda e outros agentes ligados a processo começaram a ganhar uma função muito mais interessante.

Não porque tenham respostas mágicas.

Mas porque podem observar a estrutura do fluxo.

16E o histórico de eventos permite medir o fluxo

Agora temos algo concreto.

Se preservamos transições:

• Lead criado09:10
• Qualificado11:32
• Proposta enviada+2 dias
• Negociação+5 dias
• Venda+13 dias

Podemos começar a perguntar:

• Onde espera?
• Onde volta?
• Onde morre?
• Qual etapa varia mais?
• Qual depende de quê?
• Que tipo de cliente percorre outro caminho?

Agora o FLOW não é só desenho.

Ele pode ser observado.

17E talvez até aprendido

Se milhares de execuções deixam rastros, começamos a comparar trajetórias.

O caminho projetado era um.

Mas a realidade mostra outro.

Tem retrabalho.

Tem perda.

Ou clientes excelentes pulam uma etapa inteira.

Talvez C nem seja necessário em determinados contextos.

O sistema começa a confrontar processo desenhado com processo vivido.

Isso é muito poderoso.

18E ON pode perguntar por quê

• FLOW mostraExiste retrabalho aqui.
• ON investigaO que diferencia os casos em que isso acontece?
• LAB aprofundaPrecisamos pesquisar uma solução que ainda não temos.
• OS implementaNovo workflow.
• CORE registraNova estrutura e relações.

Percebe como as partes começam a formar um ciclo?

• COREestrutura
• FLOWmovimenta
• ONinterpreta
• LABinvestiga lacunas
• OSconstrói
• COREincorpora

Isso começou a parecer menos uma suíte de produtos.

E mais um organismo operacional.

19Mas eu tomo cuidado com essa metáfora

Porque software não está vivo.

Não quero fingir consciência onde não existe.

Quando digo organismo, estou falando da arquitetura:

• partes especializadas;
• troca de sinais;
• memória;
• resposta a eventos;
• adaptação de estrutura.

É uma metáfora funcional.

E me ajuda a pensar.

20FLOW também começou a entrar no ME

Isso foi inevitável.

Porque eu também tenho fluxos.

• Ideia.
• Decisão.
• Projeto.
• Execução.
• Abandono.
• Retomada.
• Hábitos.
• Rotinas.
• Aprendizado.

Mas aqui eu quero ainda mais cuidado.

Não quero transformar uma pessoa numa linha de produção.

Porém algumas perguntas continuam úteis.

• Onde estou travando?
• O que sempre interrompe este tipo de projeto?
• Quanto tempo fico entre decidir e começar?
• Quais coisas começo com entusiasmo e abandono depois?

Essa última...

melhor o sistema não analisar profundamente ainda.

Eu tenho medo da resposta.

21E o Panteon de 260 personagens provavelmente apareceria no relatório

Algo como:

Identificamos tendência de expansão lateral durante períodos de alta excitação criativa.

Obrigado, archēON.

Foram criados aproximadamente 260 agentes antes da conclusão de determinadas prioridades estruturais.

Eu sei.

Deseja investigar esse padrão?

Não.

Talvez amanhã.

Essa é exatamente a relação que eu quero com o sistema.

Não uma máquina me julgando.

Uma estrutura me mostrando padrões que eu mesmo produzi.

22E isso volta ao observador

FLOW não deveria decidir o que significa progresso.

O objetivo define direção.

O observador continua podendo mudar o objetivo.

• ONpode apontar incoerência.
• COREpreserva contexto.
• OSexecuta.

Mas a pergunta:

É para lá que queremos ir?

continua sendo humana em muitos contextos.

Isso é importante.

23E foi aí que FLOW deixou de significar velocidade

Começou a significar movimento com contexto.

Isso é diferente.

• Nem todo movimento é progresso.
• Nem toda pausa é problema.
• Nem todo desvio é erro.
• Nem toda automação é melhoria.

FLOW precisa conhecer:

• origem;
• destino;
• estado;
• regra;
• objetivo;
• dependência;
• autoridade;
• histórico.

Só então o movimento começa a ter significado.

24E essa talvez seja a parte que eu mais gosto visualmente na archē

Eu imagino o sistema parado.

Um grafo.

Uma mudança acontece.

Uma pequena onda nasce.

Algumas relações acendem.

Outras permanecem quietas.

Um agente percebe.

Outra entidade muda.

Um workflow começa.

Uma aprovação aparece.

A onda continua.

Até encontrar um novo equilíbrio.

Depois outra coisa acontece.

Outra onda.

imagem pendente placa · flow-onda captura de tela · largura total · proporção 16:10

Não porque existe alguma energia misteriosa dentro do banco de dados.

Mas porque organizações são sistemas de relações em transformação constante.

E eu queria uma interface capaz de mostrar isso acontecendo.

Não apenas tabelas atualizadas.

• Movimento.
• Causa.
• Consequência.
• Contexto.

25Só que existe um problema

Quanto mais FLOW consegue executar...

mais precisamos saber exatamente o que está executando.

• Qual workflow.
• Qual skill.
• Qual agente.
• Qual versão.
• Qual dependência.
• Qual projeto.
• Qual produto.
• Qual regra.
• Qual código.
• Quem mantém.
• Quem aprovou.
• Quando mudou.

Porque, se o CORE organiza a realidade da empresa e o FLOW começa a movimentá-la, a máquina por trás disso também precisa ser organizada.

Caso contrário, construímos automações extraordinárias...

e seis meses depois ninguém sabe como funcionam.

Eu já vivi versões suficientes disso para não querer repetir.

Foi aí que a arquitetura operacional deixou de ser bastidor.

Ela ganhou identidade própria.

E o archēOS começou a fazer sentido de verdade.

---

Esta série acompanha as perguntas, tecnologias, erros e ideias que foram transformando a archē de uma estrutura de organização em um sistema de contexto.