1. The shift: from instructions to policy
Classic prompt engineering treats a prompt like a recipe: step 1, step 2, step 3, done. That model made sense when a prompt produced one response and the conversation ended. It breaks down for agents — systems that read a system prompt once, then run an open-ended loop of reasoning, tool calls, and follow-up decisions across many turns without a human re-typing instructions each time.
For an agent, the system prompt isn't a recipe anymore — it's closer to operating policy. It has to tell the model what role it's playing, what "done" looks like, which tools exist and when to reach for them, when to stop and ask versus keep going, and what boundaries it can't cross. That's a fundamentally different writing job: less like copywriting a single request, more like writing a spec a colleague will apply judgment against for the next twenty minutes.
2. Why micro-instructions backfire on agents
A list of tightly-sequenced steps ("first do X, then do Y, then check Z") feels like it should produce more reliable behavior. In practice it narrows the model's options at exactly the moments when the situation on the ground doesn't match what you imagined when you wrote the prompt — a file that doesn't exist, a test that was already passing, an API that returned something unexpected.
The better pattern: describe the outcome you want ("get the checkout page's load time under 2 seconds") instead of the steps to get there ("open the network tab, find the largest asset, compress it, re-run Lighthouse"). An agent with tool access can figure out the steps, and — critically — can adapt them when the first approach doesn't work. Steps you hand-wrote in advance can't adapt; they just fail.
This doesn't mean prompts should be vague. It means the specificity should live in the definition of success and the constraints, not in a rigid procedure. "Reduce load time below 2 seconds without breaking any existing test" is specific. "Open dev tools, click the Network tab..." is brittle.
3. Effort and extended thinking: let the model calibrate
Modern Claude models expose an effort/thinking parameter that scales how much internal reasoning the model does before acting, and the model itself already adjusts this based on how complex a query looks — a simple lookup gets a fast, direct answer; a gnarly multi-file refactor gets more deliberation first. That's useful, but it doesn't replace explicit chain-of-thought instructions for genuinely complex tasks — the two are complementary. Extended thinking helps the model plan; telling it explicitly to reason step by step before committing to an action still helps on tasks where the plan itself is the hard part (ambiguous requirements, competing constraints, multi-file architectural decisions).
For agentic workloads specifically — multistep tool use, long-horizon loops, coding tasks that span several files — the advice converging across current guidance is to lean into higher-effort/adaptive thinking modes rather than fight them, and to spend prompt real estate on what "good" looks like rather than trying to out-plan the model turn by turn.
4. Build in self-verification, don't assume it
An agent that can act without supervision needs a way to catch its own mistakes before declaring victory. The pattern showing up repeatedly in current agentic-prompting guidance: explicitly instruct the model to close its own loop — reproduce the reported bug first, apply a fix, then run the test suite to confirm the fix actually worked, rather than assuming a plausible-looking diff is a correct one.
| Without self-verification | With self-verification |
|---|
| Model proposes a fix, states it should work, stops. | Model reproduces the bug, applies a fix, runs tests, and only then reports success or failure. |
| Confidence in the output is the model's own narrative. | Confidence in the output is backed by an executed check the model performed itself. |
This costs more tokens and more turns per task. For anything an agent will run unattended, it's worth the cost — the alternative is a plausible-sounding answer nobody actually checked.
5. A practical checklist
- Define success, not procedure. State the end condition and the constraints; leave the path to the agent.
- Name the tools and the boundaries. What can it call, what's off-limits, when should it stop and ask a human.
- Use higher effort/thinking for genuinely hard steps and let the model calibrate on the easy ones instead of forcing uniform verbosity.
- Demand a checkable close. "Run the tests and report the result" beats "I've made the fix."
- Treat the system prompt like code. Version it, review changes to it, and expect to iterate — it's the one piece of context present on every single turn.
1. A virada: de instrução pra política
Prompt engineering clássico trata um prompt como receita: passo 1, passo 2, passo 3, pronto. Isso fazia sentido quando um prompt gerava uma resposta e a conversa acabava ali. O modelo quebra pra agentes — sistemas que leem um system prompt uma vez e então rodam um loop aberto de raciocínio, chamadas de ferramenta e decisões seguintes ao longo de várias rodadas, sem um humano redigitando instruções a cada passo.
Pra um agente, o system prompt não é mais uma receita — é mais parecido com política operacional. Ele precisa dizer que papel o modelo está desempenhando, o que "concluído" significa, quais ferramentas existem e quando usá-las, quando parar e perguntar em vez de continuar, e quais limites não pode cruzar. É um trabalho de escrita fundamentalmente diferente — menos copywriting de um pedido único, mais uma spec que um colega vai aplicar com julgamento próprio pelos próximos vinte minutos.
2. Por que micro-instruções saem pela culatra em agentes
Uma lista de passos rigidamente sequenciados ("primeiro faça X, depois Y, depois confira Z") parece que deveria gerar comportamento mais confiável. Na prática, ela estreita as opções do modelo exatamente nos momentos em que a situação real não bate com o que você imaginou ao escrever o prompt — um arquivo que não existe, um teste que já estava passando, uma API que devolveu algo inesperado.
O padrão melhor: descreva o resultado que você quer ("deixar o tempo de carregamento da página de checkout abaixo de 2 segundos") em vez dos passos pra chegar lá ("abra a aba Network, encontre o maior asset, comprima, rode o Lighthouse de novo"). Um agente com acesso a ferramentas consegue descobrir os passos e, criticamente, consegue se adaptar quando a primeira abordagem não funciona. Passos escritos à mão de antemão não se adaptam — só falham.
Isso não significa que prompts devam ser vagos. Significa que a especificidade deve estar na definição de sucesso e nas restrições, não num procedimento rígido. "Reduza o tempo de carregamento pra abaixo de 2 segundos sem quebrar nenhum teste existente" é específico. "Abra as devtools, clique na aba Network..." é frágil.
3. Esforço e extended thinking: deixe o modelo calibrar
Os modelos Claude atuais expõem um parâmetro de esforço/thinking que escala quanto raciocínio interno o modelo faz antes de agir, e o próprio modelo já ajusta isso com base em quão complexa a consulta parece — uma busca simples recebe uma resposta rápida e direta; um refactor complicado envolvendo vários arquivos recebe mais deliberação antes. Isso é útil, mas não substitui instruções explícitas de raciocínio passo a passo em tarefas genuinamente complexas — as duas coisas são complementares. Extended thinking ajuda o modelo a planejar; pedir explicitamente pra ele raciocinar passo a passo antes de se comprometer com uma ação ainda ajuda em tarefas onde o próprio plano é a parte difícil (requisitos ambíguos, restrições concorrentes, decisões de arquitetura envolvendo vários arquivos).
Especificamente pra cargas de trabalho agênticas — uso de ferramenta em múltiplos passos, loops de longo horizonte, tarefas de código que atravessam vários arquivos — o conselho que converge nos guias atuais é apoiar os modos de esforço/thinking mais alto/adaptativo em vez de lutar contra eles, e gastar o espaço do prompt definindo o que é "bom" em vez de tentar planejar o modelo passo a passo.
4. Construa autoverificação, não presuma ela
Um agente que age sem supervisão precisa de um jeito de pegar os próprios erros antes de declarar vitória. O padrão que aparece repetidamente nos guias atuais de prompting agêntico: instrua explicitamente o modelo a fechar o próprio loop — reproduzir primeiro o bug relatado, aplicar uma correção, depois rodar a suíte de testes pra confirmar que a correção realmente funcionou, em vez de presumir que um diff com cara plausível é um diff correto.
| Sem autoverificação | Com autoverificação |
|---|
| Modelo propõe uma correção, afirma que deveria funcionar, para. | Modelo reproduz o bug, aplica uma correção, roda os testes, e só então relata sucesso ou falha. |
| A confiança na resposta é a própria narrativa do modelo. | A confiança na resposta é apoiada numa checagem executada que o próprio modelo realizou. |
Isso custa mais tokens e mais rodadas por tarefa. Pra qualquer coisa que um agente vai rodar sem supervisão, vale o custo — a alternativa é uma resposta com cara plausível que ninguém de fato conferiu.
5. Um checklist prático
- Defina sucesso, não procedimento. Diga a condição final e as restrições; deixe o caminho pro agente.
- Nomeie as ferramentas e os limites. O que ele pode chamar, o que está fora dos limites, quando deve parar e perguntar pra um humano.
- Use esforço/thinking mais alto nos passos genuinamente difíceis e deixe o modelo calibrar nos fáceis, em vez de forçar verbosidade uniforme.
- Exija um fechamento verificável. "Rode os testes e relate o resultado" é melhor que "eu fiz a correção".
- Trate o system prompt como código. Versione, revise mudanças nele, e espere iterar — é a única parte do contexto presente em toda rodada.