Flows, Prompt Management e Intelligent Routing

Flows (GA em nov/2024, ex-"Prompt Flows") é um builder drag-and-drop que encadeia prompts, Knowledge Bases, Agents, funções Lambda, condicionais e iteradores num fluxo determinístico de GenAI. Você desenha o grafo; a ordem dos passos é sua, não do modelo. O exemplo abaixo é um fluxo de triagem de suporte: resume o chamado, decide por uma condição se é urgente e, se for, consulta a base de runbooks antes de responder.

• Prompts do Prompt Management (versionados) e nós de inferência direta a um modelo.
• Knowledge Bases, para embutir RAG dentro do fluxo.
• Agents do Bedrock, quando um passo específico precisa de autonomia.
• Funções Lambda, para lógica ou integração custom (chamar uma API, transformar dados).
• Nós de Condição (branches por regra) e Iteradores (loop sobre uma lista) para controle de fluxo.
• Guardrails aplicados a nós, filtrando entrada e saída dentro do próprio Flow.

Prompt Management (GA em nov/2024) deixa você criar, testar, versionar e compartilhar prompts como recursos da conta AWS. Ele existe para matar um antipadrão específico: o prompt hardcoded numa f-string espalhada pelo código, que ninguém consegue revisar, comparar ou trocar sem redeploy.

• Variáveis/placeholders no corpo do prompt (ex.: {{idioma}}, {{ticket}}), preenchidas em runtime.
• Versionamento imutável: cada versão é um snapshot; produção aponta para uma versão fixa.
• Comparação de versões e teste no playground antes de promover.
• Configuração de modelo e parâmetros (temperature, topP, system) presa ao próprio prompt.
• Reuso entre times na mesma conta e integração direta como nó dentro de um Flow.

import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

# modelId aponta para um Prompt versionado do Prompt Management (ARN + versao),
# NAO para um foundation model. O Bedrock resolve o prompt armazenado,
# injeta as variaveis e executa no modelo/parametros configurados no proprio prompt.
resp = bedrock.converse(
    modelId="arn:aws:bedrock:us-east-1:123456789012:prompt/PROMPT_ID:2",
    promptVariables={
        "idioma": {"text": "pt-BR"},
        "ticket": {"text": "Cliente nao consegue logar apos reset de senha."},
    },
)

print(resp["output"]["message"]["content"][0]["text"])
print("tokens:", resp["usage"])

Repare no truque: em vez do texto do prompt, você passa o ARN do prompt (com a versão :2) no lugar do modelId, e só manda as promptVariables. O modelo, o system e os parâmetros vêm presos à versão do prompt — funciona igual com InvokeModel. Promover a v3 em produção é mudar a versão apontada, sem tocar no código da aplicação.

Nem todo request precisa do modelo mais caro. Um "resuma esta frase" e um "analise este contrato de 40 páginas e aponte cláusulas de risco" têm custo de inferência muito diferente, mas na prática muita gente manda tudo para o modelo forte por segurança. O Intelligent Prompt Routing (GA em abr/2025) é um endpoint serverless único que, a cada request, prevê a qualidade que cada modelo entregaria e roteia para o melhor equilíbrio custo × qualidade — dentro da mesma família (Anthropic Claude, Meta Llama ou Amazon Nova).

• Você escolhe uma família e 2 modelos dela (ex.: Claude Haiku + Sonnet, ou Nova Micro + Pro).
• Define o critério de tolerância de qualidade (o quanto de queda você aceita para economizar).
• O router prevê, por request, a qualidade esperada de cada modelo e manda para o mais barato que atinge o critério.
• Requests 'fáceis' caem no modelo barato; os 'difíceis' sobem para o forte — sem você escrever nenhuma regra manual.

import boto3

rt = boto3.client("bedrock-runtime", region_name="us-east-1")

# O router e um recurso serverless: um "modelId" unico que decide, por request,
# entre 2 modelos da MESMA familia (ex.: Claude Haiku vs Sonnet). Voce chama
# como qualquer modelo no Converse; o roteamento e transparente.
resp = rt.converse(
    modelId="arn:aws:bedrock:us-east-1:123456789012:default-prompt-router/anthropic.claude:1",
    messages=[{
        "role": "user",
        "content": [{"text": "Resuma este contrato em 3 bullets: ..."}],
    }],
)

print(resp["output"]["message"]["content"][0]["text"])
# A resposta traz um trace indicando qual modelo o router escolheu para este request.
print("trace de roteamento:", resp.get("trace"))

Três serviços da AWS orquestram trabalho, e é fácil escolher o errado. A pergunta que separa os três é uma só: quem decide o próximo passo? O modelo, em runtime? Você, no papel, antes de rodar? Ou é uma orquestração ampla que vai muito além de GenAI?

Regra prática: se a decisão do próximo passo precisa ser tomada pelo modelo em runtime, é AgentCore. Se o fluxo de GenAI é fixo (com no máximo alguns branches), é Flows. Se a orquestração é ampla e vai além de GenAI, é Step Functions. E não é ou-um-ou-outro: é comum combinar — uma Step Functions de negócio que, num estado, invoca um Flow ou um Agent do Bedrock para a parte de GenAI.