Market 1: Traditional knowledge work — standard PMs, conventional SWEs, business analysts, general administrators. Job openings: flat or falling.

Market 2: AI-native roles — people who design, build, operate, and manage AI systems. Growing fast. Extremely in demand.

"There are essentially infinite AI jobs right now. Not growing demand. Not a hot sector. Functionally infinite. And they cannot find qualified people."
— Nate Jones, source research

Not all job postings are real. Nate Jones found:

• Resume farming: Companies post AI roles they don't intend to fill, using applications as free labor to learn what candidates know
• Whitewashed roles: "AI PM" but actually just regular PM with AI tools
• Overstated skills: Candidates claiming AI expertise they don't have

The skill framework in this course is specifically designed to cut through this noise — these are learnable skills tied to how AI actually works.

Humans read between the lines. We infer intent from context, body language, past conversations. Agents don't. They take what you give them literally and fill in the rest with their best guess.

The result: Vague prompt → plausible-sounding output that misses your actual goal → you assume the AI is smart enough to figure it out → it wasn't.

Here's the difference between what most people call "prompting" and what employers mean by specification precision:

❌ Vague:
"Help with customer support"

✅ Precise:
"Build a tier-1 ticket agent that:
- Handles password resets (account verification required)
- Handles order status inquiries (read-only, no changes)
- Handles return initiations (orders < 30 days, original packaging)
- Escalates to human when: sentiment score < 0.3 OR
  ticket involves billing disputes > $200 OR
  customer uses keyword 'lawyer' or 'attorney'
- Logs every escalation with reason_code and customer_sentiment_score
- Never: issue refunds, change shipping addresses, share internal pricing"

The vague version takes 5 seconds to write. The precise version takes 10 minutes. The precise version is what gets hired.

The key insight: specification is not about the AI. It's about knowing what you want.

• Before every AI interaction, write down what you expect the output to look like
• If you can't describe what you want in writing, the AI can't produce it
• Test: could a new hire execute this from your prompt alone? If not, it's too vague
• Get feedback: show your specs to someone in your field and ask what's missing

Humans stumble when they're wrong. We hesitate, qualify, backtrack. AI doesn't. AI generates text that looks exactly the same whether it's right or wrong. The confident tone implies correctness — and it's a lie.

The skill: Resisting the temptation to read fluency as competence. Building internal barometers for quality that don't depend on how confident the AI sounds.

Semantic: "The AI said the right things" — the output sounds correct, uses the right terminology, follows the right structure.

Functional: "The AI did the right thing" — the output achieves the actual goal, the data is accurate, the recommendation is valid.

Example: An AI recommends a credit card. It explains its reasoning perfectly. Semantically correct. But the card it recommends doesn't exist in the system. Functionally wrong.

This gap — between "sounds right" and "is right" — is where evaluation lives.

An eval framework is a systematic quality barometer for AI output.

For any AI task, define:

• What correct looks like — 3 to 5 concrete criteria
• What borderline looks like — acceptable but not ideal
• What failure looks like — detectable, specific failure modes
• What edge cases look like — the 10% of situations that break the general case

Example: Code Review Agent Eval

Criteria:
✓ All security vulnerabilities caught (OWASP Top 10)
✓ Performance issues flagged (> O(n²) without justification)
✓ Style deviations from team guidelines noted
✓ Every "LGTM" has a specific reason, not rubber-stamp approval

Edge cases that should fail:
✗ Silent approval of code with known CVEs
✗ Missing error handling in async code
✗ Approving code that contradicts PR description

A single agent has hard limits: context window size, task complexity it can hold in memory, and number of steps it can execute before losing the thread. Complex projects — "build our entire customer onboarding flow" — can't be done by one agent in one shot.

The solution: Decompose the project into discrete tasks, each handled by a specialized agent, coordinated by a planner that maintains state across the full run.

Human managers: "Figure out the details as you go. Use your judgment." Agents can't do this.

Human PM decomposition:
"Go handle the product launch. 
You know what needs to happen. 
Loop in marketing when you need them."

Agent decomposition:
"Planner Agent:
1. Coordinate sub-agents for: market research, 
   competitor analysis, pricing strategy, 
   content calendar, launch checklist, 
   post-mortem template
2. Each sub-agent receives exact task specs
3. Each sub-agent returns output to planner
4. Planner verifies output quality before 
   proceeding to next task
5. If any sub-agent fails twice, escalate to human"

The decomposition is the product spec for the multi-agent system. Bad decomposition = system that fails in predictable ways.

Every decomposition has a hidden question: "Is this task correctly sized for the agentic harness I have?"

Give a too-large task to a single agent → it loses track, starts improvising, produces confident nonsense.

This one deserves extra attention. It's the one that ships to production and causes problems for weeks before anyone notices.

The fix: Functional correctness checks, not just semantic ones. Does this recommendation actually work in the real world?

Where does the blast radius of a failure meet acceptable risk? Every AI action needs an answer to this before it goes live.

The problem: Telling an agent "be good" in a system prompt doesn't work. These are probabilistic systems. Guardrails have to be structural, not aspirational.

Pattern 1: Human-in-the-loop at boundaries
------------------------------------------
Agent recommends → Human approves → Action executes
Used for: High-cost, irreversible, or high-frequency actions

