Seu workspace Zoen é onde seus sistemas de IA vivem. Um sistema é feito de duas coisas. Workflows são os procedimentos que ele executa. Recursos são os dados com os quais esses procedimentos trabalham: tabelas, bases de conhecimento e arquivos.
Um workflow é um programa visual feito de blocos. Como uma receita, é um conjunto fixo de passos que você escreve uma vez e executa de novo e de novo, cada vez com uma entrada nova. Cada bloco faz um passo do trabalho, e as conexões definem a ordem em que os blocos rodam.
Aqui está um simples. Ele recebe uma mensagem de cliente, classifica a categoria e a urgência, e devolve o resultado:
As partes de um workflow
Trigger
Um trigger é onde um workflow começa e o que ele recebe de entrada. Todo workflow tem exatamente um. O trigger Start recebe a entrada diretamente — do editor enquanto você constrói, e de uma chamada de API ou de um chat depois de publicado. Para execuções que devem começar em um evento ou em um timer, você troca por um trigger de webhook ou schedule, e os blocos seguintes não mudam.
No nosso exemplo, o trigger Start recebe a mensagem do cliente. Blocos posteriores a leem pelo nome, como <start.input>.
Bloco
Um bloco é um único passo, e cada um faz uma coisa: um Agent raciocina com um modelo, um Function executa código, um Condition faz branching, um Loop repete. Alguns blocos são determinísticos (Function, Condition); outros são orientados por modelo (Agent) e podem variar de uma execução para outra. Essa diferença é a primeira coisa a saber na hora de depurar.
Nosso exemplo tem um bloco Agent, configurado com um modelo e um prompt, que lê a mensagem e devolve uma classificação.
Um bloco não é a mesma coisa que uma ferramenta. Uma ferramenta (tool) é uma capacidade que um agente pode chamar durante um passo: enviar uma mensagem no Slack, buscar em uma base de conhecimento, rodar um trecho de código. Um bloco Agent decide quais ferramentas chamar e quando. Blocos são os passos do workflow; ferramentas são as ações que um agente toma dentro de um passo.
Conexão
Uma conexão liga um bloco ao próximo e define a ordem de execução: o bloco na ponta da seta roda depois do que está na origem. Depois que um bloco rodou, os blocos seguintes podem ler sua saída por referência.
Você lê uma saída anterior com uma tag de conexão, escrita <blockName.field>: nomeie o bloco e depois o valor que quer. O prompt do Agent lê a mensagem com <start.input>; um bloco posterior poderia ler a resposta do Agent com <agent.content>.
A maioria dos problemas em workflows são problemas de dados, não de blocos que quebraram: uma referência aponta para um valor que não está lá, ou um bloco no caminho não rodou. Veja como os blocos passam dados para saídas, referências e tipos.
Saída
Uma saída (output) é o que um bloco produz; blocos posteriores a leem por tags de conexão. Por padrão, a saída do workflow é a saída do último bloco. No nosso exemplo, isso é o { category, urgency } do Agent. Não há um passo de return separado.
Na reutilização, o consumidor escolhe quais saídas quer pelo nome: um deployment de chat, uma coluna de tabela ou uma chamada de API selecionam saídas de bloco individualmente. É a mesma ideia das tags de conexão, aplicada na borda do workflow. (Para controle HTTP preciso, adicione um bloco Response.)
Tipos de blocos
Os blocos principais vêm em três tipos: blocos que fazem o trabalho (Agent, Function, API), blocos que direcionam o fluxo (Condition, Router, Loop, Parallel) e blocos que moldam a execução (Response, Guardrails, Wait e outros).
Duas famílias maiores fazem trabalhos mais específicos:
- Integrações conectam a um serviço externo — Gmail, Slack, Notion, um banco de dados — com centenas disponíveis. Um agente também pode chamá-las como ferramentas.
- Triggers são os blocos que iniciam um workflow.
Como um workflow começa
Um trigger decide o que inicia a execução e qual entrada ela recebe. Triggers nativos não precisam de conta conectada: Start (manual, API ou chat), Schedule (um timer), Webhook (qualquer requisição HTTP de entrada), RSS (um novo item de feed) e Table (uma mudança de linha em uma tabela Zoen). Triggers de integração disparam em um evento de um serviço conectado — um push no GitHub, um e-mail novo — e passam isso para o workflow.
Todo trigger executa o deployment ativo, então publique de novo depois de alterar um workflow para ele pegar a nova versão.
Como ele roda
Quando um workflow roda, os blocos executam em ordem de dependência: um bloco roda assim que os blocos dos quais depende terminaram, então ramos independentes rodam em paralelo. Conditions, loops e blocos parallel mudam o caminho que os dados tomam.
Como workflows rodam
Ordem de execução, concorrência, ramos e loops.
Workflows em contexto
Um workflow é onde o resto do workspace vira comportamento. Sozinhas, tabelas, bases de conhecimento, arquivos e integrações são só recursos. Workflows são onde eles fazem alguma coisa.
- Mothership cria e edita workflows em linguagem natural.
- Tabelas, bases de conhecimento, arquivos e integrações alimentam dados, memória, artefatos e ações em um workflow.
- Deployments expõem um workflow como API, chat ou servidor MCP.
- Logs registram cada execução para você verificar o que aconteceu, passo a passo.
Próximos passos
Como os blocos passam dados
Saídas, referências e os tipos de dados com os quais você vai trabalhar.
Agent
O bloco mais comum: raciocinar com um modelo e chamar ferramentas.
Start
O trigger padrão — rode pelo editor, por uma API ou por chat.
Como workflows rodam
Ordem de execução, concorrência e fluxo de controle.