Advanced Prompting Patterns for Infrastructure Planning

Last reviewed: June 2026
Part 3 of 8 · Using AI in infrastructure work — the full series is listed at the end.

Part 2 covered the single-prompt patterns I use every day: notes to RAID, script review, CAB draft. This part is for the cases where one prompt isn't enough — where the work has multiple steps, competing options, or input that isn't even text. These are still bounded, reviewable patterns. "Advanced" doesn't mean autonomous; it means more moving parts, each of which still needs a human gate. The rule from Part 1 holds the whole way through: a longer answer is not a better answer unless it carries better evidence.

Pattern 1: prompt chaining

Chaining works when one controlled output becomes the input to the next step, and — crucially — you review between steps rather than only at the end. On a migration, a realistic chain looks like this:

The discipline is the review at each hand-off. If you let weak extracted notes flow straight through to a polished migration plan, the chain just launders uncertainty — every step adds fluency and the original gaps disappear under it. I treat each link the way I'd treat a junior's work moving from one desk to the next: it gets checked before it's allowed to continue. Done that way, chaining is genuinely powerful; done as one long unreviewed prompt, it's a confident-sounding plan built on guesses.

Pattern 2: option comparison

For architecture decisions I make the model compare options against criteria I set, rather than asking the open question "what's best?"

Compare Citrix Cloud, hybrid Citrix, and on-premises Citrix for this environment.
Use these criteria:
- control plane ownership
- identity path
- application compatibility
- network latency
- rollback
- monitoring
- service desk readiness
- operational ownership

Return a decision matrix.
Separate facts, assumptions, and questions.

Having supported large Citrix estates, I know the decision is rarely the control plane itself — it's identity, profiles, printing, and who operates the platform after go-live. Scoring against my criteria, with facts and assumptions kept separate, stops the model from collapsing a genuinely contested decision into a confident one-liner. The trap is the model's instinct to recommend. Left to itself it will pick a winner and write a persuasive paragraph for it; what I actually need is the matrix, the assumptions it had to make, and the questions that would change the answer. The recommendation is mine to make once those are visible.

Pattern 3: tool-assisted prompting

Tool use earns its place when the model can retrieve approved context, query logs, read runbooks, or inspect a repository instead of reasoning from memory. The hard part is permission design, not capability. The model should only reach tools that match the user, the task, and the approval level — read-only by default, scoped writes only where needed, and nothing that touches production without an explicit human gate. Useful infra flows include querying monitoring logs, searching a CMDB, reading approved runbooks, summarising tickets, and checking a script repository. This pattern is the doorway from "prompting" to "systems" — retrieval is Parts 4 and 5, agents are Part 6 — and the permission discipline only gets more important from here.

Pattern 4: self-review

A self-critique pass is good at catching gaps, as long as you remember what it is: a gap-finder, not an approver.

Review this PowerShell script before production use.
Check for:
- SupportsShouldProcess
- WhatIf and Confirm behavior
- input validation
- logging
- rollback
- idempotency
- least privilege
- secrets exposure
- auditability

Return blocking risks first.

I'll often run this as a second pass after the model has drafted something, or before I put a script in front of a human reviewer. It reliably catches the obvious misses. What it cannot do is approve its own work — a model marking its own homework will miss the same blind spot twice, and it has no stake in the outcome if the script breaks production at 2am. Self-review tightens the draft; it never closes the gate.

Pattern 5: multimodal prompting

This is the pattern I understand best from the build side, so I'll spend the most time on it. While developing FlowForge — a retrieval platform I forked from RAGFlow and rebuilt around vision-language models — I spent months on exactly how models read diagrams, screenshots, scanned runbooks, and photographed whiteboards. That work made me both more willing to use multimodal prompting in infrastructure planning and far more careful about how I trust it.

The use is real and valuable. I'll hand a model an architecture diagram, a network sketch, or a whiteboard photo from a design session and ask it to extract the systems, the dependencies, the unclear labels, and the follow-up questions. For turning a wall of boxes-and-arrows into a first- pass inventory, it genuinely saves time.

But building VLM retrieval taught me precisely where it breaks, and the failure modes are specific:

• Faint or low-contrast labels get confidently misread or silently dropped — the model returns a clean list that's missing the box you most needed.
• Crossed-out or annotated elements are ambiguous to a model; it can't always tell "rejected option" from "current design."
• Arrows and direction are frequently misinterpreted, which matters enormously when the diagram is a data-flow or a trust relationship.
• Implied context — the thing everyone in the room knew but nobody drew — is simply absent, and the model won't flag its absence.

That is exactly why I treat the extracted result as a draft to verify, never as proof. The output gets checked against approved architecture documentation and the people who own the systems. Multimodal prompting is a fast way to read a diagram into text; it is not a source of truth about what the diagram actually means.

When advanced prompting is overkill

The honest counterpoint: most infrastructure tasks don't need any of this. A chained, multimodal, self-reviewing workflow is the wrong tool for "summarise this workshop" — that's a single Part 2 prompt. I reach for these patterns when the task genuinely has multiple stages, contested options, or non-text input. Reaching for them when a simple prompt would do just adds steps, latency, and more places for an error to hide. Sophistication is a cost; spend it only where it buys real clarity.

Build a shared library, not private tricks

For a team, I'd standardise a small library of prompt patterns instead of letting every engineer invent their own: discovery-to-RAID, script review, CAB drafting, option comparison, runbook review, post-incident summary, diagram extraction. Each entry should carry its allowed sources, blocked use cases, review expectations, and an example of acceptable output — versioned and reviewed like any other operational asset. A shared, reviewed library is also how you stop a junior engineer from quietly pasting a real sign-in log into a consumer chatbot because they didn't know better. The pattern is the guardrail.

Practical checklist

• Choose the pattern based on the work product, not novelty.
• Review between chained steps, not just at the end.
• Make option comparisons return matrices and assumptions, not a winner.
• Use tool access only with approved sources and least-privilege permissions.
• Treat multimodal extraction as a draft to verify against owners and docs.
• Keep a human review before any production impact.
• Version and review reusable prompts as shared team assets.

The point

Advanced prompting makes infrastructure planning more explicit and more reviewable — chained, compared, self-checked, and multimodal where it helps. The goal is never a smarter-sounding answer; it's better decisions, clearer risks, and a stronger human review. Patterns 3 and 5 both pointed at the same next problem: a prompt is only as good as the context behind it. Part 4 is about getting that context right — retrieval over your own infrastructure knowledge, and the quiet ways it fails.

The full series

1. How I Use AI Safely in Infrastructure Workflows
2. Prompt Engineering for IT Infrastructure Consultants
3. Advanced Prompting Patterns for Infrastructure Planning — (you're reading this)
4. RAG for Enterprise Infrastructure Knowledge
5. Context Engineering for Enterprise AI Systems
6. Workflow Engineering for Agentic AI in Infrastructure Operations
7. AI Coding Agents in Infrastructure Automation
8. TDD + SDD for AI-Assisted Infrastructure Automation