Before giving an AI agent tools, define its boundaries

An assistant that writes a draft and an assistant that publishes it have different responsibilities. The first produces a proposal. The second changes something outside the conversation. Treating the two as the same step makes it harder for a person to review the result.

Start with a narrow workflow: retrieve approved course information, prepare a cited draft, and pause for review. The action tool should accept only the intended operation. A course-note assistant does not need a general shell command or permission to export learner records.

If a human approves the draft, bind that approval to the exact content. Changing the draft afterward should require another review. Also decide what happens when a request is retried. The same approved action should not create duplicate messages merely because a network response was lost.

The local teaching simulator makes these ideas concrete using a proposal digest and an in-memory outbox. It blocks unapproved execution, rejects changed content, and creates one entry when the same proposal is executed twice. This is a demonstration of boundaries, not an authenticated publishing service.

An actual deployment needs additional work: identity checks, persistent records, concurrency handling, expiry, and appropriate tool authorization. A model should never be able to approve its own proposed action simply by returning a field named approved.

Only then consider where model-directed planning would help. A fixed process may be sufficient for a recurring announcement. More open-ended research may justify a bounded agent loop. Anthropic's engineering guide provides a useful distinction between predefined workflows and model-directed agents, while recommending that added complexity earn its place through evaluation. Building effective agents

Agentic AI: Tools, Workflows & MCP turns these ideas into a practical project with traces and failure tests. The goal is a system whose actions you can understand, check, and control.