Prompt Engineering Is Table Stakes. Agent Management Is the Game.

There’s a genre of article I keep seeing: “7 prompt tricks that changed my life.” They’re not wrong, exactly. The advice usually boils down to the same set of principles — be specific, give examples, use structured formatting, assign a role, ask the model to think before answering. These are real techniques that produce real improvements, and if you’re still typing “summarize this for me” into Claude, yes, you should read one of those articles.

But I’ve spent the last few months building multi-agent pipelines, and the experience has made something clear: prompt engineering is to AI agents what typing speed is to programming. It’s a prerequisite that stops being the bottleneck almost immediately. The real leverage is in how you design the system around the model.

What the prompt advice actually says

I went through about a dozen of these guides — Anthropic’s official docs, Tom’s Guide, DreamHost’s tested techniques, BuildFastWithAI, TechRadar, several Medium posts. The consensus techniques, stripped of the clickbait framing, are roughly:

1. Use XML tags to structure prompts. Claude was trained on structured inputs. Wrapping sections in <task>, <context>, and <output_requirements> tags activates better pattern matching than a flat paragraph.
2. Show examples instead of describing what you want. One concrete example of the output format beats a paragraph of adjectives.
3. Be explicit. Claude 4.x takes you literally. “Review this script” gets you a surface pass. “Review this PowerShell script for security vulnerabilities, error handling gaps, and STIG compliance issues” gets you something actionable.
4. Assign a specific role. Not “you are a sysadmin” but “you are a senior Windows Server systems administrator with deep experience in DoD STIG compliance and Azure hybrid environments.”
5. Ask the model to think, but don’t over-prescribe the steps. “Think thoroughly about this” often outperforms a hand-written step-by-step plan, because the model’s reasoning can exceed what you’d prescribe.
6. Put long documents first, query last. Anthropic’s own testing shows up to 30% improvement when queries follow the reference material rather than precede it.
7. Specify output format. Markdown tables, numbered findings, severity ratings — whatever structure makes the output immediately usable.
8. Iterate conversationally. First output is a draft. Follow up with corrections and refinements.
9. Give explicit permission to say “I don’t know.” Reduces hallucination significantly.
10. Chain complex tasks into discrete steps rather than cramming everything into one mega-prompt.

These work. I use most of them daily. The XML tags and document-ordering tips in particular are underrated — they have the strongest empirical backing and the lowest adoption.

Where this stops being the bottleneck

Here’s the thing: if you’re doing something that fits in a single conversation — drafting an email, reviewing a config file, explaining a concept, generating a script — prompt engineering is the whole game. Master those ten techniques and you’ll get excellent results.

But the moment your task involves multiple cognitive steps that depend on each other, or requires verification of claims, or needs to integrate information from different sources and evaluate it against different criteria — a single prompt, no matter how well-engineered, hits a ceiling.

I learned this concretely when I built a multi-agent pipeline to red-team GiveWell’s charity research.

GiveWell: the case study

GiveWell had done something smart — they used AI to critique their own cost-effectiveness analyses for global health interventions. Their approach was essentially prompt engineering done well: a carefully designed prompt, given to ChatGPT, with their research as context. They published the results honestly: about 15-30% of the AI’s critiques were worth investigating.

The failure modes they reported are the ones everyone who’s done serious work with LLMs recognizes: hallucinated citations, lost context, made-up quantitative estimates, rediscovery of issues already addressed in the source material.

Their diagnosis was that AI red teaming was moderately useful but inherently limited. Mine was different: these are architecture problems, not model problems.

The fix wasn’t a better prompt. It was a pipeline.

The Decomposer reads the intervention report and identifies investigation threads, plus an exclusion list of things GiveWell already addresses. Investigators generate hypotheses — but are explicitly prohibited from citing evidence. This single design choice eliminated hallucinated citations, because the hallucination pressure comes from asking a model to simultaneously generate an idea AND find supporting evidence. Separate those cognitive tasks and the problem disappears. The Verifier independently searches for real evidence for each hypothesis. The Quantifier runs actual sensitivity analysis against GiveWell’s spreadsheet — not “could reduce cost-effectiveness by 15-25%” but “changing this parameter from X to Y changes the bottom line by Z%.” An Adversarial Pair stress-tests surviving critiques. The Synthesizer ranks everything that made it through.

The result: 84% signal rate, zero hallucinated citations, $32 in API calls. The top finding — that GiveWell’s plausibility cap masks extreme parameter sensitivity — could only be discovered by running real numbers and then reasoning about the pattern across multiple critiques. No single prompt, however well-crafted, would produce that.

