You have a niche with a real awkward job. The temptation now is to ship a prompt box: "ask AI about your workflow." Resist it. A model capability is an ingredient. The application is the workflow that makes that ingredient dependable — the steps, evidence, permissions, and recovery around it.

Six terms, plainly

• Model call: one request to a model — draft, classify, summarize, extract, reason — and its reply. Clever, variable, forgetful.
• Workflow: the repeatable sequence that turns an input into a trustworthy outcome: retrieve, check, decide, record, notify, revisit.
• Orchestration: coordinating steps and tools in order — which runs first, what feeds what, what happens on failure. (Part VIII taught the machinery; here it serves the product.)
• Human approval: a named person saying yes before a consequential step runs. Not vibes — a recorded decision.
• Automation: steps that run without a human because the policy, bounds, and recovery are settled.
• System of record: where the truth lives after the work is done — the saved brief, the ticket state, the ledger. If it is not recorded, it did not happen.

The model drafts. The workflow delivers.

Research Desk: not "ask about AAPL"

Take the course's running example. The useless version is a chat box: "ask a model about AAPL." The answer is fluent, unsourced, unrepeatable — and nobody stakes a decision on it.

The useful product is everything around the call:

• Approved source retrieval — which sources are allowed, how freshness is checked, what is excluded.
• Provenance — every claim carries a visible link back to its source, so the reader can verify rather than trust.
• Consistent research structure — the same brief skeleton every time (business, financials, risks, sources), so comparison across companies works.
• Saved context — notes, preferences, and prior briefs persist per user, privately.
• Private watchlist — the state that brings the user back: saved companies, refresh status, what changed.
• Refresh behavior — when a brief re-fetches, what counts as new, what is cached and why.
• Bounds on claims — what the brief may say (organized source information) and may not (no financial advice, no pretending to decide).

None of those are model features. All of them are why someone returns. Strip them away and you have a demo; keep them and you have Lesson 54.1's application: a specific person finishing a recurring job with a trustworthy outcome.

Support Desk: summarize is the easy part

The same pattern holds inside organizations. An AI can summarize fifty support tickets in seconds — genuinely useful, genuinely not a product. The application value comes from the workflow around the summary:

• Routing — which queue, which priority, which owner, by what rule.
• Approval — who confirms the suggested reply or refund before it sends.
• CRM context — account history, plan, prior tickets attached automatically so the agent decides with memory, not amnesia.
• Escalation — the defined path when confidence is low or value is high: who gets woken, with what packet.
• Audit trail — what was suggested, what was sent, who approved, when. Regulators and managers both ask this question eventually.
• Correction — a human can fix a mistake and the fix feeds back: the log, the template, the rule that changes.

A team buys that system. Nobody buys "summarize" alone, because summarize without routing, approval, and audit is a faster way to send the wrong answer.

Predictable and controlled beats clever

Users value predictable outcomes and control more than a clever one-off answer. Models vary — same prompt, different Tuesday, slightly different reasoning. A product cannot inherit that variance; it must absorb it with context, evidence, policy, and feedback:

• Context narrows what the model may consider (approved sources, the user's saved state).
• Evidence lets the user check the result (citations, quotes, links).
• Policy sets what may happen automatically and what needs approval.
• Feedback captures corrections and turns them into better defaults, checks, or prompts.

A boring product that behaves the same way every Friday wins over a brilliant one that surprises you monthly. Surprise is for demos. Dependability is for renewals.

Where agents fit — narrowly

Connect to Part VIII carefully. An agent becomes useful when it owns one narrow step with all of the following:

• Tools limited to that step (read the queue, fetch the order, draft the reply — not "access everything").
• Memory scoped to the job (this ticket's history, this user's preferences — not the whole company).
• Limits stated up front (max actions, spend caps, time bounds, escalation triggers).
• Review by a human at the consequential point.
• A visible stop condition — done, blocked, or escalated; never spinning forever.

"An agent that runs the business" is a demo script. An agent that triages inbound tickets into three queues, drafts replies, and stops for approval on refunds above $50 is a product step. Map the step before you grant the autonomy.

Exercise: draw WORKFLOW-MAP.md

Pick one AI capability inside your niche idea (summarize, extract, draft, classify). Map every non-model step around it:

# WORKFLOW-MAP.md

## Capability (one model call)
- The model does:

## Inputs
- User provides:
- System provides (sources, context, defaults):

## Data source + provenance
- Where data comes from, how freshness/permission is checked:
- How claims link back to evidence:

## Policy + human decision
- Auto-allowed:
- Needs approval (who, threshold):

## Output + stored state
- Finished output:
- System of record (what is saved, where, for whom):

## Monitoring + recovery
- What is observed (usage, errors, corrections):
- What happens when wrong or unavailable:

Finish line: a WORKFLOW-MAP.md with inputs, source, policy, decision, output, state, monitoring, and recovery — showing why the product is more than a prompt box.

Verify fast: cover the "capability" row and ask whether the remaining map still describes something useful. If yes, you built a workflow. If the page goes blank, you built a wrapper. Common failure: skipping recovery ("the model is usually right"). Usually is not a reliability plan — write the wrong-answer path.

Check your understanding

1. What is the difference between a model call and a workflow? 2. Name three non-model steps that make Research Desk return-worthy. 3. In the support example, why is the audit trail part of the product value, not overhead? 4. What five properties must a narrow agent step have before it earns autonomy?

Next

A dependable workflow is hard to build — which is exactly why it is hard to copy. Next, Lesson 55.4 turns that difficulty into strategy: a feature is easy to copy, but a useful system is harder, and durable advantage comes from identifiable, evidence-backed sources.