Adopting AI engineering is not about picking a model. It is closer to taking on a capable new colleague whose work is sometimes brilliant and sometimes wrong in ways nobody predicted. The real decisions are how much freedom to give it, which safeguards make that freedom acceptable, and which parts of the system to build, adopt or go without. Bad decisions rarely show in the demo; they show in the first surprise invoice or the first incident.

This lesson pulls the course together around three decisions: choosing the lowest level of autonomy that solves the problem, deciding what to build and what to adopt, and placing safeguards outside the model. It then lists the common mistakes and the skills that support all three. The course's three products serve as examples of concrete choices, not universal recipes.

Use the least autonomy that solves the problem

AI systems range from a single call to a model to several working together. Each step up lets the model decide more, and adds cost and risk that only pay off if the problem needs it. Most real applications live in the first three levels.

Level	Who decides the next step	Main safeguard	Good fit for
1. App calls a model	nobody; there are no actions	checking the output	generating, summarizing, extracting
2. Workflow	your code	the design of the steps	known processes, answering from documents
3. Agent	the model	the instructions	low-risk exploration
4. Agent with a harness	the model, within limits	caps on how long it loops	agents that run without constant watching
5. Governed harness	the model, under rules	policy, approvals, isolation	real systems with real effects
6. Several governed agents	several models	all of the above, plus checks between roles	a measured need to separate duties

The jump from level 2 to 3 changes risk the most. Before it, you write the sequence of actions; after it, you design the space of actions the model may choose from (From LLM app to agent). A , the program that runs the agent's loop, makes an agent dependable, but it only makes it safe once rules and isolation are added.

What to build and what to adopt

Almost every layer has ready-made options:

Category	What it saves you	Examples
Agent frameworks	writing the loop and tool handling yourself	LangGraph, OpenAI Agents SDK, Pydantic AI
Coding agents	building an agent that works in a codebase	Claude Code, Codex, OpenHands
Model gateways	juggling many model providers	OpenRouter, LiteLLM, Vercel AI Gateway
Observability	reconstructing what happened and what it cost	OpenTelemetry, Langfuse, Arize Phoenix
Evals	measuring quality and catching regressions	promptfoo, DeepEval, Inspect AI, Ragas
Sandboxes	running code without risking the host machine	gVisor, Firecracker, E2B, Modal
Durable execution	workflows that survive crashes	Temporal, Restate, DBOS

One of docket's design records boils the choice down to a single test (ADR 0005: Cutting half of Phases 20 and 21 as overengineering): have you measured a need for this part in your system, or is it only something that works well for others? Applying it, docket dropped OpenTelemetry: sensible for a large platform, not needed by one operator on one machine. Build what sets you apart or what no vendor can provide under your constraints, such as data that must stay in-house, compliance rules or owning the point where actions are approved. Adopt the rest, and write down which layers you leave out on purpose.

The three products decided differently, each for a stated reason:

In docket

Modelproposes an action
Policy checkevery action, no exceptions
- Allow
- Ask a person
- Deny
Tool runsonly if allowed or approved
Resultgoes back to the model

the next turn of the loop

Because docket runs the loop itself, every action passes this checkpoint. Inside a framework, the checkpoint would live in someone else's code. Source: ADR 0002: Own the loop, rent the protocols · Security: Layered & Convention-Based

Put the safeguards outside the model

The useful question is not "should the model refuse?" but "which part of the system stops this?". An instruction in the has to compete with text that presents itself as a requirement. A check on commands can pause and ask a person. A network that only reaches trusted package sources makes the download impossible.

The promptasks the model to be careful
Command checkpauses commands known to be risky
The networkonly trusted sources are reachable

The further down a safeguard sits, the harder it is to talk around. Convincing text can outweigh a prompt and a variant can slip past a command check, but a download from an unreachable site simply fails.

Safeguards fall into three groups, and a sound system uses all three. Prevent: grant only the permissions needed, keep secrets out of reach, require approval for risky actions. Contain: isolate execution, restrict the network, cap and loops. Detect and recover: keep traces and an audit trail, and be able to cancel and roll back. A good prompt helps in all three but guarantees none. A loop left running all weekend, for example, is only stopped by a total budget, not by a limit per step. See Governance and human-in-the-loop and Sandboxing and agent security.

Common mistakes

Relying only on the system prompt. It handles the normal case; rules enforced in code handle the worst one.
Secrets within the model's reach. They end up in logs or commits; keep them inside the tool.
No budget, no timeouts. Cap spending per call, per task and per project.
Retries that are not safe to repeat. The result is two charges or two deploys (Durable agent execution).
Several agents because it sounds advanced. Add a role only when a measurement shows it helps (Multi-agent systems).
Judging only the final answer. Evaluate the steps too, and check automated judges against people.

The skills underneath

These decisions rest on skills that build on each other, best organized by capability rather than by tool, because tools change. They run from software basics, such as retries that never duplicate an effect, through how models, documents and agents work, to the controls this course covers: rules and isolation, , tracing, and security. The top is architecture: justifying every part, and every part you chose not to build. Running through all of it is the habit of distrusting claims, your own included, until you see them hold in real use.

Putting it into practice

Start at the lowest level that works, and move up only when a measured need asks for it.
Ask of every component what measured need it serves here. If nobody can answer, leave it out and write down why.
Ask of every risky action which layer stops it if the model gets it wrong. If the answer is "the prompt", it is not stopped yet.
Decide early what your source of truth for cost is, and cap spending per task and per project.

Go deeper

Each product documents the reasoning behind its choices:

Stack and decisions walks through each part of Adapta, what else was considered for it and which folder holds its code.
DOCKET Architecture describes docket's layers and why it runs the agent loop itself instead of relying on an outside agent process.
Security: Layered & Convention-Based lays out docket's safeguards layer by layer, from agent instructions to the check every tool call passes, including what is not gated.
Introduction explains how Tack leaves the agent to existing tools such as Claude Code or Codex and keeps planning, history and recovery for itself.

Key takeaways

Choose the lowest level of autonomy that solves the problem; each level adds cost and risk.
Build what sets you apart or what your constraints demand; adopt the rest and state what you leave out.
Guarantees live outside the model: permissions, rules, network, secrets and budgets.
Justify each component with a measured need, not a trend.

Check yourself

Why is the jump from a workflow to an agent the biggest change in risk?

In a your code decides every step. In an agent the model chooses among the actions you allow, so you stop writing the path and start designing the space of possible paths, bad ones included.

An agent finds a README telling it to download and run a script. Which safeguard stops that most reliably?

A network that only reaches trusted sources. A prompt can be outweighed by convincing text, and a command check can miss a variant, as docket's does with a Python one-liner. Without network access, the download fails whatever the command looks like.

Why would a team build its own agent loop instead of adopting a framework?

When owning the point where every action is checked matters more than convenience, as with docket. Whoever owns the loop owns those checkpoints, so a framework would make the safeguards depend on someone else's design.