What you will learn
Workflow vs agent, Autonomy levels, Task graphs, Baselines, Stop conditions.
Engineering the capability
Break a user goal into observable steps and decisions. Some steps have fixed rules; others require interpretation or information gathering. Keep deterministic steps in application code and introduce model decisions only where they help. This makes failures easier to localize and prevents a model from controlling unnecessary parts of the workflow.
Write down success, acceptable partial completion, and reasons to stop. A research task can finish with evidence missing; a purchasing task must not silently treat a failed payment as success. Represent these outcomes in state rather than only in a conversational final answer.
A useful architecture comparison includes a fixed workflow, a single agent, and any more complex proposal. Measure task completion and resource use on the same cases. Autonomy is a design choice that increases the execution paths you must understand, test, and operate.
Worked case
To answer a policy question, the system can search, inspect evidence, and draft. If evidence is missing, it may reformulate the query once or ask a clarifying question. It does not need permission to rewrite the knowledge base or contact the customer. The task boundary determines the tool boundary.
Put it into practice
Continue with the next lab: draw and implement a task graph. Build the artifact, record the failure cases, and explain the tradeoff before moving on.