A model on its own cannot send an email. It writes text. Tools are how a product turns that text into action: the model writes a structured request, like send this message to this person, and the product executes it.
Each tool is a capability with edges the product defines: read the calendar, search the web, edit a file, place a call. The model writes the request, and the product is the one that actually carries it out.
The tool call, step by step
The app tells the model which tools exist and what they do. Mid-answer, the model can emit a tool request instead of prose. The product validates it, runs the real call, and hands the result back so the model can continue. Chaining those calls is how one instruction becomes a finished errand.
The request being structured is the point. The model does not type into your email app. It fills out a form the product designed, with a recipient, a subject, and a body. Because the action arrives as a form, the product can check it before anything runs, and that checking is what makes automation safe enough to use.
Connected apps are tools with your keys
When you connect Gmail or a calendar, you are granting scoped access that tools can use on your behalf. That is real power, which is why what a tool can reach matters more than how clever the model is. Read access and send access are very different grants.
Grants should also stay narrow and stay revocable. A well-designed product asks for your calendar when you first mention scheduling, and lets you disconnect anything in one click. Be wary of the opposite pattern, where an app wants broad access up front, gives vague reasons, and has no obvious off switch.
Failure needs designing too
Tools time out, return junk, and half-complete. Good products make actions visible, reversible where possible, and honest in reporting: booked, failed, or need your call on this. You should never wonder whether the errand happened.
An honest failure report matters more than a high success rate. A tool that fails loudly and tells you why is safe to build on, because you always know where things stand. A tool that fails silently teaches you that something worked when it did not, and believing a job was done when it was not is the most expensive mistake in delegation.