AI Watch · Prompt engineering in practice

One job per prompt: chaining, and a reviewer that checks against something real

A single giant prompt that researches, drafts, formats and double-checks tends to skip a step quietly. Splitting the work into a chain of small prompts fixes that, but only if each link can be tested, and only if the "review" step checks against something outside the model's own opinion.

Contents

Why one big prompt drops steps
Three shapes of a chain
Handoffs: make each link's output parseable
The review step, and why "check your work" is not enough
A worked example in code
When not to chain

1. Why one big prompt drops steps

Anthropic's prompting docs put the problem in one sentence: when you handle everything in a single prompt, Claude can drop steps. Their example is a contract review: one prompt asked the model to find risks in a SaaS contract and write an email to the vendor proposing changes. The email came out, but the proposed changes were missing. Split into two prompts (find risks → draft email from those risks), each step did its one job.

Prompt chaining means the output of one prompt becomes the input of the next. Techsy's July 2026 guide calls it "decomposition made real in code": decomposition is breaking the task into steps on paper; chaining is running each step as its own call. The docs list three benefits:

Accuracy: each call has one objective, so nothing competes for attention.
Clarity: each prompt is short enough to read and reason about.
Traceability: when the final output is wrong, you can see which link broke and fix only that one.

Analogy: a restaurant kitchen. One cook doing prep, grill, plating and tasting will forget the garnish on a busy night. A line of stations, each with one job and a pass where the head chef checks the plate, does not. Chaining is building the line.

2. Three shapes of a chain

Sequential

Each step depends on the one before. Common pipelines from the docs:

Content:    Research → Outline → Draft → Edit → Format
Data:       Extract → Transform → Analyze → Visualize
Decision:   Gather info → List options → Analyze each → Recommend

Parallel (fan-out)

If subtasks do not depend on each other (summarizing five documents, say), run them at the same time and combine the results in a final call. The docs are explicit: chain sequentially only when an output depends on a previous step. Parallel calls cost the same tokens but much less waiting.

Verification loop

Generate → review → refine → review again. This is the one people get wrong most often, so it gets its own section below.

3. Handoffs: make each link's output parseable

A chain is only as good as the joints between links. If step 1 returns a friendly paragraph, step 2 has to guess where the useful part is. The docs recommend wrapping handoffs in XML tags: ask step 1 to put its findings inside <risks>, then pass exactly that block into step 2 as <concerns>…</concerns>.

When the next step is code rather than another prompt, go further and use structured outputs (a JSON schema the API enforces). Your code can then check the handoff before spending another call: is the list empty? Is a required field missing? Stop early instead of letting a bad input flow down the line.

4. The review step, and why "check your work" is not enough

Anthropic's docs show a three-prompt self-correction chain: summarize a paper → review the summary for accuracy, clarity and completeness on an A–F scale → update the summary based on that feedback. In their example, the review caught undefined acronyms and missing baseline statistics. That is useful, and cheap.

But research adds an important caveat. A Tsinghua/NTU paper, "Understanding the Dark Side of LLMs' Intrinsic Self-Correction" (arXiv, results timestamped Feb 2025), tested models like ChatGPT, Llama and DeepSeek on simple and complex tasks. When the model gets only a generic "are you sure? think again" with no outside information, it can waver: flip correct answers to wrong ones, react to the wording of the review prompt itself, and show human-like biases such as overthinking and perfectionism on open-ended work. Earlier studies the paper cites reached the same conclusion: self-correction without external feedback is unreliable.

So the useful question is not "should I add a review step?" but "what does the reviewer compare against?"

Reviewer checks against…	Reliability	Example
Nothing ("check your answer")	Low; may flip correct answers	"Are you sure? Try again."
An explicit rubric in a separate call	Medium; catches omissions and clarity issues	"Does the summary define every acronym? List any that are missing."
The source material	Good for factual drift	"Quote the sentence in <paper> that supports each number."
Something deterministic	Highest	Schema validation, unit tests, a word count, a regex, a banned-phrase list

Techsy describes the last row from its own production pipeline: a validator step greps every draft against a 52-phrase blocklist and blocks publishing on any hit; when a translation step started returning ASCII instead of accented characters, the fix was a gate that counts native characters and re-runs the step if the count is zero. That is a "review" with no opinion involved, and it never wavers.

Rule of thumb: push as much checking as possible into code. Use a model as reviewer only for things code cannot measure (tone, completeness), give it a concrete rubric, and run it in a separate call so it is not grading its own homework in the same breath.

5. A worked example in code

