Course 3 - Agentic Architecture

Teaching intent

Use this lesson to teach production Python structure, error boundaries, logging, and tests through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in Logistics ETL.

Before class

• Open the trainee lesson and confirm prerequisites: B1 or equivalent.
• Prepare a weak and strong production Python structure, error boundaries, logging, and tests artifact for 3.1.
• Identify the exact evidence field, threshold, or decision point learners must defend.

Suggested flow

1. 14 min - frame the field problem and evidence target
2. 22 min - model the core concept or move
3. 48 min - learner artifact production or simulation
4. 24 min - critique against the evidence standard
5. 12 min - exit ticket, risk note, and next handoff

Live facilitation

• Ask learners to draw the boundary before they write code.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Demonstrate one small move, then shift quickly into learner artifact production and review.

Evidence to collect

• Code separates I/O, business logic, configuration, and external calls.
• Errors are logged and surfaced without swallowing broad exceptions.
• Type hints or clear contracts make inputs and outputs reviewable.
• At least one focused test proves the behavior that matters in the field.

Formative check

What is the difference between an operational error and a programmer error, and how does each one return?

Reject or remediate

• Reject notebook-style scripts with globals, hidden credentials, or silent failures.
• Reject code that works only for the happy path.
• Reject demos that cannot be rerun by another learner.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed production Python structure, error boundaries, logging, and tests artifact and ask them to repair the weakest evidence field.

Stretch: Ask learners to defend the production Python structure, error boundaries, logging, and tests tradeoff against a skeptical sponsor, reviewer, or operator.

Remediation path

• Have the learner isolate one function and write its input/output contract.
• Add one failing test before refactoring.
• Require a log line that would help an operator diagnose failure.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach explicit interface contracts, permissions, schemas, and failure behavior through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in B2B integration.

Before class

• Open the trainee lesson and confirm prerequisites: 3.1.
• Prepare a weak and strong explicit interface contracts, permissions, schemas, and failure behavior artifact for 3.2.
• Identify the exact evidence field, threshold, or decision point learners must defend.

Suggested flow

1. 9 min - frame the field problem and evidence target
2. 14 min - model the core concept or move
3. 30 min - learner artifact production or simulation
4. 15 min - critique against the evidence standard
5. 7 min - exit ticket, risk note, and next handoff

Live facilitation

• Pause demos at failure points and ask what should have been observable.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Model the concept with a concrete operational example, then ask learners to apply it to a new scenario.

Evidence to collect

• Interface contract names inputs, outputs, auth, permissions, and error behavior.
• Tool or API boundaries are separated from model reasoning.
• The learner shows at least one failure response and recovery path.
• The contract can be handed to another builder without hidden assumptions.

Formative check

Which property of GraphQL most often surprises a customer in production?

Reject or remediate

• Reject tool calls with vague schemas or unbounded permissions.
• Reject API designs that hide authentication and error behavior.
• Reject architecture that cannot explain what happens when a dependency fails.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed explicit interface contracts, permissions, schemas, and failure behavior artifact and ask them to repair the weakest evidence field.

Stretch: Ask learners to defend the explicit interface contracts, permissions, schemas, and failure behavior tradeoff against a skeptical sponsor, reviewer, or operator.

Remediation path

• Rewrite the interface as a request/response contract.
• Add one denied or malformed request case.
• Mark the human approval point for any consequential action.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach explicit interface contracts, permissions, schemas, and failure behavior through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in Manufacturing telemetry.

Before class

• Open the trainee lesson and confirm prerequisites: 3.1, 3.2.
• Prepare a weak and strong explicit interface contracts, permissions, schemas, and failure behavior artifact for 3.3.
• Identify the exact evidence field, threshold, or decision point learners must defend.

Suggested flow

1. 22 min - frame the field problem and evidence target
2. 32 min - model the core concept or move
3. 72 min - learner artifact production or simulation
4. 36 min - critique against the evidence standard
5. 18 min - exit ticket, risk note, and next handoff

Live facilitation

• Compare single-agent, chain, and multi-agent designs against the same use case.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Demonstrate one small move, then shift quickly into learner artifact production and review.

Evidence to collect

• Interface contract names inputs, outputs, auth, permissions, and error behavior.
• Tool or API boundaries are separated from model reasoning.
• The learner shows at least one failure response and recovery path.
• The contract can be handed to another builder without hidden assumptions.

