Most operator-builder upskilling plans fail the same way: a sprawling list of tools to learn, no sequencing, no shipping milestones, no artifacts at the end. This three-month plan does the opposite. Twelve weeks. Three platform tracks. One shippable artifact every single week. By day 90 you have the four portfolio pieces from the previous lesson and a credible interview narrative. The plan assumes ten to fifteen hours a week of focused practice on top of your existing job. It works for both coders and non-coders; the platforms differ but the milestones do not.

The Shape of the Plan

Twelve weeks split into three four-week blocks. Each block has one focus, one tool family, and one weekly shippable artifact.

• Weeks 1-4 — Workflow Platform: learn one workflow platform deeply enough to ship a real agent. End of block: a deployed agent solving a real problem with three or more tools.
• Weeks 5-8 — Evals + Observability: add the engineering discipline. Pick one eval tool and one observability tool. End of block: a 60-100 case eval set, scored on every change, with traces in a real observability UI.
• Weeks 9-12 — MCP Server + Governance: build one portable integration and write the governance documentation. End of block: an MCP server with a hosted endpoint, plus a Blast Radius + FRIA stub document.

That is the entire framework. Read carefully, because the next thirty paragraphs are the sequenced detail of each week, the choice points, and the failure modes to avoid.

The plan does not assume you start at zero. It assumes you are an operator who has read this far in the chapter and now wants the concrete sequence. If you are at zero, add a Week 0 to read the rest of Level 1 cover to cover before starting.

Block One (Weeks 1-4): The Workflow Platform

The first four weeks anchor everything. You pick one workflow platform and you ship one real agent. The point is not to learn ten platforms; the point is to be undeniably competent on one and to ship something you can point at.

How to pick the platform

Three considerations:

1. Your background. If you are non-coding (RevOps, business operations, consulting), pick Lindy or n8n. If you have moderate code comfort, pick n8n or Microsoft Copilot Studio. If you can write Python, you can choose the OpenAI Assistants API, Anthropic Claude with the Tools API, or Vercel AI SDK as your runtime instead of a workflow platform.
2. Your target role. If you are aiming at AI Solutions Architect (no-code), pick a no-code platform whose name shows up in JDs at your target companies. If you are aiming at GTM Engineer, learn one no-code platform plus the Python-based runtime your target companies use.
3. Your existing stack. If your company uses HubSpot heavily, Salesforce Agentforce makes sense. If your company is Microsoft-shop, Copilot Studio. If you have no employer-stack constraint, default to Lindy (fast to start) or n8n (most portable across stacks).

Do not learn two workflow platforms in parallel. The split attention costs you 50% of the depth on each and you ship nothing.

Week 1: Getting in

Goal: complete the platform's official tutorial, build one agent that calls one external tool, and ship it to a public URL.

• Spend the first three hours on the platform's official getting-started tutorial. Do not skip.
• Pick one external tool: a Google Sheet, a Stripe sandbox, a Notion page. Connect it.
• Build one agent that takes an input, calls the tool, and produces an output.
• Deploy. Get a URL. Click it. Watch it work.
• Document week 1 in your portfolio repo. Three paragraphs. Cost-to-date. Hours spent.

Shippable artifact, end of Week 1: a live URL that an interviewer could hit (even if the agent is trivial).

Week 2: A real problem, three tools

Goal: replace the trivial agent with one that solves a real problem and uses three tools.

Pick the problem from your actual job. The bar is "if this worked, I would use it Monday morning." Examples:

• For a RevOps person: a lead-enrichment agent that takes a HubSpot lead, looks it up on Clearbit or Apollo, scores it, writes back to HubSpot.
• For a CS lead: a triage agent that takes an Intercom ticket, classifies it, drafts a response, and routes it.
• For a sales engineer: an RFP-drafting agent that reads a customer's RFP PDF, finds matching sections from your past responses, and drafts a first pass.
• For an ops engineer: a meeting-notes-to-action-items agent that reads a Granola or Notion note and creates Asana tasks.

Connect three tools. Make the agent work end-to-end on your real data (or a sanitized version of it).

