I’ve built automation pipelines at a large healthcare system for the past few years, everything from Power Automate flows that fire on SharePoint triggers to multi-step AI agents that extract structured data from PDFs. The hardest thing I’ve learned isn’t how to build them. It’s how to decide what to build.

The selection problem is invisible until it isn’t. You spend eight weeks engineering a solution, ship it, and then watch it save four hours a month. The math was never there. You just didn’t run the math before you started.

The Selection Trap

McKinsey’s November 2025 research puts 57% of US work hours as technically automatable with today’s AI agents and robotics. That number gets cited as evidence that the automation opportunity is massive. It is. But it also means that most of what you’re looking at can be automated, which makes the selection problem worse, not better.

Most organizations have automated less than 15% of eligible processes. The gap isn’t technical capability. It’s the absence of a filter for deciding which 15% to build first.

Two selection errors keep appearing in every automation program I’ve been part of:

The prestige automation. A process that looks impressive to automate, multi-system, AI-powered, generates a good slide. It runs monthly. Even if it works perfectly, the payback period stretches past two years. The engineering investment was real. The value wasn’t.

The visible-but-small win. A process that’s painful enough that everyone complains about it, but it’s only 5% of one person’s week. You automate it, the team cheers, and the real bottleneck, the process that consumes 40% of the week, sits untouched because it looked harder to automate.

Both errors share the same root cause: the decision was made on gut feel, not economics.

The Complexity-to-Value Matrix

Before I scope any automation now, I place the candidate process in a 2×2. The axes are implementation effort and business value.

Quick Wins first. High-frequency, structured processes that live in a single system. Low effort to automate, high payback.

Strategic Bets get staged rollouts. High value, but the complexity is real, plan for it, don’t wish it away.

Fill-ins only if trivial. They’re not the priority.

Traps don’t get built. Full stop. The prestige automation lives here.

Scoring a Process

Effort signals: these push a process toward low effort:

• Structured, predictable inputs (not PDFs with variable layouts, not free-text emails)
• Single system, no cross-system joins required
• Existing API or low-code connector available
• No multi-step approval paths
• No regulatory audit requirement

Value signals: these push a process toward high value:

• High frequency: daily or weekly, not monthly
• High per-unit time cost: this is someone’s two hours, not their fifteen minutes
• Errors are expensive: compliance risk, rework, or downstream impact
• It’s a bottleneck: upstream work queues here

If a process scores low on both axes, it’s a Fill-in at best and a Trap at worst. Don’t let the technology’s novelty substitute for the economics.

The Payback Formula

Once a process passes the quadrant filter, run the numbers:

Cost side: development hours × fully-loaded rate, tooling and licensing, QA and testing, change management, ongoing maintenance.

Value side: hours saved per week × wage, error reduction value, cycle time improvement.

Two adjustments most estimates skip:

Ramp-up discount. The first one to three months after go-live are not full savings. People are still learning the new process, there are edge cases to handle, and exceptions that weren’t in the spec.

Maintenance decay. Automations erode. The process changes, the source system gets updated, the data format shifts. Budget 10–20% annual maintenance overhead against your savings figure.

A direct-labor calculation understates ROI by 30–50%. Error reduction and cycle time value are real, include them. But they’re harder to quantify, so lead with the labor math and treat the rest as upside.

The Enterprise Wrinkle: Risk as a Modifier

In a regulated environment, a third dimension can reclassify a process. Compliance exposure, audit requirements, and data residency constraints can push a Quick Win into Strategic Bet territory, not because the automation is technically harder, but because the governance work around it is.

Before finalizing a quadrant placement: ask whether the process touches protected health information, financial records, or a regulatory workflow. If yes, the effort estimate goes up. The value might too, compliance risk reduction is often the highest-value automation outcome in healthcare, but the naive effort estimate needs to be adjusted.

When This Doesn’t Apply

This filter works when there’s enough process regularity to automate. It doesn’t work for processes that are genuinely judgment-intensive, where exceptions are the rule rather than the edge case.