Formative check

What is the right boundary between request schema and domain model?

Reject or remediate

• Reject tool calls with vague schemas or unbounded permissions.
• Reject API designs that hide authentication and error behavior.
• Reject architecture that cannot explain what happens when a dependency fails.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed explicit interface contracts, permissions, schemas, and failure behavior artifact and ask them to repair the weakest evidence field.

Stretch: Ask learners to defend the explicit interface contracts, permissions, schemas, and failure behavior tradeoff against a skeptical sponsor, reviewer, or operator.

Remediation path

• Rewrite the interface as a request/response contract.
• Add one denied or malformed request case.
• Mark the human approval point for any consequential action.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach Front-End Touchpoints: Dashboards an FDE Will Modify through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in B2B SaaS admin console.

Before class

• Open the trainee lesson and confirm prerequisites: 3.3.
• Prepare a weak and strong example of the 3.4 Front-End Touchpoints: Dashboards an FDE Will Modify instructor artifact.
• Choose the exact pause point where learners must show evidence before discussion continues.

Suggested flow

1. 14 min - frame the field problem and evidence target
2. 22 min - model the core concept or move
3. 48 min - learner artifact production or simulation
4. 24 min - critique against the evidence standard
5. 12 min - exit ticket, risk note, and next handoff

Live facilitation

• Make learners name which parts are probabilistic and which must remain deterministic.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Demonstrate one small move, then shift quickly into learner artifact production and review.

Evidence to collect

• The artifact names the field decision connected to Front-End Touchpoints: Dashboards an FDE Will Modify.
• The learner separates claims, assumptions, observations, and evidence.
• The output can be reviewed against Milestone 4.
• The formative answer addresses: What three states must any data panel handle before review?

Formative check

What three states must any data panel handle before review?

Reject or remediate

• Reject submissions that only summarize Front-End Touchpoints: Dashboards an FDE Will Modify without producing an inspectable artifact.
• Do not reward completion alone; inspect error handling, assumptions, and reviewer usability.
• Reject work that hides the decision owner, risk, or next action.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed 3.4 Front-End Touchpoints: Dashboards an FDE Will Modify instructor artifact and ask them to improve the evidence column.

Stretch: Ask learners to defend one tradeoff in Front-End Touchpoints: Dashboards an FDE Will Modify against a skeptical sponsor.

Remediation path

• Have the learner restate the decision, evidence, and weakest assumption in three sentences.
• Require one revision that makes the artifact inspectable by a sponsor or reviewer.
• Pair the learner with a peer reviewer for a five-minute evidence audit.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach agent architecture, state, deterministic boundaries, memory, and reviewable reasoning through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in Insurance underwriting.

Before class

• Open the trainee lesson and confirm prerequisites: 3.3.
• Prepare a weak and strong agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact for 3.5.
• Identify the exact evidence field, threshold, or decision point learners must defend.

Suggested flow

1. 9 min - frame the field problem and evidence target
2. 14 min - model the core concept or move
3. 30 min - learner artifact production or simulation
4. 15 min - critique against the evidence standard
5. 7 min - exit ticket, risk note, and next handoff

Live facilitation

• Ask learners to draw the boundary before they write code.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Model the concept with a concrete operational example, then ask learners to apply it to a new scenario.

Evidence to collect

• Architecture diagram identifies model calls, tools, state, memory, deterministic code, and human gates.
• Learner explains why the chosen autonomy level is necessary.
• State and memory have ownership, retention, and audit rules.
• Failure mode and evaluation point are visible before deployment.

Formative check

Why does FDE practice default to the lowest autonomy that meets the brief?

Reject or remediate

• Reject multi-agent designs that add complexity without a decision benefit.
• Reject memory plans that do not say what is stored, why, and for how long.
• Reject diagrams that omit human approval for consequential actions.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact and ask them to repair the weakest evidence field.

Stretch: Ask learners to defend the agent architecture, state, deterministic boundaries, memory, and reviewable reasoning tradeoff against a skeptical sponsor, reviewer, or operator.

Remediation path

• Have the learner redraw the system with deterministic and probabilistic parts separated.
• Remove one unnecessary agent or tool and explain the tradeoff.
• Add one test fixture for a critical tool or state transition.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach agent architecture, state, deterministic boundaries, memory, and reviewable reasoning through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in the selected field context.

