{ "resources": { "python": [ "CS50’s Introduction to Programming with Python", "https://cs50.harvard.edu/python/", "Harvard · beginner course and exercises" ], "git": [ "Pro Git", "https://git-scm.com/book/en/v2", "Scott Chacon & Ben Straub · start with chapters 1–3" ], "web": [ "Learn web development", "https://developer.mozilla.org/en-US/docs/Learn_web_development", "MDN · web fundamentals and practice" ], "fullstack": [ "Full Stack Open", "https://fullstackopen.com/en/part0/general_info/", "University of Helsinki · requires programming, web, database, and Git basics" ], "sql": [ "PostgreSQL tutorial", "https://www.postgresql.org/docs/current/tutorial.html", "PostgreSQL · relational databases and SQL" ], "api": [ "FastAPI tutorial", "https://fastapi.tiangolo.com/tutorial/", "FastAPI · build an API step by step" ], "api-tests": [ "Testing FastAPI applications", "https://fastapi.tiangolo.com/tutorial/testing/", "FastAPI · executable request and response tests" ], "discovery": [ "Using in-depth interviews", "https://www.gov.uk/service-manual/user-research/using-in-depth-interviews", "Government Digital Service · planning and conducting research" ], "agents": [ "Building effective agents", "https://www.anthropic.com/engineering/building-effective-agents", "Anthropic · choosing workflows and agent patterns" ], "hf": [ "AI Agents Course", "https://huggingface.co/learn/agents-course/en/unit0/introduction", "Hugging Face · concepts, frameworks, and assignments" ], "evals": [ "Demystifying evals for AI agents", "https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents", "Anthropic · tasks, trials, graders, and outcomes" ], "context": [ "Effective context engineering for AI agents", "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents", "Anthropic · retrieval and context trade-offs" ], "owasp": [ "Excessive agency", "https://genai.owasp.org/llmrisk/llm062025-excessive-agency/", "OWASP · permission and tool-use risks" ], "docker": [ "Get started with Docker", "https://docs.docker.com/get-started/", "Docker · containers and reproducible environments" ], "otel": [ "Observability signals", "https://opentelemetry.io/docs/concepts/signals/", "OpenTelemetry · traces, metrics, and logs" ], "sre": [ "The Site Reliability Workbook", "https://sre.google/workbook/table-of-contents/", "Google · SLOs, monitoring, incidents, and practical reliability" ], "interviews": [ "OpenAI interview guide", "https://openai.com/interview-guide/", "OpenAI · general process; exact rounds and AI permissions vary" ], "sierra": [ "The AI-native interview", "https://sierra.ai/blog/the-ai-native-interview", "Sierra · system design and a plan, build, review format" ], "policy": [ "Candidate AI guidance", "https://www.anthropic.com/candidate-ai-guidance", "Anthropic · follow the rules for the specific assessment" ], "agent-factory": [ "The AI Agent Factory: About", "https://agentfactory.panaversity.org/docs/about", "Panaversity · orientation; a proposed approach to AI workers" ], "agent-spec": [ "Spec-Driven Development", "https://agentfactory.panaversity.org/docs/spec-driven-development-crash-course", "Panaversity · writing and maintaining executable intent" ], "agent-sor": [ "The FDE AF Model", "https://agentfactory.panaversity.org/docs/ecosystem/fde-af-model", "Panaversity · governed knowledge and reusable delivery assets" ], "agent-redesign": [ "Designing the Vertical System of Record", "https://agentfactory.panaversity.org/docs/ecosystem/designing-the-vertical-sor", "Panaversity · examine inherited work before redesigning it" ], "agent-evaluation": [ "Eval-Driven Development for AI Employees", "https://agentfactory.panaversity.org/docs/eval-driven-development-crash-course", "Panaversity · evaluation-led worker development" ], "benmore": [ "Forward Deployed — Richard Buehling (February 2026)", "#ref-benmore", "Supplied Benmore book · source notes and chapter guide; PDF not hosted" ], "agent-learning": [ "How to Learn from This Book", "https://agentfactory.panaversity.org/docs/how-to-learn-from-this-book", "Panaversity · Foundations first; practise, recall, then apply" ], "agent-fit": [ "Is This an Agent Problem?", "https://agentfactory.panaversity.org/docs/is-this-an-agent-problem", "Panaversity · Choose a normal tool, a session task, or a recurring worker" ], "agent-promotion": [ "From One-Off to Worker", "https://agentfactory.panaversity.org/docs/from-one-off-to-worker", "Panaversity · Specification, evaluation, escalation, and runtime" ], "agent-workflow": [ "Workflow Design & Diagnosis", "https://agentfactory.panaversity.org/docs/workflow-design-diagnosis-crash-course", "Panaversity · Assign each step by reversibility, stakes, and accountability" ], "agent-context-system": [ "System of Context", "https://agentfactory.panaversity.org/docs/ecosystem/system-of-context", "Panaversity · Keep governing rules, live facts, and supporting context distinct" ], "agent-checker": [ "Trusting the Checker", "https://agentfactory.panaversity.org/docs/trusting-the-checker-crash-course", "Panaversity · Calibrate the evaluator against reviewed examples" ], "agent-experience": [ "Designing Agent Experiences", "https://agentfactory.panaversity.org/docs/designing-agent-experiences-crash-course", "Panaversity · Intent previews, supervision, and repair" ], "agent-teams": [ "Human-Agent Teams", "https://agentfactory.panaversity.org/docs/human-agent-teams-crash-course", "Panaversity · Role cards, ownership, and attention budgets" ], "agent-harness": [ "Harness Engineering", "https://agentfactory.panaversity.org/docs/harness-engineering-crash-course", "Panaversity · Enforce limits outside the prompt" ] }, "phases": [ { "id": "foundation", "short": "Software foundations", "title": "Build a software foundation", "outcome": "A small application that you can run, test, debug, and explain without following a tutorial.", "intro": "Make code a tool you can rely on. If you already build software professionally, use the exercises as a diagnostic and spend time only on the gaps.", "review": "Change the input format without following a tutorial. Can you isolate the failure, update the implementation, and prove the fix with a test?", "lessons": [ { "id": "programming", "title": "Write and debug a useful program", "summary": "Python, data structures, errors, and tests", "learn": "Learn variables, functions, lists and dictionaries, file I/O, exceptions, and unit tests. Read stack traces and use a debugger. Choose Python for this path; it is a practical starting choice, not a universal FDE requirement.", "practice": "Build a command-line tool that reads a CSV of support tickets, validates required fields, groups tickets by category, and exports a report. Add empty-file, malformed-row, and duplicate-ID cases.", "proof": "You can explain each transformation and show tests for both normal and malformed inputs.", "resources": [ "python" ] }, { "id": "workflow", "title": "Work in a shared codebase", "summary": "Git, command line, dependencies, and documentation", "learn": "Practise commits, branches, diffs, merges, and reverting a change. Learn shell navigation, environment variables, dependency isolation, and how to keep secrets out of a repository.", "practice": "Put your ticket tool in Git. Make a feature branch, introduce and fix a failing test, then write a setup guide. Ask a peer to run it from a fresh checkout.", "proof": "A second person can install and run it, and the history explains the changes.", "resources": [ "git" ] }, { "id": "web-basics", "title": "Make the result usable", "summary": "HTTP, forms, browser requests, and a small interface", "learn": "Understand the browser/server boundary, HTTP methods and status codes, JSON, and basic HTML. Learn enough JavaScript to send a request and present loading, empty, success, and error states.", "practice": "Build a small page that accepts a ticket file or text input and shows the results. Make an error understandable to someone who did not write the code.", "proof": "The interface can be used with a keyboard and makes failures visible.", "resources": [ "web", "fullstack" ] }, { "id": "direct-and-review", "title": "Direct AI work and verify it", "summary": "Intent, delegation, verification, and human judgment", "learn": "Agent Factory describes two uses of a general agent: solving a task in a session and helping build a worker that runs independently. Its 10-80-10 rule is a planning heuristic for human direction, AI execution, and human review; it is not a measured allocation of time.", "practice": "Give an assistant the ticket-tool task with three acceptance examples. Inspect its diff, run the examples, and explain one incorrect assumption. Log time spent specifying, generating, and correcting.", "proof": "You can reproduce the result and explain the code, its boundaries, and the checks you used. Faster generation alone is not the success measure.", "resources": [ "agent-factory", "git", "agent-learning" ] } ] }, { "id": "discovery", "short": "Customer discovery", "title": "Understand the workflow first", "outcome": "An evidence ledger, stakeholder map, approved delivery specification, and a justified workflow redesign.", "intro": "An FDE needs to discover what is worth building. Practise listening, mapping the current process, and narrowing a request into a deliverable.", "review": "Have the customer change a critical assumption. Update scope, acceptance checks, time and budget implications; explain whether to proceed, narrow, or pause.", "lessons": [ { "id": "interview-user", "title": "Run a discovery conversation", "summary": "Users, pain points, and evidence", "learn": "Ask about the last time a task happened, rather than whether someone likes your idea. Understand the trigger, steps, exceptions, current tools, and who is accountable. Record assumptions separately from observations.", "practice": "Interview a willing user for 20 minutes, or run a clearly labelled simulation. Ask them to walk through a recent task. Write a workflow map and identify one costly handoff.", "proof": "Your notes distinguish what the user said, what you observed, and what you still need to verify.", "resources": [ "discovery" ] }, { "id": "scope", "title": "Define a small, testable outcome", "summary": "Baseline, constraints, and acceptance criteria", "learn": "Choose one user and one workflow. Define the current baseline, the desired outcome, and how you will measure it. Ask about data access, approval, budget, and the person who accepts the delivery.", "practice": "Write a one-page brief: problem, user, current process, proposed slice, non-goals, data access, success test, and owner. For a simulation, choose a synthetic dataset and state its limits.", "proof": "A reviewer can decide whether the project succeeded without relying on your demo narrative.", "resources": [ "discovery" ] }, { "id": "tradeoffs", "title": "Explain a technical trade-off", "summary": "Options, risks, scope changes, and updates", "learn": "Compare a manual process, a deterministic automation, and an AI-assisted workflow. Explain trade-offs in accuracy, cost, latency, and maintenance. Learn to report a blocker with a decision or next step.", "practice": "Write a short decision record choosing the simplest viable approach. Then send a simulated weekly update: result, next step, blocker, and decision needed.", "proof": "Your recommendation is understandable to a nontechnical decision-maker and states what would change your mind.", "resources": [ "agents", "agent-fit" ] }, { "id": "discovery-debt", "title": "Validate the brief before committing", "summary": "Stakeholders, assumptions, feasibility, and conditional commitments", "learn": "Buehling calls unverified understanding discovery debt. Compare the sponsor’s request with operator evidence, technical constraints, and the real reason for the deadline. Connect goals, scope, risk, time, and budget before promising delivery.", "practice": "Create an evidence ledger with claim, source, confidence, owner, and next check. Test three claims from a fictional AI-written brief. Map the sponsor, daily operator, system owner, and acceptance owner; record one disagreement.", "proof": "Every critical assumption has evidence or an unresolved decision. Write a conditional commitment: “We can deliver this slice if access is approved by this date; otherwise we reduce scope or pause.”", "resources": [ "benmore", "discovery" ] }, { "id": "delivery-spec", "title": "Write a specification a reviewer can test", "summary": "Outcome, boundaries, acceptance examples, and change control", "learn": "Write observable behavior before implementation. Link each requirement to evidence and an acceptance check. Keep the approved intent and the actual implementation aligned when new information changes the work.", "practice": "Specify one ticket-routing slice: input schema, output, denied actions, error handling, latency and cost budget, reviewer, and three acceptance examples. Change one customer constraint and update the affected check and decision record.", "proof": "A peer can test the requirement from the document. Open questions stay visible instead of becoming invented requirements.", "resources": [ "agent-spec", "benmore" ] }, { "id": "redesign-work", "title": "Decide what to preserve, change, or remove", "summary": "Business obligations versus inherited workarounds", "learn": "Observe the old workflow, then question why each step exists. Agent Factory’s vertical-design method distinguishes enduring obligations from steps created by older tools or organizational constraints. Validate proposed changes with the responsible operator. Assign each step to a person, AI, or a reviewed collaboration. Explain the choice using reversibility, the cost of error, and who is accountable.", "practice": "Map the three eligibility lookups in your project. For each, record its purpose, evidence, and a keep/change/remove recommendation. Preserve the eligibility decision while testing whether one repeated data-entry step can disappear. Name who reviews, what they check, and when review happens before the action takes effect. Give the map an owner and a review date.", "proof": "The revised flow preserves required controls and has an owner-approved test. An unexplained step remains unresolved, not automatically deleted.", "resources": [ "agent-redesign", "agent-workflow" ] } ] }, { "id": "integration", "short": "Data & integrations", "title": "Connect data and systems", "outcome": "A tested API, recoverable data flow, and governed policy register with denied-access evidence.", "intro": "Connect your project to persistent data and an external interface. Reliability starts at the boundaries: schemas, identities, permissions, and retries.", "review": "Replay the same event twice, deny the caller permission, and make the dependency time out. Show exactly what changed in the database for each case.", "lessons": [ { "id": "data-model", "title": "Model and query the data", "summary": "SQL, schemas, joins, and data quality", "learn": "Learn tables, primary keys, foreign keys, joins, aggregates, transactions, and indexes. Identify missing values, duplication, inconsistent timestamps, and fields that should not enter your application.", "practice": "Load your project data into a relational database. Create a schema, a migration, a duplicate-detection query, and a query that measures your workflow baseline.", "proof": "You can explain the grain of each table and avoid double-counting when joining data.", "resources": [ "sql" ] }, { "id": "api-contract", "title": "Build an API with clear boundaries", "summary": "Request validation, identity, and errors", "learn": "Define request and response schemas. Distinguish authentication from authorisation. Return meaningful status codes and avoid exposing secrets in logs or responses.", "practice": "Add endpoints to create, view, and update a record. Validate inputs, add a per-user permission check, and test allowed and denied requests. Use test identities locally.", "proof": "Tests demonstrate that one user cannot read or change another user’s records.", "resources": [ "api", "api-tests" ] }, { "id": "resilience", "title": "Make the integration recoverable", "summary": "Timeouts, pagination, retries, and idempotency", "learn": "Assume remote calls can fail and events can repeat. Use bounded retries and backoff where appropriate. Define what happens after a timeout and how a caller can safely retry a write.", "practice": "Connect a mock customer API. Simulate paginated results, a rate-limit response, duplicate events, and a partial failure. Add a reconciliation script for the failed records.", "proof": "A replay does not duplicate work, and a failed batch can resume without losing completed records.", "resources": [ "api-tests" ] }, { "id": "governed-knowledge", "title": "Give domain knowledge an accountable owner", "summary": "Approved sources, versions, retrieval, and complete procedures", "learn": "A searchable document collection needs ownership, review, versioning, permissions, and citations to serve as governed knowledge. Agent Factory separates source evidence, a map of what exists, and complete procedures that must be followed together. Keep three source types distinct: approved rules, current values from the owning system, and supporting conversations. An index helps find evidence; it does not become the authority.", "practice": "Create a synthetic policy register with document ID, version, owner, approval date, review date, access group, and superseded version. Add one complete eligibility procedure. Test expired guidance, a revoked reader, and a missing required step. Assemble one context packet with the applicable policy version, live ticket facts, supporting notes, missing evidence, and citations. A chat message cannot override the approved policy.", "proof": "The answer cites an approved version; unavailable authority leads to escalation. Permissions are enforced outside the model, and a procedure is never executed from a partial search excerpt.", "resources": [ "agent-sor", "context", "owasp", "agent-context-system" ] } ] }, { "id": "ai", "short": "Applied AI & evaluation", "title": "Build an AI workflow you can evaluate", "outcome": "A bounded AI worker, a non-AI baseline, a calibrated evaluation report, and an approval-and-recovery interface.", "intro": "Learn model APIs and tool use in the context of a useful workflow. Add autonomy only when you can show that it improves the outcome.", "review": "Replace the model or prompt, rerun the same evaluation, and explain the change in quality, cost, and latency. Include at least one regression.", "lessons": [ { "id": "model-workflow", "title": "Start with a bounded model call", "summary": "Structured output, context, tools, and budgets", "learn": "Learn messages, tokens, structured output, tool calling, and schema validation. Separate a model’s suggestion from an operation your application executes. Set a usage budget before using a paid API.", "practice": "Add ticket classification or draft suggestions. Compare a rule-based baseline with one model call. Validate the returned schema and route uncertain or invalid outputs to human review.", "proof": "The workflow behaves sensibly when the model is unavailable or returns an invalid response.", "resources": [ "agents", "hf" ] }, { "id": "retrieval", "title": "Retrieve the right context safely", "summary": "Search, citations, freshness, and access control", "learn": "Learn when keyword search, indexed retrieval, or live exploration fits. Preserve source identity, apply access controls before returning content, and handle missing or contradictory evidence.", "practice": "Add a small knowledge collection with source links. Include stale documents, two conflicting answers, and a document that a test user cannot access.", "proof": "Your test user never receives the restricted document and can trace an answer to its source.", "resources": [ "context", "owasp" ] }, { "id": "evaluation", "title": "Measure outcomes and inspect failures", "summary": "Held-out cases, graders, traces, and regression", "learn": "Create representative tasks with expected outcomes. Separate development examples from evaluation cases. Use deterministic checks when possible and calibrate subjective judgements with human review.", "practice": "Create an initial set of 20–30 diverse test cases as a project exercise. Include ambiguity and adversarial input. Record completions, failure categories, latency, and cost; explain the small sample’s limits.", "proof": "Your report includes failed cases and the actual resulting system state, not just a convincing model response.", "resources": [ "evals" ] }, { "id": "worker-contract", "title": "Turn a session task into an operable worker", "summary": "Trigger, state, tools, supervision, and stop conditions", "learn": "A useful session result does not establish that a workflow can run unattended. Specify who owns a recurring job, what wakes it, what it can change, where progress lives, and how it stops. Keep human judgment explicit at consequential boundaries.", "practice": "Run the ticket task from a synthetic queue. Persist job state, cap runtime and retries, require review before assignment, and expose pause/resume. Interrupt a job after a suggested route is saved and demonstrate safe recovery.", "proof": "A duplicate trigger causes no duplicate assignment. The operator can see why work stopped and resume without guessing what already happened.", "resources": [ "agent-factory", "agent-evaluation", "agent-promotion", "agent-harness" ] }, { "id": "check-the-checker", "title": "Check the evaluator before trusting its score", "summary": "A passing grade is useful only when the grader catches the failures that matter.", "learn": "Tests verify specific properties; evaluation estimates behavior on a sample. A model judge can miss a bad outcome or reward a persuasive explanation. Check the final state, compare with human judgments, and keep evaluation examples separate from tuning.", "practice": "Label 12 held-out routing runs as correct or incorrect with a peer. Include fluent but wrong suggestions, correct but terse results, and failed writes. Compare the judge with those labels, list false passes and false failures, then revise the rubric without editing the held-out cases.", "proof": "You can show a disagreement table, explain which errors the grader misses, and state where human review is still needed. Twelve examples are a calibration exercise, not production reliability evidence.", "resources": [ "agent-checker", "agent-evaluation", "evals" ] }, { "id": "review-and-recover", "title": "Design a workflow people can supervise", "summary": "Make the intended action clear, keep interruptions useful, and provide a way to recover.", "learn": "An approval screen should show the proposed change, supporting evidence, affected records, and available alternatives. Distinguish queued, running, waiting for review, failed, and completed work. Design recovery and operator access before expanding autonomy.", "practice": "Build a routing review screen with approve, edit, and reject actions. Seed a stale recommendation and an interrupted write. Ask a peer to use only the interface to explain the change, correct it, and recover the interrupted task. Test the same task with a keyboard and at a narrow viewport.", "proof": "The reviewer sees what will happen before approving. A stale decision is revalidated, a repeated click cannot repeat the write, and the person can find the next action after a failure. Record completion time and the confusing step.", "resources": [ "agent-experience", "agent-workflow", "web" ] } ] }, { "id": "production", "short": "Production & handoff", "title": "Make it work after the demo", "outcome": "A release-gap register, reproducible deployment, recovery drill, and accepted ownership and support pack.", "intro": "Give your project an operational life. Make it possible to see a failure, recover from it, and hand the system to another person.", "review": "Ask a peer to recover from a simulated outage using only the runbook. Record where they got stuck and improve the instructions.", "lessons": [ { "id": "deploy", "title": "Deploy reproducibly", "summary": "Containers, configuration, environments, and rollback", "learn": "Separate code from environment-specific configuration. Pin the dependencies your build needs. Understand health checks and what a deploy changes in application and database state.", "practice": "Containerise the service or document an equivalent reproducible setup. Add an automated test step, a health check, and a rollback procedure. Keep a local demo mode to control cost.", "proof": "You can deploy a known version and return to the previous working version.", "resources": [ "docker" ] }, { "id": "observe", "title": "See and diagnose a failure", "summary": "Logs, traces, metrics, and service objectives", "learn": "Connect a user-visible failure to the requests and dependencies involved. Record useful identifiers without exposing sensitive data. Choose measurements that correspond to the customer workflow.", "practice": "Add structured logs and measure task completion, p95 latency, and cost per task. Simulate a slow dependency. Create one actionable alert with an owner and a response.", "proof": "You can find the failing request, identify the dependency, and describe the user impact.", "resources": [ "otel", "sre" ] }, { "id": "handoff", "title": "Transfer ownership responsibly", "summary": "Runbooks, feedback, incidents, and adoption", "learn": "Document setup, permissions, common failures, recovery, and operational ownership. Observe a user doing the workflow and remove friction. Describe what the system cannot yet do.", "practice": "Write a runbook and a short incident report from your failure exercise. Run a handoff session, ask the other person to operate the service, and capture one improvement from feedback.", "proof": "A named person can operate the project without relying on your memory.", "resources": [ "sre" ] }, { "id": "prototype-gap", "title": "Close the gap between prototype and release", "summary": "Known shortcuts, requirement coverage, and independent checks", "learn": "Buehling separates prototype, specification completion, and production readiness. A convincing interface can still contain stubbed integrations, unsupported rules, and untested recovery. Keep a visible record of those gaps.", "practice": "Make a gap table: requirement, current behavior, placeholder, risk, evidence needed, and owner. Replace one mock dependency with a test integration. Recheck earlier acceptance cases and review the full workflow before proposing a pilot.", "proof": "Every release-critical gap has been closed with evidence or explicitly excluded from the pilot. Tests and permission checks start with implementation and continue through release.", "resources": [ "benmore", "agent-spec" ] }, { "id": "support-exit", "title": "Agree the support boundary and prove handoff", "summary": "Ownership drills, service coverage, changes, and exit", "learn": "Buehling’s handoff stack combines an operational runbook, a system overview, and a maintained specification tree. Receiving teams learn through changes and recovery exercises. Support needs explicit responsibilities, coverage, and an end or review point.", "practice": "Have a peer diagnose a seeded failure, roll back a release, and implement a small requirement change. Record the drill outcome, primary and backup owner, support hours, escalation route, exclusions, and next review date.", "proof": "The receiver can operate and change the system. A named owner accepts remaining issues, and ongoing support distinguishes defect fixes from new scope.", "resources": [ "benmore", "sre", "agent-teams" ] } ] }, { "id": "career", "short": "Portfolio & applications", "title": "Turn the work into a credible application", "outcome": "A reproducible case study, a bounded engagement proposal, practice interviews, and a targeted application shortlist.", "intro": "Make your contribution easy to assess. Connect engineering decisions to the user’s problem and apply to roles whose responsibilities match your experience.", "review": "Give a peer five minutes with your case study. Can they explain the problem, your contribution, the result, and the most important limitation?", "lessons": [ { "id": "case-study", "title": "Write the project case study", "summary": "Problem, decisions, results, and limitations", "learn": "Explain the original workflow, your scope, the architecture, a difficult trade-off, the evaluation, and what happened after delivery. Distinguish real user outcomes from results on synthetic data.", "practice": "Publish a concise case study with a diagram, a runnable repository, a demo, a failure example, and the runbook. Make setup instructions the first thing a reviewer can find.", "proof": "A reviewer can reproduce your evidence and understand what you personally owned.", "resources": [ "sierra" ] }, { "id": "practice-interview", "title": "Practise explaining and building", "summary": "Coding, debugging, system design, and customer ambiguity", "learn": "Practise a timed debugging task and a solution-design conversation with missing requirements. State assumptions, ask focused questions, and explain alternatives. Check AI permissions for the actual assessment.", "practice": "Do two mock interviews with a peer. In one, debug a broken integration. In the other, design a workflow and respond to a changed constraint. Review where your reasoning became unclear.", "proof": "You can explain your code and decisions, respond to feedback, and work within the stated tool rules.", "resources": [ "interviews", "policy", "sierra" ] }, { "id": "applications", "title": "Build a targeted application shortlist", "summary": "Role scope, eligibility, travel, and proof", "learn": "Read the exact requisition. Compare what you would build, the customer interaction, seniority, location eligibility, and travel. Tailor your CV around relevant ownership and outcomes.", "practice": "Shortlist five roles using the directory, recheck each employer page, and map three requirements per role to concrete evidence. Rewrite two CV bullets without inventing impact numbers.", "proof": "Every application has a clear match, an evidence link, and explicit gaps you can discuss.", "resources": [ "interviews" ] }, { "id": "delivery-offer", "title": "Present a bounded engagement or portfolio proposal", "summary": "Customer value, evidence, scope, and reusable learning", "learn": "Frame your work around an accepted result and the evidence you will deliver. Employment, independent client work, and a domain product require different commercial arrangements. Do not infer income or demand from a teaching framework.", "practice": "Write a one-page proposal for the synthetic routing pilot: sponsor, baseline, fixed scope, assumptions, access needs, acceptance, support boundary, and exclusions. Explain which generic adapter or check could be reused without customer data.", "proof": "A reviewer can distinguish the deliverable, acceptance decision, recurring support, and optional expansion. Label simulated results and explain who owns any proposed reusable material.", "resources": [ "benmore", "agent-sor" ] } ] } ] }