Don’t use the matrix to justify automating something that actually requires human reasoning, the maintenance cost of a badly-scoped AI agent will swamp any savings in the first year. The question isn’t “can we automate this?” It’s “does this process have enough structure that an automation will be cheaper to maintain than the human doing it?”

McKinsey didn’t tell you what to build first. This does.

Rich Wellman is an AI Automation Specialist at the healthcare system where he works, building AI pipelines on Azure. He writes about what actually works at richwellman.com.

Ask most enterprise IT people what it is and they’ll say “Microsoft’s low-code chatbot builder.” That’s accurate — the way saying a compiler is a text processor is accurate. Technically true, completely misses the point.

I’ve spent the last several months building agents in Copilot Studio for a large healthcare system. What I’ve come to understand is that Copilot Studio — in its modern generative orchestration mode — is running the same fundamental loop as Claude’s tool-use system, OpenAI function calling, LangChain’s agent executor, and Microsoft’s own Semantic Kernel. The “low-code” label describes the authoring surface. It says nothing about the architecture underneath.

That architecture is worth understanding. Because once you see it, a few things become clear: what the highest-leverage work actually is, why most Copilot Studio agents underperform, and why the skills you’re building here transfer directly to every other agent framework.

The Loop That Every Agent Framework Runs

Strip away the platform-specific terminology and every modern LLM agent — whether you’re building in Claude, Copilot Studio, LangChain, or Semantic Kernel — runs some version of this:

1. Give the model a set of callable functions, with descriptions
2. Model reads the descriptions, picks one, generates the arguments
3. Framework executes the function
4. Result gets fed back to the model
5. Model decides: done, or call another function?
6. Repeat until done

That’s it. Every framework is a different wrapper around that loop. The wrappers differ in governance, execution environment, authoring UX, and enterprise integration. The loop is the same.

Copilot Studio’s version of this is called generative orchestration. In this mode:

• Your agent instructions are the system prompt
• Your actions (backed by Power Automate flows or HTTP calls) are the callable functions
• The action descriptions are what the LLM reads to decide which function to call
• The LLM orchestrator sequences the workflow at runtime, based on what you’ve written

Microsoft’s own guidance says it plainly: “Copilot Studio isn’t designed to be heavily authored, topic by topic. Instead, it’s focused on authored business-critical experiences that work side by side with AI-driven knowledge, orchestration, and automation.”

Translation: stop drawing topic graphs. Write the system prompt and the tool descriptions. Let the LLM route.

The Equivalence Table Nobody Shows You

Here’s the direct mapping across frameworks:

The syntax is different. The concept is identical.

What Copilot Studio adds — and this is the actual differentiator — is the enterprise wrapper:

• Azure AD authentication, so the agent runs as a governed identity
• Teams and M365 Copilot as deployment surfaces, so users never leave their workspace
• DLP policies, compliance boundaries, and audit trail built into the platform
• Licensing and capacity management Microsoft already handles

If you’re building AI agents inside a regulated enterprise — healthcare, finance, government — that wrapper isn’t overhead. It’s the thing that lets the project ship at all. Any custom-built agent framework means you’re also building the auth, the deployment surface, the compliance story, and the licensing model. Copilot Studio comes with all of that.

The trade-off is flexibility. You’re working within Microsoft’s constraints. But for most enterprise business process automation, those constraints are fine — and the governance layer is genuinely hard to replicate.

What This Means for How You Build

If Copilot Studio is running the same loop as every other agent framework, then the highest-leverage skills are the same too.

The most important thing you do is write the action descriptions.

Not the Power Automate flows. Not the topic graph. Not the system prompt (though that matters). The descriptions you write for each action are what the LLM reads when it decides which function to call next. Write them poorly and the agent mis-routes. Write them well and the agent sequences correctly even in edge cases you didn’t explicitly author.

A good action description:

• States when to use it — the trigger condition in plain English
• Names preconditions — what must already be true before this function is called
• Hints at downstream coupling — how this action’s output feeds the next
• Explicitly excludes ambiguous cases — what NOT to use it for