Before class

• Open the trainee lesson and confirm prerequisites: 3.5.
• Prepare a weak and strong agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact for 3.6.
• Identify the exact evidence field, threshold, or decision point learners must defend.

Suggested flow

1. 11 min - frame the field problem and evidence target
2. 16 min - model the core concept or move
3. 36 min - learner artifact production or simulation
4. 18 min - critique against the evidence standard
5. 9 min - exit ticket, risk note, and next handoff

Live facilitation

• Pause demos at failure points and ask what should have been observable.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Model the concept with a concrete operational example, then ask learners to apply it to a new scenario.

Evidence to collect

• Architecture diagram identifies model calls, tools, state, memory, deterministic code, and human gates.
• Learner explains why the chosen autonomy level is necessary.
• State and memory have ownership, retention, and audit rules.
• Failure mode and evaluation point are visible before deployment.

Formative check

Which primitive abstraction matters most for auditability?

Reject or remediate

• Reject multi-agent designs that add complexity without a decision benefit.
• Reject memory plans that do not say what is stored, why, and for how long.
• Reject diagrams that omit human approval for consequential actions.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact and ask them to repair the weakest evidence field.

Stretch: Ask learners to defend the agent architecture, state, deterministic boundaries, memory, and reviewable reasoning tradeoff against a skeptical sponsor, reviewer, or operator.

Remediation path

• Have the learner redraw the system with deterministic and probabilistic parts separated.
• Remove one unnecessary agent or tool and explain the tradeoff.
• Add one test fixture for a critical tool or state transition.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach agent architecture, state, deterministic boundaries, memory, and reviewable reasoning through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in Customer support triage.

Before class

• Open the trainee lesson and confirm prerequisites: 3.5, 3.6.
• Prepare a weak and strong agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact for 3.7.
• Identify the exact evidence field, threshold, or decision point learners must defend.

Suggested flow

1. 22 min - frame the field problem and evidence target
2. 32 min - model the core concept or move
3. 72 min - learner artifact production or simulation
4. 36 min - critique against the evidence standard
5. 18 min - exit ticket, risk note, and next handoff

Live facilitation

• Compare single-agent, chain, and multi-agent designs against the same use case.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Demonstrate one small move, then shift quickly into learner artifact production and review.

Evidence to collect

• Architecture diagram identifies model calls, tools, state, memory, deterministic code, and human gates.
• Learner explains why the chosen autonomy level is necessary.
• State and memory have ownership, retention, and audit rules.
• Failure mode and evaluation point are visible before deployment.

Formative check

Why are structured outputs the precondition for evaluation?

Reject or remediate

• Reject multi-agent designs that add complexity without a decision benefit.
• Reject memory plans that do not say what is stored, why, and for how long.
• Reject diagrams that omit human approval for consequential actions.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact and ask them to repair the weakest evidence field.

Stretch: Ask learners to defend the agent architecture, state, deterministic boundaries, memory, and reviewable reasoning tradeoff against a skeptical sponsor, reviewer, or operator.

Remediation path

• Have the learner redraw the system with deterministic and probabilistic parts separated.
• Remove one unnecessary agent or tool and explain the tradeoff.
• Add one test fixture for a critical tool or state transition.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach agent architecture, state, deterministic boundaries, memory, and reviewable reasoning through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in Compliance review.

Before class

• Open the trainee lesson and confirm prerequisites: 3.7.
• Prepare a weak and strong agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact for 3.8.
• Identify the exact evidence field, threshold, or decision point learners must defend.

Suggested flow

1. 29 min - frame the field problem and evidence target
2. 43 min - model the core concept or move
3. 96 min - learner artifact production or simulation
4. 48 min - critique against the evidence standard
5. 24 min - exit ticket, risk note, and next handoff

Live facilitation

• Make learners name which parts are probabilistic and which must remain deterministic.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Reserve most time for build, critique, revision, and final defense.

Evidence to collect

• Architecture diagram identifies model calls, tools, state, memory, deterministic code, and human gates.
• Learner explains why the chosen autonomy level is necessary.
• State and memory have ownership, retention, and audit rules.
• Failure mode and evaluation point are visible before deployment.

Formative check

What invariants must hold over the shared state in a multi-agent graph?

Reject or remediate

