Learning bite
Give the agent a bounded job
An operational agent needs a defined goal, scoped tools, and a stopping condition.
Predict before you try
Can a plausible model explanation grant authority or establish that the saved case recovered?
Try it: Try the reasoning exercise →On this page
MicroBank in this path
Proposed design and evaluation sequence; no agent executor is supplied by this lesson. Logs and retrieved text cannot grant authority. Correct no-change and escalation decisions belong in the evaluation.
Open the diagram at full size.
Start with the operational need
An operational agent needs a defined goal, scoped tools, and a stopping condition. Use the same MicroBank contract and operating evidence from Platform engineering. The selected baseline and existing delivery owner must be known before an agent can be given a meaningful task.
What should an agent be allowed to do during an incident?
Start with a small job: investigate a delayed MicroBank case in the local lab.
Give it scoped tools to read workload state, selected logs, and the saved case result.
Set a tool-call limit and a deadline. Stop when evidence is missing or the limit is reached.
It cannot change the cluster in this first stage.
The useful output is a bounded evidence summary, with uncertainty visible.
Work through a bounded example
Goal: investigate one delayed case. Target: the named local MicroBank environment. Tools: fixed-target workload, selected-log, and saved-case reads. Budget: five calls with explicit timeouts. Stop: missing evidence, exhausted budget, or a completed evidence summary. No action tool is available.
| Contract field | Bounded first investigation |
|---|---|
| Input | One named local environment and one saved MicroBank case |
| Reads | Selected workload state, bounded logs, saved-case evidence |
| Budget | At most five tool calls, each with a timeout |
| Output | Source-linked observations, hypotheses, and missing evidence |
| Stop | Evidence missing, budget exhausted, or summary complete |
| Write authority | None in this first stage |
The five-call budget is a teaching choice. It is useful only if the tool boundary actually enforces it.
This is an offline design and evaluation fixture. No model SDK, agent executor, approval service, or live tool integration is supplied by this Markdown lesson. If you implement one, record its actual behavior and the application profile separately before describing it as working.
Try the reasoning exercise
Write the input, expected decision, allowed tools, forbidden action, observed evidence, and stopping condition. Compare the expected result with a labelled fixture first. For a later authorized local run, retain the exact tool calls and independently checked outcome.
Compare your reasoning
Begin with a small observable job and enforced read-only scope. A plausible explanation does not establish that an action was permitted or that the original operation recovered. Keep evidence, proposal, approval, execution, and verification as separate records.
Sources
Prove what you learned
Inspect the result
Record fixture/input, expected decision, allowed/attempted calls, evidence, stop condition and observed outcome.
Explain it in your own words
Explain why your observation supports the stated outcome, and name one thing it does not prove.
Try a small variation
Use one missing-evidence, injected-instruction or changed-target fixture; predict the correct refusal or escalation.
Your evidence should show
- Record the context/revision or label the work as a paper or prepared fixture.
- Compare the prediction with the actual result from “Try the reasoning exercise”.
- Record fixture/input, expected decision, allowed/attempted calls, evidence, stop condition and observed outcome.
- Explain the transfer challenge and retain the same verification question.
Hint
Separate observations, hypotheses, proposal, independent authorization, execution and verification.
Answer guide: compare after predicting
No. Enforce scope outside generated text and verify the original operation independently.
Compare this with your actual observation. A paper answer is useful reasoning practice; record execution separately.
Recall the platform support contract and independent GitOps ownership.
Save the prediction, result and explanation ↓Your notes and evidence
Record observations, questions, or links to your work. Keep credentials out of your notes.
Back up or restore this path
Progress and notes stay in this browser. A backup contains only this learning path.