I built a treasury reconciliation agent with four actions. No topics. The agent loads a CSV export, extracts data from PDF documents, reconciles the two, and moves the file to the right folder — entirely driven by the LLM reading the agent instructions and action descriptions. The only time I needed to add a deterministic topic was for a specific edge case where the orchestrator consistently drifted. One topic, as a guardrail.

That’s the modern model. System prompt as the control plane. Action descriptions as the routing logic. Topics only where you need a hard rail.

The Portability Point

Here’s what I find most useful about this framing.

If you understand that Copilot Studio is running the same loop as Claude or LangChain, then the skills you’re building aren’t Copilot Studio skills. They’re agent design skills. Tool decomposition. Description authoring. Orchestration drift handling. Knowing when to make the LLM decide versus when to force a deterministic path.

Those skills transfer directly to any other framework. Moving from Copilot Studio to the Claude API or LangChain is additive syntax — you’re learning new function signatures, not a new paradigm.

This matters if you’re an enterprise architect who wants to stay current. You don’t need to abandon the Microsoft stack to develop serious AI engineering depth. The work you’re doing in Copilot Studio, if you understand what it’s actually doing, is the same work you’d be doing anywhere else. The enterprise wrapper is the deployment target. The architecture is the skill.

The One-Line Summary

Copilot Studio in generative orchestration mode is an LLM agent runtime with Microsoft’s enterprise governance layer on top. The AI capability is the same as every other major framework. What you’re buying is the wrapper.

Once you see it that way, you know what to spend your time on: write good descriptions, write a clear system prompt, and let the LLM do the routing it was built to do.

Rich Wellman is a Solutions Architect at a major healthcare system, building AI automation on Azure. He writes about what actually works at richwellman.com.

The problem: Treasury staff at a major healthcare system receive banking documents every day — patient cash sweeps, wire transfer requests, concentration reports, standalone transfers. Each one a PDF. Each one needs to be reconciled against a treasury management system export to confirm every dollar moved where it was supposed to move.

Manual reconciliation is slow. A single Patient Cash Sweep can contain seventeen line items totaling tens of millions of dollars. One transposed account number is hours of debugging.

The solution, eventually, was a single prompt running on a reasoning model. What I built before that teaches more than the solution itself.

What I Tried Before It Worked

Approach 1 — Just ask Copilot.

Paste the PDF text in, prompt for extraction. This proved the concept: an LLM can read these documents and return structured data without a custom parser. It also proved the obvious limitation: you can’t automate a paste-and-wait workflow.

Approach 2 — Azure AI Document Intelligence custom models.

I trained a custom model on each document type — wire transfer forms, sweep summaries, concentration reports. Document Intelligence is excellent for fixed-layout forms, and it worked for those. Treasury documents aren’t fixed layouts. One sweep has twelve rows; the next has twenty-three. Wire requests have optional fields that appear only for inter-bank transfers. A new document type meant a new labeling session, a new training run, a new testing cycle. The maintenance overhead compounded immediately.

Approach 3 — Azure AI Content Understanding: classifier plus type-specific analyzers.

A smarter architecture: a classifier to identify the document type, then route to the right analyzer. I built this with Azure AI Content Understanding — a classifier with child analyzers for each document category. The architecture was sound. The failure modes multiplied. Misclassification routes the document to the wrong analyzer. The right analyzer hits a layout variant it hasn’t seen. The extraction succeeds but a field mapping is incomplete. Each layer adds diagnostic surface without proportional accuracy. Debugging a failed extraction now means asking: did the classifier route correctly? Did the right analyzer fire? Did the extraction return nulls it shouldn’t have? Complexity scaled faster than reliability.

Approach 4 — Copilot Studio orchestrating an Azure Function.

I moved to Copilot Studio as the delivery layer, with an Azure Function handling extraction. The problem: the function became a maintenance bottleneck. Custom parsing logic per document type. Every new format meant new code. Different language, same problem as the custom models.

Approach 5 — GPT-4.1 with classify-then-extract prompts.

I embraced LLM-based extraction fully. A classification prompt identified the document type. A Power Automate Switch routed to one of four extraction prompts, each with its own JSON schema. This was the closest I got before the real solution — and it exposed the actual problem clearly.