• Reject multi-agent designs that add complexity without a decision benefit.
• Reject memory plans that do not say what is stored, why, and for how long.
• Reject diagrams that omit human approval for consequential actions.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact and ask them to repair the weakest evidence field.

Stretch: Ask learners to defend the agent architecture, state, deterministic boundaries, memory, and reviewable reasoning tradeoff against a skeptical sponsor, reviewer, or operator.

Remediation path

• Have the learner redraw the system with deterministic and probabilistic parts separated.
• Remove one unnecessary agent or tool and explain the tradeoff.
• Add one test fixture for a critical tool or state transition.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach Bridging Probabilistic Intelligence with Deterministic Execution through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in Banking back-office.

Before class

• Open the trainee lesson and confirm prerequisites: 3.8.
• Prepare a weak and strong example of the 3.9 Bridging Probabilistic Intelligence with Deterministic Execution instructor artifact.
• Choose the exact pause point where learners must show evidence before discussion continues.

Suggested flow

1. 9 min - frame the field problem and evidence target
2. 14 min - model the core concept or move
3. 30 min - learner artifact production or simulation
4. 15 min - critique against the evidence standard
5. 7 min - exit ticket, risk note, and next handoff

Live facilitation

• Ask learners to draw the boundary before they write code.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Have learners find the decision point, the missing evidence, and the consequence of a poor choice.

Evidence to collect

• The artifact names the field decision connected to Bridging Probabilistic Intelligence with Deterministic Execution.
• The learner separates claims, assumptions, observations, and evidence.
• The output can be reviewed against Milestone 3.
• The formative answer addresses: Where does the deterministic engine sit relative to the proposing agent?

Formative check

Where does the deterministic engine sit relative to the proposing agent?

Reject or remediate

• Reject submissions that only summarize Bridging Probabilistic Intelligence with Deterministic Execution without producing an inspectable artifact.
• Do not let case discussion stay descriptive; force a recommendation and next action.
• Reject work that hides the decision owner, risk, or next action.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed 3.9 Bridging Probabilistic Intelligence with Deterministic Execution instructor artifact and ask them to improve the evidence column.

Stretch: Ask learners to defend one tradeoff in Bridging Probabilistic Intelligence with Deterministic Execution against a skeptical sponsor.

Remediation path

• Have the learner restate the decision, evidence, and weakest assumption in three sentences.
• Require one revision that makes the artifact inspectable by a sponsor or reviewer.
• Pair the learner with a peer reviewer for a five-minute evidence audit.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach explicit interface contracts, permissions, schemas, and failure behavior through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in Enterprise ITSM.

Before class

• Open the trainee lesson and confirm prerequisites: 3.7.
• Prepare a weak and strong explicit interface contracts, permissions, schemas, and failure behavior artifact for 3.10.
• Identify the exact evidence field, threshold, or decision point learners must defend.

Suggested flow

1. 14 min - frame the field problem and evidence target
2. 22 min - model the core concept or move
3. 48 min - learner artifact production or simulation
4. 24 min - critique against the evidence standard
5. 12 min - exit ticket, risk note, and next handoff

Live facilitation

• Pause demos at failure points and ask what should have been observable.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Demonstrate one small move, then shift quickly into learner artifact production and review.

Evidence to collect

• Interface contract names inputs, outputs, auth, permissions, and error behavior.
• Tool or API boundaries are separated from model reasoning.
• The learner shows at least one failure response and recovery path.
• The contract can be handed to another builder without hidden assumptions.

Formative check

Why is tool naming a security control?

Reject or remediate

• Reject tool calls with vague schemas or unbounded permissions.
• Reject API designs that hide authentication and error behavior.
• Reject architecture that cannot explain what happens when a dependency fails.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed explicit interface contracts, permissions, schemas, and failure behavior artifact and ask them to repair the weakest evidence field.

Stretch: Ask learners to defend the explicit interface contracts, permissions, schemas, and failure behavior tradeoff against a skeptical sponsor, reviewer, or operator.

Remediation path

• Rewrite the interface as a request/response contract.
• Add one denied or malformed request case.
• Mark the human approval point for any consequential action.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach agent architecture, state, deterministic boundaries, memory, and reviewable reasoning through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in Field service.

Before class

• Open the trainee lesson and confirm prerequisites: 3.8.
• Prepare a weak and strong agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact for 3.11.
• Identify the exact evidence field, threshold, or decision point learners must defend.