A generic support pipeline: classify a ticket, draft a reply, check the reply. Below, callModel stands in for any LLM API call; it is not a real library function.

1 · ExtractTicket → JSON: category, product, what the customer wants

→

Code gateValid JSON? Known category?

→

2 · DraftReply using only the extracted facts + policy

→

Code gateLength, no forbidden promises

→

3 · Rubric reviewSeparate call: does it answer the ask?

async function handleTicket(ticket, policy) {
  // Link 1: one job — extract facts. Output must match a schema.
  const facts = await callModel({
    prompt: `Read the ticket in <ticket>. Return JSON with
category (billing | technical | account), product, and request
(one sentence: what the customer wants).
<ticket>${ticket}</ticket>`,
    schema: FACTS_SCHEMA,
  });

  // Gate: deterministic check before spending another call.
  if (!["billing", "technical", "account"].includes(facts.category)) {
    return { status: "needs_human", reason: "unknown category" };
  }

  // Link 2: one job — draft, using only the handed-off facts.
  const draft = await callModel({
    prompt: `Write a reply under 120 words that addresses <request>.
Follow <policy>. Do not promise refunds or dates.
<request>${facts.request}</request>
<policy>${policy}</policy>`,
  });

  // Gate: rules code can measure.
  const words = draft.split(/\s+/).length;
  if (words > 120 || /refund|guarantee/i.test(draft)) {
    return { status: "retry_draft", draft };
  }

  // Link 3: rubric review in a separate call — compares against the request.
  const review = await callModel({
    prompt: `Does <reply> fully answer <request>? Answer PASS or FAIL,
then list anything missing.
<request>${facts.request}</request>
<reply>${draft}</reply>`,
  });

  return review.startsWith("PASS")
    ? { status: "ready", draft }
    : { status: "revise", draft, feedback: review };
}

Notice three things. Each prompt has one objective. Handoffs are wrapped in tags or schemas. And two of the three checks are plain code, which costs nothing and behaves the same every time. When something regresses, you test that one link with a handful of saved tickets instead of rereading a 60-line mega-prompt.

6. When not to chain

The task is simple. Current reasoning models already plan internally. Techsy notes that scripting reasoning steps for these models can be redundant or even hurt; OpenAI's reasoning guide says the same. A short, clear single prompt beats a five-step chain for a one-paragraph answer.
Latency matters more than polish. Every sequential link adds a full round-trip. Parallelize what you can and merge links that never fail.
You can't say what each link should output. If you can't write a test for a step, it isn't a real step yet. Rethink the split.
An agent loop fits better. A fixed chain suits a known sequence. When the path depends on what the model finds (search, read, decide), an agent with tools is the better shape. Chains and agents are cousins: a chain is a route you choose in advance.

Takeaway: split work where a step keeps getting dropped, pass clean tagged handoffs, and make every "review" compare against something real: a schema, a test, the source text, or at minimum a written rubric in a separate call.

Sources

Note: category rotation pointed to "Prompt engineering in practice"; no Anthropic/Claude announcement dated today was found (the most recent items were the Oct 14 election-information update and the Oct 15 default rollout of Docs/Slides/Design). Anthropic's chaining guidance was read through a third-party digest that links to the official page. The code example is illustrative; callModel is a placeholder.

IA Watch · Prompt engineering na prática

Um trabalho por prompt: encadeamento, e um revisor que confere contra algo concreto

Um prompt gigante que pesquisa, rascunha, formata e ainda revisa costuma pular uma etapa sem avisar. Dividir o trabalho numa cadeia de prompts pequenos resolve isso, mas só se cada elo puder ser testado, e só se a etapa de "revisão" conferir contra algo que não seja a própria opinião do modelo.

Sumário

Por que um prompt grande pula etapas
Três formatos de cadeia
Passagem de bastão: saída de cada elo precisa ser legível por máquina
A etapa de revisão, e por que "confira seu trabalho" não basta
Um exemplo em código
Quando não encadear

1. Por que um prompt grande pula etapas

A documentação de prompting da Anthropic resume o problema numa frase: quando tudo fica num único prompt, o Claude pode pular etapas. O exemplo deles é a revisão de um contrato: um prompt pedia para achar os riscos de um contrato de SaaS e escrever um e-mail ao fornecedor propondo mudanças. O e-mail saiu, mas sem as mudanças propostas. Dividido em dois prompts (achar riscos → redigir e-mail a partir desses riscos), cada etapa cumpriu sua função.