GPT-4.1 is an instruction-following model. The extraction prompts I needed weren’t instruction-following tasks. They were reasoning tasks:

• Infer that the single “From” account at the top of a sweep applies to every row in the table below it
• Understand that FFC routing means the sub-account is the real beneficiary, not the intermediate bank
• Distinguish between line items that describe cost breakdown versus line items that are separate transfers
• Decide whether a “Total” row aggregates destinations or justifies a single wire amount

GPT-4.1 handled clean documents acceptably. On complex ones it left fields blank, treated cost breakdowns as separate transfers, or misread structural relationships. The model was doing its best. I was asking it to do something it wasn’t built for.

The architecture also created a maintenance problem: five prompts, four JSON schemas, a Switch with four branches. Adding a new document type meant a new prompt, a new schema, a new Switch case.

What Actually Worked

I collapsed everything to one prompt.

One prompt. One schema. All document types. No classifier. No Switch. No branches.

The schema defines every money movement as a from → to → amount row:

{
  "document_type": "string",
  "date": "string",
  "transactions": [
    {
      "from_entity": "string",
      "from_account": "string",
      "to_entity": "string",
      "to_account": "string",
      "amount": "number",
      "description": "string or null"
    }
  ],
  "grand_total": "number or null",
  "transaction_count": "number"
}

The prompt instructs the model to extract every distinct money movement, infer shared values from context, use FFC accounts as the real beneficiary, and validate that amounts sum to the grand total.

The reasoning model reads the document, builds an internal model of its structure, infers entity relationships, and maps everything to the universal schema — without being told what type of document it’s processing. Document type is still output as a field, but it’s a byproduct of reasoning rather than a routing prerequisite.

The arithmetic validation catches extraction failures: if grand_total is present and the amounts don’t sum to it, a validation_error field routes the document to human review. Clean documents get processed automatically.

The Numbers

What This Actually Means

The lesson isn’t specific to document extraction. It’s about where complexity belongs in an AI pipeline.

Classification-and-branch architectures push complexity into orchestration. The prompt stays simple; the pipeline compensates. You pay for this with failure modes at every routing decision, with maintenance overhead on every branch, with no recovery path from a misclassification.

A reasoning model moves that complexity into the model itself — where it’s invisible, zero-maintenance, and doesn’t require you to enumerate every document type in advance. The model infers structure as part of generating output. That’s what it’s for.

The broader principle: if you’re building elaborate classification and branching logic to compensate for a model that can’t reason through the problem, you might have the wrong model. Pipeline complexity is often a symptom of model mismatch.

Universal schemas are worth looking for. Every money movement is from → to → amount. Every support ticket is symptom → severity → owner. Find the invariant in your domain. Build the schema around that, not around the document types.

And built-in validation catches what prompts miss. Extraction will fail occasionally. A deterministic check — arithmetic, referential integrity, required field presence — provides a reliable safety net without requiring extraction to be perfect.

The reasoning model didn’t just solve the problem. It simplified the entire pipeline.

Rich Wellman is a Solutions Architect at a major healthcare system, building AI automation on Azure. He writes about what actually works at richwellman.com.

The article is filled with case studies, but one stands out as particularly relevant to our current AI automation frenzy.

The Ford Story Nobody Remembers

Ford’s accounts payable department was gearing up for a standard efficiency project. The goal: reduce staff by 20%. Not bad for a corporate initiative. Management was feeling pretty good about the plan.

Then someone looked at Mazda.

Ford’s accounts payable department had 500 people. They were planning to cut that to 400.

Mazda’s accounts payable department had 5 people.

Not 500. Not 400. Five.

That’s not a 20% improvement. That’s a 99% improvement. And it’s the difference between automating a process and obliterating it.

The Lesson We Keep Forgetting

Ford didn’t get to Mazda’s numbers by automating their existing process. They couldn’t. You can’t automate your way from 500 people to 5 people by making the same process faster.

As Bill Gates famously said: “Automation applied to an efficient operation will magnify the efficiency. Automation applied to an inefficient operation will magnify the inefficiency.”

Ford had to completely reimagine how accounts payable worked. They had to question every assumption. They had to throw out the old process and start from scratch.