Suggested flow

1. 11 min - frame the field problem and evidence target
2. 16 min - model the core concept or move
3. 36 min - learner artifact production or simulation
4. 18 min - critique against the evidence standard
5. 9 min - exit ticket, risk note, and next handoff

Live facilitation

• Compare single-agent, chain, and multi-agent designs against the same use case.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Model the concept with a concrete operational example, then ask learners to apply it to a new scenario.

Evidence to collect

• Architecture diagram identifies model calls, tools, state, memory, deterministic code, and human gates.
• Learner explains why the chosen autonomy level is necessary.
• State and memory have ownership, retention, and audit rules.
• Failure mode and evaluation point are visible before deployment.

Formative check

What two questions decide whether memory should persist beyond the session?

Reject or remediate

• Reject multi-agent designs that add complexity without a decision benefit.
• Reject memory plans that do not say what is stored, why, and for how long.
• Reject diagrams that omit human approval for consequential actions.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact and ask them to repair the weakest evidence field.

Stretch: Ask learners to defend the agent architecture, state, deterministic boundaries, memory, and reviewable reasoning tradeoff against a skeptical sponsor, reviewer, or operator.

Remediation path

• Have the learner redraw the system with deterministic and probabilistic parts separated.
• Remove one unnecessary agent or tool and explain the tradeoff.
• Add one test fixture for a critical tool or state transition.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach agent architecture, state, deterministic boundaries, memory, and reviewable reasoning through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in Finance / sales operations.

Before class

• Open the trainee lesson and confirm prerequisites: 3.11.
• Prepare a weak and strong agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact for 3.12.
• Identify the exact evidence field, threshold, or decision point learners must defend.

Suggested flow

1. 14 min - frame the field problem and evidence target
2. 22 min - model the core concept or move
3. 48 min - learner artifact production or simulation
4. 24 min - critique against the evidence standard
5. 12 min - exit ticket, risk note, and next handoff

Live facilitation

• Make learners name which parts are probabilistic and which must remain deterministic.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Have learners find the decision point, the missing evidence, and the consequence of a poor choice.

Evidence to collect

• Architecture diagram identifies model calls, tools, state, memory, deterministic code, and human gates.
• Learner explains why the chosen autonomy level is necessary.
• State and memory have ownership, retention, and audit rules.
• Failure mode and evaluation point are visible before deployment.

Formative check

What does the metadata layer add that a semantic layer alone does not?

Reject or remediate

• Reject multi-agent designs that add complexity without a decision benefit.
• Reject memory plans that do not say what is stored, why, and for how long.
• Reject diagrams that omit human approval for consequential actions.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact and ask them to repair the weakest evidence field.

Stretch: Ask learners to defend the agent architecture, state, deterministic boundaries, memory, and reviewable reasoning tradeoff against a skeptical sponsor, reviewer, or operator.

Remediation path

• Have the learner redraw the system with deterministic and probabilistic parts separated.
• Remove one unnecessary agent or tool and explain the tradeoff.
• Add one test fixture for a critical tool or state transition.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach explicit interface contracts, permissions, schemas, and failure behavior through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in Internal platform engineering.

Before class

• Open the trainee lesson and confirm prerequisites: 3.10.
• Prepare a weak and strong explicit interface contracts, permissions, schemas, and failure behavior artifact for 3.13.
• Identify the exact evidence field, threshold, or decision point learners must defend.

Suggested flow

1. 9 min - frame the field problem and evidence target
2. 14 min - model the core concept or move
3. 30 min - learner artifact production or simulation
4. 15 min - critique against the evidence standard
5. 7 min - exit ticket, risk note, and next handoff

Live facilitation

• Ask learners to draw the boundary before they write code.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Model the concept with a concrete operational example, then ask learners to apply it to a new scenario.

Evidence to collect

• Interface contract names inputs, outputs, auth, permissions, and error behavior.
• Tool or API boundaries are separated from model reasoning.
• The learner shows at least one failure response and recovery path.
• The contract can be handed to another builder without hidden assumptions.

Formative check

What does MCP buy you when an agent needs to discover a tool at runtime?

Reject or remediate

• Reject tool calls with vague schemas or unbounded permissions.
• Reject API designs that hide authentication and error behavior.
• Reject architecture that cannot explain what happens when a dependency fails.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed explicit interface contracts, permissions, schemas, and failure behavior artifact and ask them to repair the weakest evidence field.