Shippable artifact, end of Week 2: the agent works on real-problem data with three tools. Documented in your repo.

Week 3: Hardening

Goal: stop the agent from breaking. This is when you discover that real-problem data has edge cases.

• Run the agent on twenty different real inputs. Document which ones fail.
• Add input validation. Add error handling. Add fallback behavior when a tool call fails.
• Add a per-run cost cap. Most platforms have this built in; if yours does not, use your model provider's API key with a spending limit.
• Document the first incidents you saw. These are draft postmortems for Block 3.

Shippable artifact, end of Week 3: a list of twenty real inputs and the agent's responses, plus a one-page document of failure modes encountered and fixes applied.

Week 4: Block 1 capstone

Goal: polish the agent for portfolio display. Custom domain. Cost dashboard. Documentation.

• Point a custom domain at your deployed agent (Vercel, Cloudflare, or your platform's domain settings).
• Write the three-paragraph "what this does and why" landing page.
• Document cost-per-run and total cost-to-date.
• Take a screen recording for archive (you will share the URL, not the recording, but a recording is your fallback).

Shippable artifact, end of Week 4 (Block 1 capstone): a deployed agent on a custom domain, with a public landing page and a documented cost profile. Portfolio Artifact 1 is now real.

Block Two (Weeks 5-8): Evals and Observability

The agent from Block 1 works. The question Block 2 answers: does it work reliably? This is the four-week block where you add the engineering discipline that separates serious operator-builders from people who built a demo.

How to pick the eval tool

Eight named tools are recognized in the 2026 market: Braintrust, Promptfoo, LangSmith eval, OpenAI Evals, Inspect AI (Anthropic), Helicone evals, Langfuse evals, Phoenix (Arize). Pick one.

• If you are non-coding: pick Braintrust or LangSmith. Both have UIs you can use without writing code. Braintrust has the cleanest playgrounds; LangSmith is closer to the rest of the LangChain ecosystem.
• If you write some Python: pick Promptfoo (YAML-driven, runs locally) or Inspect AI (more rigorous, Anthropic-built).
• If your stack is OpenAI-heavy: pick OpenAI Evals (deepest integration with their API).

How to pick the observability tool

Four named tools matter in 2026: LangSmith (traces + evals in one place), Helicone (cost-focused), Langfuse (open source), Arize/Phoenix (production-grade). Pick one.

• If you want one tool for both eval and observability: LangSmith.
• If you want cost visibility first: Helicone.
• If you want self-hosted: Langfuse or Phoenix.
• If you want enterprise depth: Arize.

Most candidates pick LangSmith for the simplicity of having one vendor across eval and observability in their portfolio.

Week 5: First twenty eval cases

Goal: write twenty representative eval cases for your Block 1 agent. Score them. Document the score.

• Open your eval tool. Set up a project for your agent.
• Write twenty input/expected-output pairs, all happy-path. These should be cases you know the agent should handle.
• Run the eval. Score. Document the score (probably 80-95%; this is normal).
• For each failure, write down what failed and what you would do about it. Do not fix them yet.

Shippable artifact, end of Week 5: a 20-case happy-path eval set with the first scored run documented.

Week 6: Edge cases and adversarial cases

Goal: expand the eval set to 60 cases with the right composition.

• Add 20 edge cases: typos, missing fields, ambiguous inputs, malformed inputs. Score them. Many will fail.
• Add 15 adversarial cases: prompt-injection attempts, attempts to make the agent take unauthorized actions, attempts to extract the system prompt. Score them. Some will fail in concerning ways.
• Add 5 "should-escalate" cases where the correct answer is "I don't know" or "route to a human." These often score 0 the first time because the agent will confidently answer.
• Document the score breakdown by category. This is the artifact reviewers want to see.

Shippable artifact, end of Week 6: a 60-case eval set with a documented composition and a category-level score breakdown.

Week 7: Observability stack

Goal: every run of your agent now produces a structured trace visible in your observability tool.

• Wire your agent to the observability tool. Most platforms have a one-line integration (LangSmith especially).
• Trigger 10 runs. Inspect the traces. Confirm you can see thought/action/observation per iteration, cost per run, and latency.
• Set up a dashboard: runs-per-day, average cost, p50/p99 latency, error rate.
• Set up one alert: cost-per-run threshold or daily aggregate cap.

Shippable artifact, end of Week 7: a screenshot of your observability dashboard plus a written description of three traces (good run, edge case, failure).

Week 8: Block 2 capstone

Goal: close the loop. Use the eval set and the observability traces to identify three specific improvements to your agent. Make those improvements. Re-run the eval. Document the score jump.

• Pick three things from your failure analysis. Make targeted changes (prompt edits, retrieval tuning, tool-schema clarifications).
• Re-run the full eval. Document score change by category.
• Add 20-40 more eval cases informed by what you learned. Aim for 80-100 cases total by end of week 8.
• Write a one-page summary of the "change → re-score → improvement" loop you ran.

Shippable artifact, end of Week 8 (Block 2 capstone): a documented eval set of 80-100 cases with score progression over weeks 5-8, observability dashboard, and a written summary of the improvement loop. Portfolio Artifact 2 is now real.

Block Three (Weeks 9-12): MCP Server + Governance

The agent runs and the eval set proves it. Block 3 turns you from "operator who built one good agent" into "operator who thinks in production-grade systems." Two outputs: a portable integration via MCP, and a governance document.

Why MCP now

By Q1 2026, MCP is the open standard for connecting agents to tools across runtimes (covered in the previous lesson on MCP servers and agent skills). Building one MCP server during your on-ramp does three things at once: it forces you to design a schema (a real engineering skill), it produces a portfolio artifact that reviewers verify by recognition ("oh you have an MCP server, let me connect"), and it makes your work portable across Claude Desktop, Claude Code, ChatGPT enterprise, Cursor, Lindy, n8n, Zapier Agents, and Microsoft Copilot Studio.

How to pick the MCP target

Pick a target that satisfies three criteria:

1. You have a real API to wrap. A public API (GitHub, Stripe sandbox, Notion, Linear, your own product's API) that the agent could meaningfully use.
2. No official MCP server exists yet. Atlassian, Stripe, GitHub, Notion, Slack, HubSpot, Salesforce, Figma, and Canva all ship official servers in 2026. Pick something smaller or your own product.
3. You can host it. A small Python or TypeScript service deployable to Vercel, Render, Cloudflare Workers, or Fly.io.

Week 9: MCP schema design

Goal: design the tool surface for your MCP server.

• List the operations you want to expose. Aim for 4-8 tools. Too few is trivial; too many is unfocused.
• For each tool, write the JSON schema: name, description, input parameters, output shape.
• For each tool, write three sample inputs/outputs in your eval format.
• Run a design review with yourself: are these tools at the right level of granularity? Are the descriptions clear enough that an LLM would pick the right tool?

Shippable artifact, end of Week 9: a schema document (Markdown or JSON) defining 4-8 tools with descriptions, inputs, outputs, and sample interactions.

Week 10: MCP implementation

Goal: implement the MCP server. Hosted endpoint. Two tools working end-to-end.

• Use the MCP SDK in Python or TypeScript. Both have official scaffolds.
• Implement two tools fully. Test by connecting to Claude Desktop or Cursor.
• Deploy to a hosted endpoint. Document the endpoint URL.
• Add basic auth (an API key in the header) so the server is not anonymous-callable.

Shippable artifact, end of Week 10: a live MCP server URL with two working tools and authentication, plus a one-paragraph "how to connect" instruction.

Week 11: Governance write-up

Goal: write the 1-3 page governance document for your Block 1 agent. This is Portfolio Artifact 3 from the previous lesson.

• Blast Radius classification: list every action the agent can take. Classify each: internal-reversible, internal-hard-to-reverse, external-reversible, external-hard-to-reverse, external-irreversible.
• Identity model: whose authority does the agent act under? How is that logged?
• FRIA stub: who's affected, what rights, worst-case + mitigation, oversight, identity logging. One page.
• Kill switch + cost caps: document the mechanism, the last test date, the cost ceiling.
• HITL gates: for any external action, what is gated.
• Known limitations: what the agent does poorly and why.

Shippable artifact, end of Week 11: a 1-3 page governance document for your portfolio agent. Portfolio Artifact 3 is now real.

Week 12: Postmortem + portfolio site

Goal: write the postmortem and assemble the portfolio site.

• Postmortem: write up the most significant failure your agent had in weeks 1-11. If you genuinely don't have one, engineer an adversarial near-miss this week and document it as a near-miss with that label.
• Use the SRE template: summary, timeline, root cause, contributing factors, impact, response, remediation, what-we'd-do-differently.
• Build the portfolio site: hero section with one-line positioning, four artifact sections, about/links.
• Host on Vercel, Netlify, GitHub Pages, or a custom domain.
• Send the URL to three people for feedback. Iterate based on what they call out as confusing.

Shippable artifact, end of Week 12 (Block 3 capstone): a complete portfolio site linking all four artifacts. Portfolio Artifact 4 is now real and the portfolio is complete.

Hours/Week and Failure Modes

The plan assumes 10-15 hours a week of focused practice. That is realistic for someone working a full-time job. Compression to 6-8 hours a week works but extends the plan to 16-18 weeks. Compression below 6 hours a week tends to lose continuity and the artifacts slip.

Failure mode 1: too many platforms

The most common failure: trying to learn three workflow platforms in parallel in weeks 1-4 because "I want to put them all on my resume." Result: shallow on all three, deployed agent on none. The fix is the discipline to pick one and ship.

Failure mode 2: skipping evals

The second most common failure: the agent works in week 4 and the operator moves directly to "more features" instead of evals. Six weeks later they have a more complex agent that breaks in more ways. The fix: respect the weeks 5-8 block. Evals are not optional.

Failure mode 3: no postmortem

The third most common failure: making it to week 12 without ever writing a postmortem because "nothing went wrong." This is almost never true. Either you saw small failures and dismissed them, or your testing was too shallow to surface failures. Engineer an adversarial near-miss in week 12 if you need to. Label it as such. Hiring managers respect the honest label.

Failure mode 4: the tutorial trap

The fourth failure: spending weeks 1-4 on tutorials and YouTube videos without ever shipping. The platform's official tutorial in week 1 is the only one allotted. After that, you ship. Tutorials are infinite; ships are finite; you need ships.

The Tool Shortlist by Week

The named tools you will touch by the end of week 12, organized by block:

Block 1 tools

• Workflow platforms (pick one): Lindy, n8n, Microsoft Copilot Studio, Salesforce Agentforce, Zapier Agents, Make. For coders: OpenAI Assistants API, Anthropic Claude with Tools API, Vercel AI SDK.
• Connected systems (typical): Google Sheets, Notion, Slack, HubSpot, Salesforce, Stripe (sandbox), GitHub, Linear, Intercom.
• Hosting (pick one): Vercel, Render, Cloudflare Workers, Fly.io.

Block 2 tools

• Eval (pick one): Braintrust, Promptfoo, LangSmith eval, OpenAI Evals, Inspect AI, Helicone evals, Langfuse evals, Phoenix.
• Observability (pick one): LangSmith, Helicone, Langfuse, Arize, Phoenix.
• Alerting: the observability tool's native alerts, or push to PagerDuty/Opsgenie/email/Slack.

Block 3 tools

• MCP SDK: Python mcp package or TypeScript @modelcontextprotocol/sdk.
• MCP clients (for testing): Claude Desktop, Cursor, Claude Code, ChatGPT enterprise.
• Governance docs: Markdown or Google Docs. No special tool required.
• Portfolio site: Vercel, Netlify, GitHub Pages, Notion site, or a single-page static HTML.

What You Have on Day 90

By the end of week 12 you have:

• A deployed agent on a custom domain solving a real problem with 3+ tools, documented cost-per-run.
• An 80-100 case eval set with documented score progression over weeks 5-8 and traces in an observability UI.
• A 1-3 page governance write-up with Blast Radius classification, FRIA stub, identity model, kill switch, cost caps, HITL gates, and known limitations.
• A postmortem of a real incident or engineered near-miss using the SRE template.
• An MCP server with a hosted endpoint and 2-8 working tools.
• A portfolio site indexing all of the above.
• Verified literacy with named tools (LangSmith, Helicone, or whichever you picked).
• A real, lived experience of the operator-builder workflow that no certificate can give you.

That is the qualification. That is what gets you to the panel. The work in weeks 1-12 is not training for the role; it is the role, at a portfolio scale.

After Day 90

The first 90 days build the floor. After day 90, three directions:

1. Deepen one block. If your strongest interest is observability and ops, spend the next 90 days going deep on Helicone or Arize, build a second agent, and lift your portfolio toward Agent Operations Lead level.
2. Add Python/SQL if you have not yet. Six months of focused Python and SQL on top of your portfolio shifts your offers from no-code band to GTM Engineer band. Apollo's data shows this is the most lucrative single skill add for the operator-builder career.
3. Ship a second agent in a different domain. Your first agent solved a problem from your day job. A second in a different domain (a side project that uses three different tools, with a separate eval set) signals breadth.

How to Narrate the 90 Days in an Interview

Hiring managers will ask you to walk through your portfolio. The cleanest narrative:

"I spent 90 days on a structured on-ramp. Weeks 1-4 I picked Lindy and built a renewal-risk scoring agent that connects HubSpot, Stripe, and our knowledge base. Weeks 5-8 I added an eval set in Braintrust — 84 cases across happy-path, edge, adversarial, and escalate categories — and observability in LangSmith. Weeks 9-12 I wrapped up with an MCP server for our internal product API and a governance write-up using Blast Radius classification and a FRIA stub. The postmortem in week 12 was a real cost-overrun incident I caught in week 7's observability work; root cause was an unbounded retry loop on ambiguous company names. I added a per-run cost cap and 8 new eval cases. End-to-end portfolio is at [URL]."

One sentence per block. Specific tool names. One real failure with a real fix. A URL to the portfolio. That narrative, in 90 seconds, takes you from screen to panel in most interview loops.

Key Takeaways

• Twelve weeks split into three four-week blocks: Block 1 = one workflow platform shipping a deployed agent; Block 2 = one eval tool + one observability tool with 80-100 case eval set; Block 3 = one MCP server + governance write-up + postmortem + portfolio site.
• Each week ends in a shippable artifact you can point to in an interview. The plan is artifact-driven, not knowledge-driven.
• 10-15 hours a week is the planned cadence; compression to 6-8 hours stretches the plan to 16-18 weeks. Below 6 hours/week the continuity tends to break.
• Pick one workflow platform. Lindy or n8n for non-coders, n8n or Copilot Studio for moderate code comfort, OpenAI Assistants/Claude Tools API/Vercel AI SDK for coders. Do not learn two platforms in parallel.
• Pick one eval tool and one observability tool. Named tools that reviewers recognize: Braintrust, Promptfoo, LangSmith eval, OpenAI Evals, Inspect AI, Helicone evals, Langfuse evals, Phoenix for eval. LangSmith, Helicone, Langfuse, Arize, Phoenix for observability.
• Eval composition is 50-60% happy path, 20-25% edge, 10-15% adversarial, 5-10% should-escalate. Score by category, document progression over weeks, run on every change.
• The MCP server in Block 3 produces a portable, recognized artifact. Pick a target with no official MCP server yet, design 4-8 tools, implement 2 fully, host with auth.
• The governance write-up uses Blast Radius classification + FRIA stub from Lesson 2 of this chapter. Identity model, kill switch, cost caps, HITL gates, known limitations all documented.
• Four failure modes to avoid: learning too many platforms in parallel, skipping the eval block, never writing a postmortem, and getting stuck in tutorial-watching instead of shipping.
• By day 90 you have all four portfolio artifacts from the previous lesson plus an MCP server and a portfolio site. After day 90, deepen a block, add Python/SQL, or ship a second agent in a different domain. The 90-day narrative is the cleanest 90-second walk-through in an operator-builder interview.