Atendimento com agenda

O fluxo de empresa completo: o atendente consulta serviços e disponibilidade na API da sua operação, identifica o cliente e cria o agendamento — com base de conhecimento para o que não muda.

Atualizado em 01 de set. de 2026

Este é o fluxo que a maioria das empresas realmente precisa: um atendente que não sabe nada de cor. Preço, disponibilidade, cadastro e agendamento vêm todos do sistema, na hora — e a conversa acontece no canal onde o cliente já está.

É um agent real de produção, com o negócio trocado por um fictício. As sete rotas, o desenho do prompt e a divisão entre RAG e API são os originais.

A divisão que faz o agente parar de alucinar

Base de conhecimento para o que não muda (região atendida, como o serviço funciona, política). Webhook para o que muda a cada minuto (preço, disponibilidade, cadastro, agendamento). O prompt diz isso explicitamente — e é por isso que o agente não inventa preço.

Baixar Atendimento com agendabooking-desk.hinow-agent.json · 16.2 KB

Como importar

Na plataforma: Agents → Importar, escolha o arquivo baixado. Ele entra como um rascunho novo (nada existente é alterado), com ids de observabilidade renovados. Depois preencha o que é do seu ambiente — credenciais, URLs e bases de conhecimento — e publique.

O arquivo

O arquivo completo tem as sete rotas. Aqui está a estrutura e duas delas — uma de leitura com query string e uma de escrita com corpo:

booking-desk.hinow-agent.json (trecho)json

{
  "format": "hinow.agent",
  "version": 1,
  "agent": {
    "name": "Atendimento com agenda",
    "system_prompt": "Você é o atendente da Clínica Movimento … (o prompt inteiro está no arquivo)",
    "workflow": {
      "nodes": [
        { "id": "start",   "type": "start", "data": { "label": "Início", "variables": [] } },
        { "id": "agent-1", "type": "agent", "data": { "name": "atendente", "model": "hinow/himax" } },
        { "id": "rag-1",   "type": "rag_search", "data": { "label": "Base de conhecimento",
            "config": { "rag_ids": [], "top_k": 4, "min_score": 0.3 } } },
        { "id": "webhook-1", "type": "webhook", "data": { "label": "Sistema da empresa",
            "config": {
              "name": "API da agenda",
              "baseUrl": "https://api.suaempresa.com/tools",
              "timeout": 30000,
              "auth": { "type": "bearer", "token": "COLE_SEU_TOKEN_AQUI" },
              "retryOnError": true,
              "maxRetries": 2,
              "routes": [
                {
                  "name": "verificar_cliente",
                  "method": "GET",
                  "path": "/customer",
                  "queryParams": { "phone": "{{phone}}" },
                  "description": "Diz se o telefone já tem cadastro e o nome da pessoa.",
                  "whenToUse": "No início do atendimento, para saber se é cliente novo ou de volta.",
                  "responseDescription": "Se está cadastrado, o nome; e se o e-mail ainda não foi informado.",
                  "parameters": [
                    { "name": "phone", "type": "string", "required": true,
                      "description": "Telefone do cliente com código do país",
                      "howToObtain": "É o número de quem está conversando no WhatsApp",
                      "example": "5511987654321" }
                  ],
                  "enabled": true
                },
                {
                  "name": "criar_agendamento",
                  "method": "POST",
                  "path": "/booking",
                  "bodyTemplate": "{\"customerId\": \"{{customerId}}\", \"serviceId\": \"{{serviceId}}\", \"hotelId\": \"{{hotelId}}\", \"when\": \"{{when}}\"}",
                  "description": "Cria o agendamento e o coloca na fila do sistema.",
                  "whenToUse": "Só quando já souber: quem é o cliente, qual serviço, em qual local e quando.",
                  "responseDescription": "O número do pedido e o valor.",
                  "parameters": [
                    { "name": "customerId", "type": "string", "required": true,
                      "description": "Id do cliente no sistema",
                      "howToObtain": "Vem de verificar_cliente", "example": "6" }
                  ],
                  "enabled": true
                }
                /* consultar_servicos · consultar_locais · verificar_disponibilidade
                   solicitar_codigo · confirmar_codigo — no arquivo */
              ]
            } } },
        { "id": "end-1", "type": "end", "data": { "label": "Fim" } }
      ],
      "edges": [
        { "source": "start",     "target": "agent-1" },
        { "source": "rag-1",     "target": "agent-1", "targetHandle": "slot-1" },
        { "source": "webhook-1", "target": "agent-1", "targetHandle": "slot-2", "sourceHandle": "tool" },
        { "source": "agent-1",   "target": "end-1" }
      ]
    }
  }
}

