Seu workspace do Studio é 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: tables, bases de conhecimento e arquivos.
Um workflow é um programa visual feito de blocks. Como uma receita, é um conjunto fixo de passos que você escreve uma vez e executa muitas vezes, cada vez com uma entrada nova. Cada block faz um passo do trabalho, e as conexões definem a ordem em que os blocks executam.
Veja um exemplo 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 entrega. 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 do deploy. Para execuções que devem começar por um evento ou por um temporizador, você troca por um trigger de webhook ou de schedule, e os blocks seguintes não mudam.
No nosso exemplo, o trigger Start recebe a mensagem do cliente. Os blocks seguintes a leem pelo nome, como <start.input>.
Block
Um block é um único passo, e cada um faz uma coisa: um Agent raciocina com um modelo, uma Function executa código, um Condition ramifica, um Loop repete. Alguns blocks são determinísticos (Function, Condition); outros são guiados por modelo (Agent) e podem variar de uma execução para outra. Essa diferença é a primeira coisa a saber quando você for depurar.
Nosso exemplo tem um block Agent, configurado com um modelo e um prompt, que lê a mensagem e devolve uma classificação.
Um block não é a mesma coisa que uma ferramenta. Uma ferramenta é uma capacidade que um agente pode chamar durante um passo: enviar uma mensagem no Slack, buscar em uma base de conhecimento, executar um trecho de código. Um block Agent decide quais ferramentas chamar e quando. Os blocks são os passos do workflow; as ferramentas são as ações que um agente toma dentro de um passo.
Conexão
Uma conexão liga um block ao próximo e define a ordem de execução: o block na ponta da seta executa depois do block na origem. Depois que um block executa, os blocks seguintes podem ler a saída dele por referência.
Você lê uma saída anterior com uma tag de conexão, escrita como <blockName.field>: nomeie o block, depois o valor que você quer. O prompt do Agent lê a mensagem com <start.input>; um block posterior poderia ler a resposta do Agent com <agent.content>.
A maioria dos problemas em workflows são problemas de dados, não blocks quebrados: uma referência aponta para um valor que não existe, ou um block no caminho não executou. Veja como os blocks passam dados para entender saídas, referências e tipos.
Saída
Uma saída é o que um block produz; os blocks seguintes a leem por meio de tags de conexão. Por padrão, a saída do workflow é a saída do último block. No nosso exemplo, é o { category, urgency } do Agent. Não existe um passo de retorno separado.
Ao reutilizar, quem consome escolhe pelo nome quais saídas quer: um chat deployment, uma coluna de table ou uma chamada de API selecionam saídas de block individualmente. É a mesma ideia das tags de conexão, aplicada na borda do workflow. (Para controle preciso do HTTP, adicione um block Response.)
Tipos de blocks
Os blocks principais vêm em três tipos: blocks que fazem trabalho (Agent, Function, API), blocks que direcionam o fluxo (Condition, Router, Loop, Parallel) e blocks 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 blocks 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 exigem conta conectada: Start (manual, API ou chat), Schedule (um temporizador), Webhook (qualquer requisição HTTP recebida), RSS (um novo item de feed) e Table (uma mudança de linha em uma table do Studio). Triggers de integração disparam em um evento de um serviço conectado — um push no GitHub, um novo e-mail — e o entregam ao workflow.
Todo trigger executa o deployment ativo, então faça um novo deploy depois de mudar um workflow para que ele adote a nova versão.
Como funciona a execução
Quando um workflow executa, os blocks são executados em ordem de dependência: um block executa assim que os blocks dos quais ele depende terminam, então ramificações independentes executam em paralelo. Blocks de condição, loop e paralelo mudam o caminho que os dados percorrem.
Como os workflows executam
Ordem de execução, concorrência, ramificações e loops.
Workflows em contexto
Um workflow é onde o resto do workspace se transforma em comportamento. Por si só, tables, bases de conhecimento, arquivos e integrações são apenas recursos. Os workflows são onde eles fazem algo.
- Studio constrói e edita workflows em linguagem natural a partir do Chat.
- Tables, bases de conhecimento, arquivos e integrações alimentam um workflow com dados, memória, artefatos e ações.
- Deployments expõem um workflow como API, chat ou servidor MCP.
- Logs registram toda execução para você verificar o que aconteceu, passo a passo.
Próximos passos
Como os blocks passam dados
Saídas, referências e os tipos de dados com que você vai trabalhar.
Agent
O block mais comum: raciocinar com um modelo e chamar ferramentas.
Start
O trigger padrão — execute a partir do editor, de uma API ou do chat.
Como os workflows executam
Ordem de execução, concorrência e controle de fluxo.