Lab: draw and implement a task graph

Assignment

Use ten synthetic support questions with complete, missing, or conflicting evidence. Start with fake search results.

Build sequence

1. Draw the fixed sequence and identify exactly which decisions need model judgment.
2. Implement the fixed baseline and a version that can refine one search.
3. Define success, partial, and failed states with explicit stop reasons.
4. Compare both designs on all ten cases.

Acceptance checks

• Every path terminates within the declared budget.
• The agent cannot access tools unrelated to the task.
• The comparison explains where autonomy helped and where the fixed workflow was sufficient.

Evidence to keep

Submit the working artifact or decision document described above, the inputs used, and the observed results for every acceptance check. Include one failed attempt and the change you made after investigating it. Label fixture-based outcomes separately from live-system measurements. These artifacts become part of your final portfolio review.

Guided workshop: implement the simplest support workflow

A fixed workflow is often enough when the sequence is known: read the ticket, retrieve evidence, draft an answer, and request review. An agent introduces model-selected steps. Compare both against a defined task before granting more autonomy.

Copy code# academy-check

def support(ticket, search, draft):
    if ticket is None:
        return {"state": "missing_ticket"}
    evidence = search(ticket["question"])
    if not evidence:
        return {"state": "needs_information"}
    proposal = draft(ticket["question"], evidence)
    return {"state": "awaiting_review", "proposal": proposal}

assert support(None, lambda _: [], lambda *_: "") == {"state": "missing_ticket"}
assert support({"question": "help"}, lambda _: [], lambda *_: "")["state"] == "needs_information"
result = support({"question": "reset"}, lambda _: ["Settings"], lambda q, docs: docs[0])
assert result == {"state": "awaiting_review", "proposal": "Settings"}

The injected functions make dependencies visible. This workflow never sends a response to a customer. awaiting_review is a durable business state in a real implementation, not a prompt asking the model to behave politely.

Draw the graph: include entry, missing-ticket stop, retrieval, insufficient-evidence stop, drafting, review, rejection, and completion. Annotate each edge with the condition that permits it. For every side effect, name the authorizing component and the operation ID used for replay.

Challenge: introduce a question that requires two searches. Compare a fixed two-search workflow with a bounded agent choosing the second query. Give both the same evidence collection, maximum calls, and evaluation cases. More searches are not automatically better; measure supported answers, unnecessary calls, and stop behavior.

Worked decision: if almost every ticket uses the same known source and sequence, the fixed workflow offers predictable testing and latency. If query refinement improves success on genuinely varied tasks within the same budget, adaptive search may be justified. Keep mutation approval outside either model's decisions.

Assessment: explain the distinction between model reasoning and executable runtime transitions. A model's proposed next step is data until the runtime validates and dispatches it. Submit the graph, three fixture traces, and a written autonomy decision based on observed task outcomes.