The technology—databases, computers, networks—was the small player in this story. The big player was the willingness to obliterate the old way of doing things.

Why This Matters Now

We’re living through the AI automation hype cycle. Companies are being told that AI will revolutionize their operations, eliminate inefficiencies, and cut costs dramatically.

And they will—if you do the hard work of reengineering first.

But most companies are making the same mistake Ford almost made. They’re taking their existing, inefficient processes and trying to automate them with AI.

The result? Automated inefficiency. Faster dysfunction. More expensive complexity.

The Mazda Advantage

Why was Mazda’s accounts payable department so small? They didn’t have the baggage of “the way we’ve always done it.”

Much of the Japanese economy had to rebuild from scratch after World War II. There were no legacy processes to protect. No entrenched departments to defend. No politics around “but we’ve always done it this way.”

They could start with a clean sheet and ask: “What’s the simplest possible way to accomplish this goal?”

That freedom led to radically simpler processes that required far fewer people.

The Automation Fairy Tale

Today’s automation vendors would have you believe their technology is pixie dust. Just sprinkle AI on your problems and watch them disappear.

It won’t work.

If your process is broken, automating it just means you’ll produce wrong answers faster. If your workflow is overcomplicated, adding AI just creates overcomplicated AI workflows.

The vendors selling you automation don’t want you to obliterate your process. They want you to automate your existing one. Why? Because that’s a technology sale. Obliteration requires consulting, change management, and hard thinking. That’s messy and expensive.

Buying software is easier than rethinking your business.

What Obliteration Actually Looks Like

Before you automate with AI, ask:

1. If we started from zero today, how would we do this? Don’t ask “how can we make our current process faster?” Ask “do we need this process at all?”

2. What’s the simplest version that could work? Ford’s existing process had multiple checks, approvals, and verification steps. Mazda eliminated most of them by redesigning the upstream process so they weren’t needed.

3. What are we doing because ‘that’s how it’s always been done’? Legacy processes often exist because of constraints that no longer apply. The approval chain that made sense when everything was on paper might be ridiculous when everything is digital.

4. Can we eliminate this instead of accelerating it? The fastest process is the one you don’t have to do at all.

The Database Didn’t Save Ford

Here’s what’s crucial: Ford and Mazda both had access to the same database technology. The technology wasn’t Mazda’s advantage.

The advantage was that Mazda designed their process around what was possible with the technology, while Ford was trying to use the technology to speed up their old process.

Sound familiar?

Today, everyone has access to the same AI models. OpenAI, Anthropic, Google—they’ll sell to anyone. The technology isn’t your competitive advantage.

Your advantage is being willing to obliterate your process and redesign it around what AI makes possible.

You Can’t Just Keep Doing What You’re Doing

Thirty years later, Hammer’s message is more relevant than ever.

You can’t just keep doing what you’re doing, automate it with AI, and hope to survive. Your competitors who are willing to reimagine their processes from the ground up will destroy you.

Not because they have better AI. Because they have better processes that happen to use AI.

Where to Start

If you’re serious about AI transformation:

1. Stop the automation projects. Pause any “let’s add AI to this process” initiatives.

2. Start with obliteration. Pick one inefficient process and ask: “If we could start over, how would we do this?”

3. Design for AI, don’t retrofit it. Build new processes that take advantage of what AI can do, rather than bolting AI onto old processes.

4. Measure end-to-end outcomes. Ford measured people in their department. Mazda measured cost per transaction and error rate. One metric encourages efficiency. The other encourages obliteration.

5. Be willing to throw everything out. The hardest part isn’t the technology. It’s having the courage to say “our current approach is fundamentally wrong.”

The Real Challenge

Thirty years ago, companies failed at reengineering not because they lacked technology. They failed because:

• They were unwilling to challenge sacred cows
• They protected departments and headcount
• They automated first, thought second
• They measured activity instead of outcomes

Today, companies are making the exact same mistakes with AI.

The question isn’t “how can we use AI to automate this process?”

The question is “what would this process look like if we designed it today with AI as a fundamental capability?”

