Outcome Delegation Prompt Framework

The biggest shift in 2026 prompting isn't a new trick — it's an inversion. Instead of writing detailed step-by-step instructions (which constrain the model to your solution path), you define the outcome, the constraints, and the quality bar, then let the model determine the best approach.

This works because frontier models (Claude 4, GPT-5, Gemini 2.5 Pro) are now strong enough to plan and execute autonomously — but only if you stop micromanaging them.

---

The Framework

Use this structure for any task you'd normally over-specify:

## Outcome
[One sentence: what does "done" look like? Be specific and measurable.]

## Context
[What the model needs to know to succeed. Domain knowledge, existing state, relevant history. Include what you'd tell a smart new hire on their first day.]

## Constraints
- [Hard boundaries the solution must respect]
- [Things that are NOT acceptable]
- [Resource/time/scope limits]

## Quality Bar
[How will you evaluate the output? What separates "good enough" from "excellent"? Include examples of what good looks like if possible.]

## Anti-Patterns
[Common mistakes or approaches you've seen fail. Things that look right but aren't.]

## Autonomy Level
[How much freedom does the model have?]
- FULL: Choose any approach, tools, format
- GUIDED: Choose approach within these options: [list]
- CONSTRAINED: Follow this general method but optimize within it: [method]

---

Example: Code Refactoring

Bad (step-by-step micromanagement):

1. Find all functions longer than 50 lines
2. Extract helper functions from them
3. Add type hints to all parameters
4. Write docstrings for each new function
5. Run the linter and fix issues

Good (outcome delegation):

## Outcome
The auth module should be readable enough that a new engineer can understand
the login flow in under 10 minutes, without asking anyone questions.

## Context
This is a FastAPI auth module handling JWT tokens, OAuth2, and session
management. It grew organically over 18 months. Three engineers have
contributed. No one fully understands all the edge cases anymore.

## Constraints
- Zero behavior changes — all existing tests must pass unchanged
- No new dependencies
- Keep the public API surface identical (same function signatures)
- Python 3.12+, use modern syntax

## Quality Bar
- No function exceeds 30 lines
- Every public function has a one-line docstring explaining WHAT, not HOW
- Related logic is grouped into clearly-named private functions
- A new reader can trace the happy path (login → token → session) linearly

## Anti-Patterns
- Don't create a "utils.py" dumping ground
- Don't add abstraction layers that don't reduce complexity
- Don't refactor error handling into a generic handler — keep errors
  contextual and specific

## Autonomy Level
FULL — restructure however you see fit, as long as tests pass.

---

Example: Content Creation

## Outcome
A LinkedIn post that generates meaningful conversation (10+ thoughtful
comments, not just "Great post!") about why most AI demos are misleading.

## Context
Audience: technical founders and senior engineers (2,000 followers).
My voice: direct, slightly contrarian, no jargon, no emojis. I've posted
about AI skepticism before — this should build on that reputation, not
repeat previous points.

## Constraints
- Under 1,300 characters (LinkedIn truncation limit before "see more")
- No "I" in the first line — start with the provocative claim
- No hashtags
- Must include one specific, verifiable example (not hypothetical)

## Quality Bar
- A CTO should want to screenshot it and send it to their team
- The take should be defensible under pushback, not just inflammatory
- It should NOT read like it was written by AI

## Anti-Patterns
- Don't start with "Unpopular opinion:" or "Hot take:"
- Don't use the word "landscape"
- Don't end with a question that feels like engagement bait

## Autonomy Level
FULL — write it however you'd write it. I trust the voice.

---

Example: Research & Analysis

## Outcome
A decision memo that tells me whether to use Postgres or DynamoDB for our
event sourcing system, with enough detail that I can defend the choice in
a technical review.

## Context
We're building an event-sourced system handling ~50K events/day initially,
projected 2M/day in 12 months. Team of 4, all strong with Postgres, one
has DynamoDB experience. Running on AWS. Budget-conscious but not
penny-pinching.

## Constraints
- Consider only these two options (we've already ruled out others)
- Factor in team expertise as a first-class concern, not an afterthought
- Include cost estimates for both at 50K and 2M events/day

## Quality Bar
- Recommendation should be clear and opinionated, not "it depends"
- Every claim should be backed by a specific technical reason
- Include the strongest argument AGAINST your recommendation and address it
- Under 800 words

## Anti-Patterns
- Don't list generic pros/cons — those are googleable
- Don't hedge with "both are great choices"
- Don't ignore the team expertise factor to give a "technically pure" answer

## Autonomy Level
FULL — structure the memo however makes the argument clearest.

---

Why This Works

1. Models are better planners than you think. When you give step-by-step instructions, you're capping the model's performance at your own problem-solving ability. Outcome delegation lets the model find paths you wouldn't have considered.

2. Constraints > instructions. Telling a model what NOT to do is more information-dense than telling it what to do. A constraint eliminates entire solution spaces instantly.

3. Quality bars create self-correction. When the model knows what "good" looks like, it can evaluate its own output before delivering it. Without a quality bar, it has no internal benchmark.

4. Anti-patterns prevent the obvious failure modes. Every domain has cliches and traps. Naming them explicitly saves a round-trip of "no, not like that."

5. Autonomy levels set expectations. Sometimes you want creativity, sometimes you want precision within bounds. Making this explicit prevents the model from either over-constraining itself or going rogue.

---

When NOT to Use This

• Safety-critical tasks: If the exact procedure matters (medical, legal, financial compliance), specify the procedure.
• Simple tasks: If you need a regex or a format conversion, just ask directly. Don't over-framework a one-liner.
• When you know the best approach: If you're an expert and the optimal path is clear, step-by-step is fine. Outcome delegation shines when the solution space is large.