Prompt chaining (encadeamento de prompts) é quando a saída de um prompt vira a entrada do próximo. O guia da Techsy de julho de 2026 chama isso de "decomposição colocada em código": decompor é quebrar a tarefa em etapas no papel; encadear é rodar cada etapa como uma chamada separada. A documentação lista três benefícios:

Precisão: cada chamada tem um objetivo, então nada disputa a atenção do modelo.
Clareza: cada prompt é curto o bastante para ler e entender.
Rastreabilidade: quando o resultado final sai errado, dá para ver qual elo quebrou e consertar só ele.

Analogia: a cozinha de um restaurante. Um cozinheiro sozinho fazendo pré-preparo, grelha, montagem e prova vai esquecer a guarnição numa noite cheia. Uma linha de praças, cada uma com uma função e um passe onde o chef confere o prato antes de sair, não esquece. Encadear prompts é montar essa linha.

2. Três formatos de cadeia

Sequencial

Cada etapa depende da anterior. Pipelines comuns citados na documentação:

Conteúdo:   Pesquisa → Estrutura → Rascunho → Edição → Formatação
Dados:      Extrair → Transformar → Analisar → Visualizar
Decisão:    Reunir info → Listar opções → Analisar cada uma → Recomendar

Paralelo (fan-out)

Se as subtarefas não dependem umas das outras (resumir cinco documentos, por exemplo), rode todas ao mesmo tempo e combine os resultados numa chamada final. A documentação é direta: encadeie em sequência só quando uma saída depende de uma etapa anterior. Chamadas em paralelo gastam os mesmos tokens, mas muito menos tempo de espera.

Loop de verificação

Gerar → revisar → refinar → revisar de novo. É o formato que mais se faz errado, então ganhou uma seção só para ele.

3. Passagem de bastão: saída de cada elo precisa ser legível por máquina

Uma cadeia é tão boa quanto as juntas entre os elos. Se a etapa 1 devolve um parágrafo simpático, a etapa 2 precisa adivinhar onde está a parte útil. A documentação recomenda envolver as passagens em tags XML: peça para a etapa 1 colocar o resultado dentro de <risks> e passe exatamente esse bloco para a etapa 2 como <concerns>…</concerns>.

Quando a próxima etapa é código, e não outro prompt, vá além e use structured outputs (um JSON schema que a API garante). Aí seu código pode validar a passagem antes de gastar mais uma chamada: a lista veio vazia? Falta um campo obrigatório? Pare cedo em vez de deixar uma entrada ruim descer pela linha.

4. A etapa de revisão, e por que "confira seu trabalho" não basta

A documentação da Anthropic mostra uma cadeia de autocorreção com três prompts: resumir um artigo → revisar o resumo quanto a precisão, clareza e completude numa escala de A a F → atualizar o resumo com base nesse feedback. No exemplo, a revisão pegou siglas não definidas e estatísticas de base que faltavam. Isso é útil e barato.

Mas a pesquisa acrescenta uma ressalva importante. Um artigo de Tsinghua/NTU, "Understanding the Dark Side of LLMs' Intrinsic Self-Correction" (arXiv, resultados datados de fev/2025), testou modelos como ChatGPT, Llama e DeepSeek em tarefas simples e complexas. Quando o modelo recebe só um genérico "tem certeza? pense de novo", sem nenhuma informação externa, ele pode vacilar: trocar respostas certas por erradas, reagir ao próprio texto do prompt de revisão e mostrar vieses parecidos com os humanos, como pensar demais e perfeccionismo em tarefas abertas. Estudos anteriores citados pelo artigo chegaram à mesma conclusão: autocorreção sem feedback externo não é confiável.

Então a pergunta útil não é "devo colocar uma etapa de revisão?", e sim "contra o que o revisor está comparando?"

O revisor confere contra…	Confiabilidade	Exemplo
Nada ("confira sua resposta")	Baixa; pode trocar resposta certa por errada	"Tem certeza? Tente de novo."
Uma rubrica explícita, em chamada separada	Média; pega omissões e problemas de clareza	"O resumo define todas as siglas? Liste as que faltam."
O material de origem	Boa contra desvio factual	"Cite a frase em <paper> que sustenta cada número."
Algo determinístico	A mais alta	Validação de schema, testes unitários, contagem de palavras, regex, lista de termos proibidos

A Techsy descreve a última linha a partir do próprio pipeline de produção: uma etapa validadora faz grep de cada rascunho contra uma lista de 52 frases proibidas e bloqueia a publicação em qualquer ocorrência; quando a etapa de tradução começou a devolver ASCII em vez de caracteres acentuados, a correção foi um portão que conta caracteres nativos e roda a etapa de novo se a contagem der zero. É uma "revisão" sem opinião envolvida, e ela nunca vacila.

