Agents, Tools, and Integrations

The concept

An agent without tools is just a chatbot that talks about doing things instead of doing them. The tools it's connected to — web search, email, a calendar, a spreadsheet, a CRM, a custom API — are what turn "the LLM thinks you should check your calendar" into the agent actually checking it. This lesson is about how those connections get made without writing code, and — more importantly — the permission decision baked into every single one.

Today, most non-developers connect an agent to tools one of two ways. The first is built-in integrations inside an AI platform itself — many assistants now ship with native connectors to common services (calendar, email, search, file storage) that you turn on with a toggle and an authorization click, no code involved. The second is no-code automation platforms (Zapier, Make, and similar tools), which sit between an AI step and dozens of other apps, letting you wire "when X happens, call the AI, then do Y with the result" without writing a line of code — the AI step becomes one block in a larger automated chain built entirely by dragging and connecting pieces.

Every one of these connections is also a permission boundary, and this is the part that's easy to skip past in the excitement of getting something working. Read-only access means the agent can look something up — check a calendar's availability, search an inbox, pull a spreadsheet row — but cannot change anything. Read/write access means it can also create, modify, or delete — book the meeting, send the email, update the row. The gap between these two is the gap between "the agent can make a mistake I'll notice when I look at its output" and "the agent can make a mistake that's already happened before anyone looks." The same tool, connected in read-only mode versus write mode, carries a completely different risk profile for an identical task.

The practical default: start every new agent in read-only mode on every tool it touches, and add write access only to the specific tool and specific action that absolutely needs it — and only after you've already designed the approval gate from the previous lesson around that exact action. An agent that can check your calendar but not book on it is far less risky to deploy quickly than one that can do both, and in most real workflows the "suggest, human confirms" pattern loses almost nothing in usefulness while removing nearly all the downside.

Worked example

A learner is building a scheduling assistant and considers two configurations for its calendar connection. Configuration A (read-only): the agent can check availability across the team's calendars and respond to "when's a good time to meet with Priya and Dev next week?" with three suggested slots — but cannot create the event itself. Configuration B (read/write): the agent can do everything in A, plus actually create the calendar event and send the invite once it has picked a time.

Reviewing both for a first deployment, the learner notices Configuration B saves perhaps fifteen seconds per use — the time it takes a human to copy a suggested slot into an actual invite — in exchange for a new failure mode: the agent could book the wrong time zone, double-book a room, or invite the wrong "Dev" if two people share that name in the directory, and the event would already exist before anyone caught it. Configuration A has an equivalent failure mode (suggesting the wrong slot) but it costs nothing to notice and ignore, since nothing has actually happened yet. The learner deploys Configuration A first, runs it for two weeks, and only considers adding write access once they've seen enough real suggestions to trust the slot-picking logic specifically — treating the upgrade to write access as its own decision, not a default.

Exercise

Take the task you sketched a workflow for in the previous lesson (Designing Agent Workflows). List the specific tools that workflow needs — aim for three, drawn from categories like web search, email, calendar, a spreadsheet, or a CRM.

For each tool, write down whether the agent needs read-only or read/write access to do its job, and justify the read/write choice specifically: what does the agent gain from write access that it couldn't achieve by suggesting the action and having a human confirm it? If you can't name a concrete gain beyond "it's slightly faster," default that tool back to read-only. Note which single tool in your list is the one you'd be most hesitant to grant write access to, and why.

Recap

• An agent is only as useful as the tools it's connected to, and today those connections are made through built-in platform integrations or no-code tools like Zapier and Make — no coding required.
• Every tool connection is a permission decision: read-only (look something up) versus read/write (also change something) carries a very different risk profile for the same tool.
• Default to read-only everywhere a human can approve the final action instead, and add write access only to the specific step where you've already built the approval gate.

Resources

• Zapier: "AI automation" — https://zapier.com/ai
• Make: "AI integrations" — https://www.make.com/en/integrations
• OpenAI: "Function calling and tool use" — https://platform.openai.com/docs/guides/function-calling