D4 · Choosing the Right Capability

This is the heaviest domain on the mock — 20%, roughly 10 of 50 items — and it is the section the Applied AI material calls out as the single most valuable thing to master. It tests one judgment repeatedly: given a task, what should you actually build it with? The answer runs along a ladder from the lightest option (a well-written prompt) to the heaviest (an API application), and the skill is reaching for the lightest capability that meets the need rather than the most impressive one.

What you need to know

ChatGPT offers a ladder of ways to package a workflow: a one-off prompt, a saved instruction (custom instructions / a reusable prompt), a Project (a workspace with its own instructions and knowledge files for recurring context), a custom GPT (a shareable, configured assistant for a repeatable task others can run), a workspace agent (delegated multi-step work with oversight), and — when you outgrow ChatGPT — an API application (programmatic, integrated, scalable). Orthogonal to that ladder are in-conversation capabilities you switch on when a task needs them: search for current facts, deep research for sourced multi-source synthesis, data analysis for computation over files, Canvas for iterating on a document or code, and file uploads for working over your own documents. The winning judgment is to climb the ladder only as far as repeatability, sharing and integration actually demand.

Learning objectives

By the end of this page you should be able to:

1. Place a task on the prompt → saved instruction → Project → custom GPT → workspace agent → API application ladder.
2. Justify choosing the lightest rung that meets the need, and recognise over- and under-reaching.
3. Select the right in-conversation capability — search, deep research, data analysis, Canvas, file uploads — from signals in the task.
4. Distinguish a Project from a custom GPT, and a custom GPT from a workspace agent.
5. Decide when a workflow has outgrown ChatGPT and belongs in an API application.

4.1 The capability ladder

LIGHTEST ─────────────────────────────────────────────────────► HEAVIEST
 Prompt      Saved         Project        Custom GPT     Workspace     API
 (one-off)   instruction   (recurring     (shareable,    agent         application
             (reusable)    context +      configured     (delegated    (programmatic,
                           knowledge)     assistant)     multi-step)    integrated)
 ▲                                                                            ▲
 use for a   use when you  use when a     use when       use when a     use when it
 single      repeat the    task needs     OTHERS run     multi-step     must run in
 task        same prompt   its own        the same       task can be    code, at scale,
             often         context/files  task without   delegated w/   or wired into
                           every time     you            oversight      other systems

Each rung adds capability and cost (setup, maintenance, governance). The default posture is: start at the left, move right only when a concrete need forces you.

4.2 Prompt vs saved instruction vs Project

The first three rungs are all inside your own ChatGPT use; the difference is what persists.

Worked example. You write a weekly digest that always needs the team’s style guide and last quarter’s OKRs.

• Prompt each time: you re-paste the style guide and OKRs weekly — wasteful and error-prone.
• Saved instruction: the ask is saved, but you still attach the files each time.
• Project: the style guide and OKRs live as knowledge files; the Project instruction says “produce the Friday digest in the house template.” You just drop in the week’s updates. This is the right rung — recurring context is exactly what a Project is for.

4.3 Project vs custom GPT

Both hold standing instructions and knowledge. The dividing question is who runs it.

Do OTHER people need to run this task, on their own, without you?
│
├─ No  ─► PROJECT      (your recurring workspace; shareable within your team
│                       as a shared project, but centred on your work)
│
└─ Yes ─► CUSTOM GPT   (a packaged assistant others invoke; configured once,
                        used by many; can be shared across the workspace)

A Project is your recurring context. A custom GPT is a product you hand to others: it wraps the instructions, knowledge and behaviour so a colleague gets consistent results without knowing how you set it up. If the answer to “who runs it” is “just me, repeatedly”, a Project is lighter and sufficient; building a custom GPT is over-reaching.

4.4 Custom GPT vs workspace agent

A custom GPT still responds to a person turn by turn. A workspace agent executes a multi-step task on your behalf, using tools and connectors, under oversight.

Reach for a workspace agent only when the task genuinely has steps to execute, not just questions to answer — and always with the oversight design from Domain 5.

4.5 When to leave ChatGPT for an API application

ChatGPT stops being the right container when the workflow must be embedded, scheduled at scale, integrated, or governed programmatically.

The trap is jumping to “build an API app” for a task a Project or custom GPT handles. Building software has real cost; it is justified by scale, integration and programmatic control — not by ambition.

4.6 In-conversation capabilities — the second axis