Regra prática: empurre o máximo de checagem possível para o código. Use o modelo como revisor só para o que código não mede (tom, completude), dê a ele uma rubrica concreta e rode em chamada separada, para ele não corrigir a própria prova no mesmo fôlego.

5. Um exemplo em código

Um pipeline genérico de suporte: classificar um chamado, redigir uma resposta, conferir a resposta. Abaixo, callModel representa qualquer chamada de API de LLM; não é função de nenhuma biblioteca real.

1 · ExtrairChamado → JSON: categoria, produto, o que o cliente quer

→

Portão em códigoJSON válido? Categoria conhecida?

→

2 · RedigirResposta usando só os fatos extraídos + política

→

Portão em códigoTamanho, nenhuma promessa proibida

→

3 · Revisão por rubricaChamada separada: responde ao pedido?

async function handleTicket(ticket, policy) {
  // Elo 1: um trabalho — extrair fatos. A saída precisa seguir um schema.
  const facts = await callModel({
    prompt: `Leia o chamado em <ticket>. Retorne JSON com
category (billing | technical | account), product e request
(uma frase: o que o cliente quer).
<ticket>${ticket}</ticket>`,
    schema: FACTS_SCHEMA,
  });

  // Portão: checagem determinística antes de gastar outra chamada.
  if (!["billing", "technical", "account"].includes(facts.category)) {
    return { status: "needs_human", reason: "categoria desconhecida" };
  }

  // Elo 2: um trabalho — redigir, usando só os fatos recebidos.
  const draft = await callModel({
    prompt: `Escreva uma resposta com menos de 120 palavras que atenda <request>.
Siga <policy>. Não prometa reembolso nem prazo.
<request>${facts.request}</request>
<policy>${policy}</policy>`,
  });

  // Portão: regras que o código consegue medir.
  const words = draft.split(/\s+/).length;
  if (words > 120 || /reembolso|garant/i.test(draft)) {
    return { status: "retry_draft", draft };
  }

  // Elo 3: revisão por rubrica em chamada separada — compara com o pedido.
  const review = await callModel({
    prompt: `A <reply> responde totalmente a <request>? Responda PASS ou FAIL
e depois liste o que faltou.
<request>${facts.request}</request>
<reply>${draft}</reply>`,
  });

  return review.startsWith("PASS")
    ? { status: "ready", draft }
    : { status: "revise", draft, feedback: review };
}

Repare em três coisas. Cada prompt tem um objetivo. As passagens vão envoltas em tags ou schemas. E duas das três checagens são código puro, que não custa nada e se comporta igual toda vez. Quando algo piora, você testa só aquele elo com um punhado de chamados salvos, em vez de reler um megaprompt de 60 linhas.

6. Quando não encadear

A tarefa é simples. Os modelos de raciocínio atuais já planejam internamente. A Techsy observa que roteirizar passos de raciocínio para esses modelos pode ser redundante ou até piorar; o guia de raciocínio da OpenAI diz o mesmo. Um prompt único, curto e claro ganha de uma cadeia de cinco etapas para uma resposta de um parágrafo.
Latência importa mais que acabamento. Cada elo sequencial adiciona uma ida e volta completa. Paralelize o que der e junte elos que nunca falham.
Você não consegue dizer o que cada elo deve entregar. Se não dá para escrever um teste para uma etapa, ela ainda não é uma etapa de verdade. Repense a divisão.
Um loop de agente encaixa melhor. Uma cadeia fixa serve para uma sequência conhecida. Quando o caminho depende do que o modelo encontra (buscar, ler, decidir), um agente com ferramentas é o formato certo. Cadeias e agentes são primos: a cadeia é um roteiro que você escolhe antes.

Resumo: divida o trabalho onde uma etapa vive sendo esquecida, passe o bastão com tags limpas e faça toda "revisão" comparar contra algo concreto: um schema, um teste, o texto de origem ou, no mínimo, uma rubrica escrita numa chamada separada.

Fontes

Nota: a rotação apontava para "Prompt engineering na prática"; não foi encontrado anúncio da Anthropic/Claude datado de hoje (os itens mais recentes eram a atualização de informações eleitorais de 14/10 e a ativação padrão de Docs/Slides/Design em 15/10). A orientação da Anthropic sobre encadeamento foi lida por um resumo de terceiros que aponta para a página oficial. O código é ilustrativo; callModel é um placeholder.