What agent management actually looks like

The techniques from the prompt engineering guides don’t disappear in a multi-agent system. They get absorbed into the infrastructure. Here’s where each one lives:

XML tags and structured formatting become the inter-agent communication protocol. Each agent’s output is structured so the next agent can parse it unambiguously. You’re not hoping the model formats things nicely — you’re requiring it as part of the pipeline contract.

Role assignment becomes agent specialization. Instead of asking one model to be a researcher-fact-checker-analyst-editor simultaneously, each agent has one role with one set of capabilities and one definition of success.

“Think before answering” becomes pipeline staging. The Decomposer thinks about what to investigate. Investigators think about what might be wrong. The Verifier thinks about what’s actually supported. You’ve externalized the chain of thought into architecture, where it can be inspected, debugged, and iterated on.

“Say ‘I don’t know’” becomes verification as a first-class stage. The Verifier classifies claims as verified, partially verified, or unverified. Uncertainty isn’t a polite caveat — it’s a routing decision that affects what happens next.

Document ordering and context management becomes scoped context per agent. No agent sees the whole filing cabinet. Each gets a CONTEXT.md defining what’s in scope, what data to reference, and what not to re-examine. This eliminates the lost-context failure mode that plagues long single-prompt interactions.

Task chaining becomes the pipeline itself.

The pattern is consistent: every prompt engineering technique, when applied at the agent level, transforms from a suggestion to the model into a structural guarantee of the system.

Where this matters for real work

I’m a systems administrator, not an AI researcher. The reason I care about this distinction is practical.

In my day job supporting DoD IT operations, I use Claude constantly for single-prompt tasks — reviewing PowerShell scripts, drafting STIG compliance documentation, troubleshooting IIS configurations, preparing technical briefs for leadership. Prompt engineering techniques make those interactions significantly better. The role assignment technique alone (“you are a DoD systems administrator reviewing this for STIG compliance against the Windows Server 2022 STIG”) changes the output from generic to directly usable.

But when I needed to evaluate whether Splunk 10’s FIPS mode requirement actually conflicts with DoD PKI certificate requirements — a question that requires reading multiple STIG documents, cross-referencing vendor documentation, checking actual certificate chains, and producing a recommendation for my ISSM — that’s not a prompt engineering problem. That’s a “how do I structure multiple passes of analysis so each one builds on verified output from the last” problem.

Same pattern with my StemForge and MusicVision projects. The individual prompts for code generation and debugging are important, and Claude Code’s built-in prompt engineering (CLAUDE.md files, skill definitions, context management) handles most of the technique list automatically. The harder problem is orchestrating multiple tools and models across machines — when to use the local Qwen instance for inference, when to use Whisper for transcription, how to pipeline audio separation into MIDI transcription into video scene generation. That’s agent management, not prompt engineering.

The mental model shift

The prompt engineering articles frame AI as a conversation partner that you need to talk to more skillfully. That framing is useful up to a point, and it’s the right mental model for most daily interactions.

But for complex work, the better mental model is AI as a team you’re managing. You wouldn’t hand one person a 50-page brief and say “find everything wrong with this, check your own facts, quantify the impact, argue against yourself, and write up the results.” You’d assign those tasks to different people with different skills and build a review process.

The prompt engineering techniques are still there — they’re how you write the job description for each team member. But the leverage comes from how you structure the team.

Practical takeaways

If you’re using Claude (or any LLM) primarily through chat, master the prompt engineering basics. They’re real, they’re well-documented, and the gap between a vague prompt and a structured one is wider on Claude than on any other frontier model. Start with XML tags and explicit output formatting — those two alone will change your results immediately.

If you’re building anything that involves multiple dependent steps, verification, or integration of information from different sources, stop trying to write a better prompt and start designing a pipeline. The returns from going multi-agent — even a simple two-stage “generate then verify” pipeline — dwarf the returns from prompt optimization on a single pass.

And if you’re at an organization trying to decide whether to invest in “prompt engineering training” or “AI workflow design” — invest in both, but know where the ceiling is on each. Prompt engineering gets you from 30% to 70%. Agent architecture gets you from 70% to 90%. The last 10% is domain expertise and human judgment, and that’s not going away.

---

The GiveWell red-teaming pipeline is open source at github.com/tsondo/givewell_redteam. StemForge is at github.com/tsondo/stemforge. If you want to discuss agent architectures, prompting, or any of this — I’m at [email protected] or @tsondo.com on Bluesky.