Independent of which rung you are on, a task may need a specific capability switched on. Match the signal to the capability.

4.7 Context and the cost of over-reaching

Heavier rungs cost more than money. A Project must be maintained (stale knowledge files mislead), a custom GPT shared across a workspace needs governance, an agent needs oversight design, an API application needs engineering and monitoring. Over-reaching front-loads cost you may never recoup; under-reaching (a one-off prompt for a task ten people run weekly) wastes time and produces inconsistent results. The right rung minimises total cost — build + maintain + govern — for the need actually present.

Decision framework

The LADDER question set — ask in order; the first “yes” that adds a genuine need moves you up one rung.

Stop at the lowest rung whose need is truly present. If only L is yes, a saved instruction is the answer — not a custom GPT because it “might be useful to others someday”.

Common mistakes

Scenario challenge

Scenario. Marcus supports a 30-person sales team. Every Monday he compiles a “deal-risk digest”: he pulls each rep’s notes, checks the latest news on the top five accounts, computes which deals slipped versus last week from the CRM export, and writes a one-page summary in the team’s template with the style guide applied. Today he does it all as fresh prompts, re-pasting the style guide and template each time, and it takes two hours. Leadership now wants every rep to self-serve a personal version, and wants the whole thing to eventually run automatically each Monday morning and post to Slack. Marcus’s manager says “just build an API application for the whole thing”.

Expert reasoning trace.

1. Separate the two decisions. There is a packaging question (which rung) and a capability question (what to switch on) — and there are actually two different consumers now: Marcus’s own recurring work, and the reps’ self-serve version, and a future automated version. They may sit at different rungs.
2. Fix Marcus’s own recurring work first — it’s a Project. Re-pasting the style guide and template weekly is the classic Project signal (A — same context every time). Put the style guide, template and last-week’s-baseline as knowledge files in a Project; Marcus drops in this week’s notes. That alone kills most of the two hours. Jumping straight to an API app for his task is over-reaching.
3. Assign the in-conversation capabilities. “Latest news on top accounts” → search (current facts), not deep research, since it’s a quick current-facts pull per account. “Which deals slipped vs last week from the CRM export” → data analysis (computation over an uploaded file), not just file upload. The write-up in the template is plain generation; iterating it could use Canvas.
4. Handle the reps’ self-serve version — that’s a custom GPT. “Every rep runs a personal version themselves, without Marcus” is the defining custom-GPT signal (D — others run it). Package the instructions and shared knowledge into a workspace-shared custom GPT so each rep gets consistent output. It is lighter than an API app and exactly fits “others run the same task.”
5. Only the automated Monday-morning-to-Slack version justifies the API. “Run automatically on a schedule and post to Slack” is embedding + scheduling + integration (E) — that is the one piece that genuinely outgrows ChatGPT and belongs in an API application (with the Responses API, tools/connectors, and Batch/Flex if volume grows). But that is a future piece, not “the whole thing today.”
6. Reject the manager’s one-shot API answer. Building an API app for all of it front-loads engineering and governance cost for parts (Marcus’s own digest, the reps’ self-serve) that a Project and a custom GPT handle far more cheaply. Right-sizing means: Project now, custom GPT for reps, API only for the scheduled integration when it’s actually needed.

The decision: a Project (with search + data analysis + Canvas) for Marcus’s recurring digest, a shared custom GPT for reps to self-serve, and an API application only for the future scheduled Slack automation — not a single API application for everything. Each need maps to the lightest rung that satisfies it.

Assessment traps

Practice questions

Each item states how many responses to select. Commit before revealing.

Key takeaways

• The capability ladder runs prompt → saved instruction → Project → custom GPT → workspace agent → API application; reach for the lightest rung that meets the need.
• Project vs custom GPT turns on who runs it: your recurring context is a Project; a task others run themselves is a custom GPT.
• Custom GPT vs workspace agent turns on answer vs execute: a GPT responds turn by turn; an agent executes multi-step work under oversight.
• Leave ChatGPT for an API application only when the workflow must be embedded, scheduled at scale, integrated, or programmatically governed.
• The second axis is in-conversation capability: search (current facts), deep research (sourced synthesis), data analysis (computation over files), Canvas (iterating on a doc/code), file uploads (your documents).
• Don’t confuse search (quick, current) with deep research (long, sourced), or file uploads (read) with data analysis (compute).
• Over-reaching front-loads build/maintain/govern cost; under-reaching wastes time and yields inconsistent results — right-size to the need actually present.