Pattern 2: Pre-flight verification
------------------------------------------
Agent prepares output → Verification agent checks →
  Pass: proceed | Fail: return for revision
Used for: Outputs that go to external customers

Pattern 3: Output constraints in system prompt
------------------------------------------
"[CONSTRAINTS]
- Never mention internal pricing
- Escalate legal questions to human
- Confirm dollar amounts with user before proceeding
- Never store PII in logs
[/CONSTRAINTS]"
Used for: Behavior that must always apply

Pattern 4: Rollback-capable transactions
------------------------------------------
Action → Log for audit → Verify → Commit | Revert
Used for: Database writes, external API calls

In 2024, "using AI at work" meant pasting the right documents into the prompt. In 2026, it means building systems where the right information is always available to agents — structured, clean, and traversable.

Context architecture is the discipline of designing that information layer so agents can self-serve what they need — without human hand-holding.

Persistent context: Always available to the agent — company policies, product knowledge base, team roster, past interaction history. Loaded once, used forever.

Per-session context: Loaded for a specific run — the user's current request, session-specific data, task-relevant documents. Refreshed each session.

Persistent Context (always available):
├── Company policies (HR, legal, security)
├── Product documentation
├── Team directory + responsibilities
├── Escalation paths
└── Historical decisions + rationale

Per-Session Context (loaded per task):
├── Current user request
├── Relevant documents for this task
├── Session-specific variables
└── Handoff data from previous agents

Dirty data in context = confused agents = confident wrong output. If your product database has outdated prices, your agent will recommend outdated prices — confidently.

Context architecture includes:

• Data freshness: When was this data last updated?
• Source of truth: Which system is authoritative?
• Confidence signals: How certain should the agent be about this data?
• Escalation triggers: When should the agent flag data as unreliable?

Before building any AI feature, you need to answer: Is it worth it?

Cost per task = (tokens_used × model_price) + overhead

ROI = value_of_task / cost_per_task

Break-even: cost_per_task < value_of_task

The model selection problem: Frontier models (Claude Opus, GPT-4.5) give the best quality but cost more. Cheap models (Llama, Haiku) cost less but may be wrong more often. The skill is matching model to task correctly.

The practical skill: build a tool (spreadsheet, script, or dashboard) where you can change variables and see blended cost across models instantly.

Token Cost Calculator Template:

Task: [describe task]
Estimated tokens: [your estimate]

Model          | $/1M tokens | Your cost
------------------------------------
GPT-4.5        | $2.50       | [calc]
Claude Haiku   | $0.25       | [calc]
Claude Sonnet  | $3.00       | [calc]
Llama 4        | $0.10       | [calc]

Volume: [tasks/day] × [days/month] = [monthly_tasks]
Monthly cost at each tier: [calc]

Break-even value per task: [value] / [monthly_tasks]

• I can write exact specs that agents execute without clarification
• I test my prompts as if a new hire will read them
• I've documented prompting standards for my team

• I catch AI errors before they reach production
• I build eval frameworks for AI tasks
• I understand the difference between semantic and functional correctness

• I can break complex projects into agent-sized chunks
• I understand planner/sub-agent architectures
• I've built at least one working multi-agent system

• I can identify which of the 6 failure modes is occurring
• I build correction loops into my agentic systems
• I've diagnosed a silent failure in production

• I map blast radius for every agent action
• I know where humans stay in the loop for my systems
• I've built guardrails that hold under adversarial input

• I can design context systems for scalable agent deployments
• I understand persistent vs. per-session context
• I think like a librarian when structuring company data for AI

• I can estimate token costs before building agents
• I select models based on task requirements, not just "best available"
• I've built tools to calculate blended AI costs

• Anthropic Prompt Engineering Guide — anthropic.com
• OpenAI API Best Practices — platform.openai.com
• Google's ML Product Guidelines — machine-learning-principles

• Anthropic Engineering Blog — especially the eval writing posts
• Braintrust / Helicone — eval tooling for AI
• OpenAI Evals — open source eval library

• CrewAI documentation — crewai.com
• LangGraph examples — langchain.com/langgraph
• Nate Jones' agent architecture videos (his YouTube channel)

• Search "Claude loops" on Twitter/X — real failure examples
• Claude documentation on agentic patterns
• LangChain troubleshooting guides

• OWASP Top 10 for LLMs — owasp.org
• Anthropic's AI safety guidelines
• OpenAI's use-case-specific safety guidelines

• RAG tutorials — Retrieval Augmented Generation explainers
• Pinecone / Weaviate / Chroma — vector DB tutorials
• "What is a vector database" explainers (Hacker News)

• OpenRouter model pricing page — openrouter.ai/models
• Anthropic pricing — console.anthropic.com/pricing
• OpenAI pricing — platform.openai.com/pricing
• Tiktoken — token counting library

• Claude Certified Architect — growing fast, Accenture-backed, likely becomes the "AWS cert" of AI roles
• AWS Machine Learning Specialty — enterprise credibility
• Google Cloud Professional ML Engineer — if you're GCP-native

• AI Builders Slack — search "AI Builders Slack invite"
• CrewAI / LangChain Discord servers
• Nate Jones' hiring board (when it launches — check his Substack)