One question gives you incremental improvement. The other gives you the Ford-to-Mazda leap.

Struggling to figure out where to start? I help companies identify which processes to obliterate and how to redesign them for AI-first operations. The goal isn’t just automation—it’s transformation that delivers measurable business results. Let’s talk about reimagining your processes before you automate them.

References

Hammer, M. (1990). “Reengineering Work: Don’t Automate, Obliterate.” Harvard Business Review, July-August 1990. https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate

About the author: Richard Wellman helps companies implement AI automation that delivers measurable business value. With experience in business process reengineering and enterprise transformation,he specializes in identifying processes that should be obliterated, not automated.

“If I had an hour to fix a problem I would spend 55 minutes on forming the question.”

— Often attributed to Albert Einstein (and variations to other luminaries)

Whether Einstein actually said this or not, the principle is profound. And nowhere is it more relevant than in prompt engineering.

The Problem with Most Prompts

Most people treat AI like a search engine. They type in a quick question, hit enter, and hope for useful results.

“Write me a sales email.”

“Analyze this data.”

“Create a marketing plan.”

The AI dutifully generates something. It’s grammatically correct. It looks professional. And it’s completely useless because the question was lazy.

Garbage in, garbage out—but with better grammar.

Prompt Engineering is Problem Definition

The real work of prompt engineering isn’t learning special syntax or magic words. It’s the discipline of clearly defining what you actually want.

This is hard. It requires you to:

• Know your desired outcome
• Understand your constraints
• Define your criteria for success
• Provide relevant context
• Anticipate edge cases

In other words, it forces you to think clearly about the problem before demanding a solution.

That’s why spending 55 minutes on the question isn’t wasted time. It’s the work.

Bad Prompt vs. Good Prompt

Bad Prompt:

Write a sales email.

Good Prompt:

Write a sales follow-up email for a B2B SaaS prospect who attended our webinar
on AI automation but didn't respond to our first outreach.

Constraints:
- Keep it under 150 words
- Don't mention pricing (that's for the call)
- Reference specific value from the webinar content
- Include a soft ask for 15-minute discovery call

Tone: Professional but conversational, not salesy

Context: This prospect is a VP of Operations at a 200-person manufacturing
company. They're exploring AI but don't have internal expertise. Our
differentiation is practical implementation vs. theoretical consulting.

Which one will give you a better result?

The second prompt took 5 minutes to write. It will save you 30 minutes of editing generic AI output into something actually useful.

The Five Questions Framework

Before you write a prompt, answer these five questions:

1. What is the specific output I need?

Not “a blog post” but “an 800-word blog post formatted for LinkedIn with 3 actionable takeaways and a CTA to book a consultation.”

2. Who is the audience?

Not “people” but “CFOs at mid-market companies who are skeptical of AI hype and need to see ROI in months, not years.”

3. What context does the AI need that I have in my head?

The AI doesn’t know your industry, your company, your product, or your customer’s pain points. You have to provide that.

4. What constraints or requirements apply?

Length limits, tone requirements, format specifications, things to avoid, compliance requirements.

5. How will I know if the output is good?

What criteria will you use to evaluate it? Define those upfront.

Examples in Practice

Example 1: Data Analysis

Lazy prompt:

Analyze this sales data.

Better prompt:

Analyze Q4 sales data to identify:
1. Which product lines underperformed vs. target
2. Whether the decline was due to volume or pricing
3. Geographic patterns in the decline
4. Correlation with sales rep tenure

Format findings as an executive summary with:
- 3 key insights (bullets, not paragraphs)
- Supporting data table
- 2 recommended actions

I need this for Thursday's board meeting, so focus on findings that
suggest concrete actions we can take in Q1.

Example 2: Code Generation

Lazy prompt:

Write a Python script to process CSV files.

Better prompt:

Write a Python script that:
- Reads CSV files from /data/input/ directory
- Filters for rows where status = "complete"
- Calculates total revenue by product category
- Outputs summary to /data/output/summary.csv

Requirements:
- Handle missing values gracefully
- Log errors to /logs/processing.log
- Use pandas library
- Include error handling for file not found
- Add comments explaining each major step