Card a card

Card	Por que está aqui	O que faz
Agent `atendente`	Um só agente, muitas ferramentas.	Não precisa de roteador: o próprio modelo escolhe entre as sete rotas e a base. O prompt lista as ferramentas e diz quando usar cada uma.
Conhecimento (RAG)	O que não muda.	Região atendida, tipos de local, como o serviço funciona. `top_k: 4` e `min_score: 0.3` — pouco e relevante, para não inflar o contexto.
Webhook (7 rotas)	O que só o seu sistema sabe.	Cada rota vira uma tool: consultar serviços, consultar locais, verificar cliente, verificar disponibilidade, solicitar código, confirmar código, criar agendamento.

As sete rotas, e por que cada uma existe

Rota	Método	Papel no atendimento
`consultar_servicos`	GET	Preço e duração saem do sistema, nunca da memória do modelo. É a rota que impede o erro mais caro.
`consultar_locais`	GET	Devolve os ids dos locais. O agente não pode adivinhar um id — e o agendamento exige um.
`verificar_cliente`	GET + query	Logo no começo: cliente conhecido é cumprimentado pelo nome; novo é cadastrado sem burocracia.
`verificar_disponibilidade`	GET + query	Antes de falar de horário. É o que sustenta a honestidade do "pode levar até 30 minutos".
`solicitar_codigo`	POST	Quando a pessoa diz que já é cliente mas o canal não é reconhecido: código de 6 dígitos por e-mail.
`confirmar_codigo`	POST	Liga o canal à conta em definitivo — e o `whenToUse` diz para nunca mais pedir depois disso.
`criar_agendamento`	POST + body	A ação de verdade. Dez parâmetros, e o `whenToUse` lista as quatro coisas que precisam estar sabidas antes.

O encadeamento sem `dependsOn`

As rotas dependem umas das outras — criar_agendamento precisa do customerId que vem de verificar_cliente, e do serviceId que vem de consultar_servicos. Como o runtime ainda não usa o campo dependsOn, a ordem é ensinada em texto, no lugar em que o modelo lê:

{ "name": "customerId", "howToObtain": "Vem de verificar_cliente", "example": "6" }

É simples e funciona melhor do que parece: o howToObtain entra na descrição do parâmetro, e o modelo aprende a buscar o dado antes de tentar a escrita.

Como adaptar ao seu caso

Troque a baseUrl pela da sua API e cole o token em auth.token (ele sai mascarado no arquivo, de propósito).
Reescreva as rotas com os caminhos e parâmetros do seu sistema — mantendo o padrão: description curta, whenToUse como regra, howToObtain apontando a rota anterior.
Aponte a base de conhecimento para a sua (o rag_ids vem vazio: bases não atravessam ambientes).
Reescreva o prompt com o nome e o tom da sua empresa — a estrutura (como fala / o que nunca faz / de onde vêm as informações / como conduzir) vale para qualquer operação.
Publique e teste no sandbox antes de ligar o canal real.

A referência completa do card

Regras de substituição de {{parâmetros}}, autenticação, erros e o que o modelo vê de cada rota estão na página do Webhook.

Todos os fluxos prontos

Outros agents completos para importar e adaptar.

Voltar à galeria Cards do builder

Esta página foi útil?

O arquivo

Card a card

As sete rotas, e por que cada uma existe

O encadeamento sem dependsOn

Como adaptar ao seu caso

O encadeamento sem `dependsOn`