Agentic systems map

Draw and defend an AI-SRE loop from operational signal to measured outcome without hiding behind product names.

Learn Lab Incident Review Mentor guide

Create the mental model the team will use for every later decision. Engineers learn to separate a deterministic workflow from an agent, locate autonomy, and identify where state, identity, evidence and human judgment live.

Prerequisites

Core Learning OS foundations at L2
AWS IAM, APIs and CloudWatch at L2
Ability to trace a normal web request

01 / CONCEPT LESSONS

Build the mental model first.

Workflow, assistant and agent

A workflow follows known transitions. An assistant proposes. An agent selects actions using a model. Use the least autonomous form that can solve the problem.

The control loop

Observe, interpret, choose, act and verify. Every transition needs inputs, outputs, ownership and a stop condition.

State and memory

Execution state supports the current run; durable memory influences future runs. Both require lifecycle, retention and access decisions.

Tools are authority

A tool contract is not merely a function signature. It is the exact authority an agent can exercise, with validation, limits and audit evidence.

Human approval

Approval belongs before the irreversible boundary. The reviewer needs enough evidence to judge, not a vague request to click approve.

02 / SYSTEM FLOW

Trace the complete path.

Operational signal→Context collection→Model reasoning→Policy check→Human approval→Bounded tool→Outcome verification→Trace + cost record

For every arrow, the engineer must name the data, identity, trust boundary, failure mode and evidence produced.

03 / GUIDED LAB

Build it in bounded steps.

AI and documentation are allowed. The learner owns every generated artifact and must preserve the stated safety boundaries.

01Choose one recurring internal alert with no client data.
02Draw the current human diagnostic path.
03Classify each step as deterministic, probabilistic or judgment-based.
04Propose the smallest agent-assisted loop; keep actions read-only.
05Mark data, identity, network and approval boundaries.
06Walk another engineer through one successful and one failed run.

04 / INCIDENT SIMULATION

A generated recommendation reaches a write-capable tool without meaningful review.

Mentor injects

Approval message omits the target resource
Tool role allows a broader action than its name suggests
The execution trace does not record the approver

Required evidence

Boundary where excessive agency entered
IAM and tool-contract evidence
Revised approval payload and audit event

Investigation loop

Symptom → impact → hypothesis → evidence → test → root cause → containment → correction → verification.

05 / DESIGN CHALLENGE

Start with a blank page.

Design the same diagnostic capability three ways: runbook-only, deterministic Step Functions workflow and bounded agent. Recommend one using complexity, risk, latency and value.

06 / VERIFY & SUBMIT

Verification checklist

Every component has one purposeEach data transition is visibleIdentity is shown separately from networkingAll write actions have an approval boundaryStop and escalation conditions are explicitOutcome and cost are measurable

Submission package

Before/after architecture diagram
Boundary and trust table
One-page design decision record
Failure walkthrough
Five-minute teach-back recording or notes

Review questions

What makes this an agent rather than a workflow?
Where could untrusted text influence a tool call?
What state survives a retry?
Who can stop the loop?
Which claim in the design is still an assumption?

07 / MENTOR-ONLY GUIDANCE

Pass only when the engineer can remove product labels and still explain the system. Probe the exact point where model output becomes authority.

SCORING1 · cannot explain2 · explains with gaps3 · implements and verifies4 · designs and handles trade-offs

Record the achieved L-level only from observed evidence. Course completion and certification do not automatically change the skill matrix.