Input CSV format: date, product_id, category, revenue, status
Output CSV format: category, total_revenue, row_count

Example 3: Strategic Thinking

Lazy prompt:

Help me think through this business problem.

Better prompt:

I need to decide whether to build our AI evaluation capability
in-house or partner with an existing vendor.

Context:
- We have 2 engineers with ML experience
- Current projects need eval framework within 2 months
- Budget: $50K for tools/services this quarter
- Long-term: expect 5-10 AI projects per year

Help me think through:
1. Build vs. buy tradeoffs specific to our situation
2. What capabilities we'd need in-house either way
3. Risks I might be overlooking
4. What decision criteria I should use

Challenge my assumptions. I'm biased toward building because
I like having control, but that might not be the right call here.

The ROI of Better Prompts

Time spent on prompt: 5 minutes Time saved editing mediocre output: 30 minutes Quality improvement: Significant

But the real value isn’t time savings. It’s forcing yourself to think clearly about what you actually need.

Often, when you sit down to write a detailed prompt, you realize:

• You don’t actually know what good looks like
• You haven’t defined your constraints
• You’re asking the wrong question entirely
• You need to gather more information first

That’s valuable. That’s 55 minutes well spent.

What Good Prompt Engineering Looks Like

Good prompt engineers don’t memorize special techniques. They:

1. Define the problem clearly before asking for solutions
2. Provide context the AI can’t infer
3. Specify constraints and success criteria
4. Iterate on prompts based on output quality
5. Build libraries of proven prompt patterns
6. Test edge cases to find where prompts break

It’s less “prompt hacking” and more “clear thinking.”

Common Prompt Engineering Mistakes

Mistake 1: Assuming the AI knows your context

The AI doesn’t know your business, your industry, your customers, or your goals. You have to tell it.

Mistake 2: Being vague about what “good” means

If you can’t describe what good output looks like, the AI can’t produce it.

Mistake 3: Not specifying format

“Write a report” could mean anything from 2 paragraphs to 50 pages. Be specific.

Mistake 4: Asking for multiple unrelated things

One prompt, one clear output. If you need multiple things, use multiple prompts.

Mistake 5: Not iterating

First prompts rarely nail it. Refine based on what you get back.

Advanced: Chain of Thought and Structured Prompts

Once you master basic prompt clarity, you can use advanced techniques:

Chain of Thought:

Before answering, think through:
1. What are the key constraints?
2. What assumptions am I making?
3. What could go wrong?
Then provide your recommendation.

Few-Shot Learning:

Here are 3 examples of good outputs:
[Example 1]
[Example 2]
[Example 3]

Now create one for this new scenario: [details]

Role-Based Prompting:

You are a CFO evaluating AI project ROI. Analyze this proposal with
a focus on financial risk, capital requirements, and payback period.

But these are techniques, not fundamentals. The fundamental is: spend time on the question.

The Meta-Lesson

Prompt engineering teaches a valuable skill that applies beyond AI: the ability to clearly articulate what you want.

How many meetings meander because nobody defined the desired outcome?

How many projects fail because requirements were vague?

How many emails get ignored because the ask wasn’t clear?

Prompt engineering is just clear thinking in written form.

And in an age where AI will do increasingly sophisticated tasks, your ability to clearly define the problem becomes your competitive advantage.

Anyone can type “write me a thing.”

The value is in knowing exactly what thing you need and why.

That’s the 55 minutes. That’s the work.

Practical Exercise

Take something you’d normally ask AI to do. Before you write the prompt, spend 5 minutes answering:

1. What specific output do I need?
2. Who is this for?
3. What context is missing?
4. What makes output “good”?
5. What constraints apply?

Then write the prompt.

Compare the quality of output to what you’d get from “just ask it something quick.”

The difference is the ROI of thinking before prompting.

Need help implementing AI that actually delivers value? I help companies build AI systems with proper evaluation frameworks and business metric alignment—which starts with asking the right questions. Let’s talk about making your AI projects work.

Rich Wellman is a Solutions Architect at a major healthcare system, building AI automation on Azure. He writes about what actually works at richwellman.com.