Stretch: Ask learners to defend the explicit interface contracts, permissions, schemas, and failure behavior tradeoff against a skeptical sponsor, reviewer, or operator.

Remediation path

• Rewrite the interface as a request/response contract.
• Add one denied or malformed request case.
• Mark the human approval point for any consequential action.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach agent architecture, state, deterministic boundaries, memory, and reviewable reasoning through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in Document processing.

Before class

• Open the trainee lesson and confirm prerequisites: 3.8.
• Prepare a weak and strong agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact for 3.14.
• Identify the exact evidence field, threshold, or decision point learners must defend.

Suggested flow

1. 11 min - frame the field problem and evidence target
2. 16 min - model the core concept or move
3. 36 min - learner artifact production or simulation
4. 18 min - critique against the evidence standard
5. 9 min - exit ticket, risk note, and next handoff

Live facilitation

• Pause demos at failure points and ask what should have been observable.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Demonstrate one small move, then shift quickly into learner artifact production and review.

Evidence to collect

• Architecture diagram identifies model calls, tools, state, memory, deterministic code, and human gates.
• Learner explains why the chosen autonomy level is necessary.
• State and memory have ownership, retention, and audit rules.
• Failure mode and evaluation point are visible before deployment.

Formative check

When does a self-check loop reduce quality?

Reject or remediate

• Reject multi-agent designs that add complexity without a decision benefit.
• Reject memory plans that do not say what is stored, why, and for how long.
• Reject diagrams that omit human approval for consequential actions.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact and ask them to repair the weakest evidence field.

Stretch: Ask learners to defend the agent architecture, state, deterministic boundaries, memory, and reviewable reasoning tradeoff against a skeptical sponsor, reviewer, or operator.

Remediation path

• Have the learner redraw the system with deterministic and probabilistic parts separated.
• Remove one unnecessary agent or tool and explain the tradeoff.
• Add one test fixture for a critical tool or state transition.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.

Teaching intent

Use this lesson to teach agent architecture, state, deterministic boundaries, memory, and reviewable reasoning through the course lens of production engineering, API boundaries, agent design, semantic context, memory, and eval-ready architecture, anchored in a concrete field decision in Pick one.

Before class

• Open the trainee lesson and confirm prerequisites: 3.1–3.14.
• Prepare a weak and strong agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact for 3.15.
• Identify the exact evidence field, threshold, or decision point learners must defend.

Suggested flow

1. 29 min - frame the field problem and evidence target
2. 43 min - model the core concept or move
3. 96 min - learner artifact production or simulation
4. 48 min - critique against the evidence standard
5. 24 min - exit ticket, risk note, and next handoff

Live facilitation

• Compare single-agent, chain, and multi-agent designs against the same use case.
• Ask learners to answer: What boundary, state, tool, or evaluation choice makes this system safer to operate?
• Reserve most time for build, critique, revision, and final defense.

Evidence to collect

• Architecture diagram identifies model calls, tools, state, memory, deterministic code, and human gates.
• Learner explains why the chosen autonomy level is necessary.
• State and memory have ownership, retention, and audit rules.
• Failure mode and evaluation point are visible before deployment.

Formative check

What is the single design choice you would most regret in this system?

Reject or remediate

• Reject multi-agent designs that add complexity without a decision benefit.
• Reject memory plans that do not say what is stored, why, and for how long.
• Reject diagrams that omit human approval for consequential actions.

Rubric focus

• Artifact is specific enough for a reviewer to inspect without a verbal walkthrough.
• Evidence is tied to a field decision, not a general opinion.
• Risks and limits are explicit.
• Next action is clear and owned.

Support and stretch

Support: Give learners a partially completed agent architecture, state, deterministic boundaries, memory, and reviewable reasoning artifact and ask them to repair the weakest evidence field.

Stretch: Ask learners to defend the agent architecture, state, deterministic boundaries, memory, and reviewable reasoning tradeoff against a skeptical sponsor, reviewer, or operator.

Remediation path

• Have the learner redraw the system with deterministic and probabilistic parts separated.
• Remove one unnecessary agent or tool and explain the tradeoff.
• Add one test fixture for a critical tool or state transition.

Debrief

Ask learners what changed in their artifact after review, what evidence remains weak, and what they would show a sponsor next.