Understand tools, workflows and agents

A tool connects a model to an operation

A tool is a capability the application can call: search a collection, calculate a total, save a document or create a calendar entry. Writing “I will add it” is different from receiving confirmation that the entry exists. In a common pattern, a model requests an operation, application code carries it out and returns the result. The Claude tool guide documents one implementation.

Optional technical vocabulary: an API is a defined way for one program to request work from another. An orchestrator coordinates steps and passes the results between them. MCP, Model Context Protocol, is a shared connection standard for exposing capabilities to AI applications; see its tools specification. JSON is a text format with named fields, such as a date and a title, that programs can process. None of these terms is a prerequisite for asking an ordinary question.

A fixed route and a choosing system

A workflow follows a predefined route: take notes, prepare a draft, show it to you, then save the approved version. An agent can choose its next operation according to the situation, such as looking for another relevant source. This architectural distinction is explained by Anthropic; the older article's implementation examples need fresh checking.

Think of the difference between following a recipe and deciding which recipe or ingredient information to consult next. More freedom is useful only if the choices help the task. For a simple repeated preparation job, a small fixed sequence may be easier to understand and maintain.

Worked example: notes to an invitation

Use this fictional note: “A board-game afternoon, Sunday at 16:00. Bring a game if you want. Address to be confirmed.” Ask for a short invitation and a list of missing details. An illustrative draft is: “Join us for board games on Sunday at 16:00. Bring a game if you like. I will confirm the address.” Missing: the address and which calendar date Sunday refers to.

The useful transformation is from rough notes to a message you can finish. You select the actual recipients and confirm the missing details. A connected process could then save the approved draft in your notes. Sending it is a separate choice; a draft is already useful without that connection.

If saving is requested, the application should return confirmation of the actual saved item. If the response is lost, check whether the item exists before retrying. Otherwise a single draft can become two. This is one reason the connections need more than a clever prompt.

What automation does not solve

A structured record can still contain the wrong date. A working connection can save to the wrong place. Approval can become outdated if the text changes afterward. Show the exact proposed content and destination, and apply approval to that version.

For your first experiment, use invented notes and save manually. Add a connection after the preparation itself is useful. For an organization, the same pattern can prepare a client record, but access and responsibility need to be defined for that setting. The lesson does not set up an actual integration.