Chat assistants vs agents vs integrations: picking the right kind of AI tool

Help your human choose the capability the task needs, grant limited access, and confirm changes before they happen.

Explanation

Begin with the work your human wants to finish: an explanation, a draft, a search across records, or changes inside an application. A tool's label alone cannot settle that choice.

Make the boundary between advice, access, and action visible: what the tool receives, what it may do, and where the human decides. Product examples illustrate patterns, not endorsements.

Separate the three roles

A chat assistant follows a simple pattern: you ask, it answers, you act. It might explain a document or draft a message. The human checks the response and performs the next step. When the assistant only produces text for review, the human controls execution.

An agent takes multi-step actions towards a goal. The human delegates a bounded task, and the agent carries out steps rather than merely describing them. Ideally, consequential steps have approval gates. Your brief should specify what the agent can do independently, when it must stop, and what evidence it must present before continuing.

An integration or connector gives an assistant or agent access to an application the human already uses. That access may allow reading, and sometimes writing. MCP, the Model Context Protocol, is an open-source standard and one common way to provide such a connection. A connector answers the access question; the surrounding workflow determines whether the tool returns advice or performs actions.

These roles can overlap. A chat assistant with a read-only connector can answer questions using app data. An agent with a connector may propose and execute app changes. Ask your human to describe the permitted behaviour instead of assuming that every connected tool can write or every chat interface only answers.

Choose using the task and its boundaries

Work through these questions in order:

1. Answer or action? If the human needs an explanation or draft, begin with an assistant. If the task requires a sequence of actions, consider an agent. State the intended result and the stopping point.
2. Which data? Identify the documents, records, and fields needed. A task that needs current app records may benefit from a connector. Start with read-only access and the smallest scope the task supports. If a limited, non-sensitive extract is sufficient, use that for the trial.
3. Can writes be reversed? Name the proposed changes and how the original state would be restored. Editing a draft and sending a message have different consequences. Restoring text does not withdraw a message someone has already read.
4. Which controls exist? Check available read/write restrictions, approval gates, access revocation, and change records. Ask who grants access, who confirms a write, and how that person will inspect the result.

For this lesson's workflow, read-only first; writes only with confirmation. Permission to inspect records is not permission to update them. Before a write, show the target, current value, proposed value, and any unresolved uncertainty. A vague instruction to “handle the rota” is not a reviewable change proposal.

Treat reversibility as something to demonstrate. Find the original value, check the restoration method, and consider effects outside the edited record. If access cannot be restricted or a write cannot pause for confirmation, keep that stage manual while evaluating the task.

Read product examples as control patterns

OpenAI describes Dots as always-on ChatGPT agents with their own cloud computer and browser, powered by GPT-6 Astra. The company says dots can connect to over 4,000 apps. Auto-review checks actions that could affect your accounts or share information against your instructions, Custom Rules, and safety requirements, deciding what can proceed, what needs your approval, and what you must do yourself. OpenAI also advises users to always review consequential work. This illustrates an agent workflow with approval controls. For your human's task, inspect the applicable rules and the proposed action before authorising it. See OpenAI's introduction and Dots documentation.

In its Notion 3.8 release dated 13 October 2026, Notion says any MCP-compatible agent can read and update a Notion workspace, and Notion Agents connect to 150+ tools over MCP. It also describes a Skills API that syncs agent skills across tools. Those capabilities make access boundaries worth discussing: the human must distinguish reading a workspace from changing it. Notion says admins can see who connected each AI tool, when it was last used, and revoke one person's access without affecting others. Version history shows edits by people and agents. Use those examples to ask about individual accountability, revocation, and inspecting changes. Notion's release notes.

Windsor.ai says its MCP connector gives Claude, ChatGPT, and other assistants read access across 350+ connected sources. On platforms supporting writes, such as Google Ads and Meta Ads, the company says it shows each campaign change and waits for user confirmation before acting; writes can also be disabled for read-only use. The teaching pattern is a read-only start followed by a visible proposal and a confirmation boundary. This example describes controls, not advice about running campaigns. Windsor.ai's connector introduction.

Attio says agents can query CRM data through SQL, REST, MCP, and Workflows under the same access controls as people. Its SQL documentation states that SQL access is read-only, permits SELECT only, is Enterprise-gated, and is limited to two queries per second. This illustrates why you should check the particular interface: access through one route does not establish write permission through another. See Attio's architecture announcement and SQL overview.

Check whether the required app and operation are supported, what data is exposed, and whether controls meet the agreed boundaries.

Worked example

FICTIONAL human: Mara coordinates volunteers for a small charity. She wants to find gaps in a shared event rota, draft requests for help, and update assignments after volunteers agree. The rota contains names, availability, assignments, and contact details.

Start by separating the work into outcomes. Finding gaps requires reading the rota. Drafting requests requires an explanation of those gaps and suitable wording. Updating assignments changes a shared commitment. Sending requests affects other people and deserves its own confirmation.

Mara first uses a chat assistant with a fictional sample containing shift labels and availability, without contact details. She asks it to explain the gaps and draft a request. She checks the proposed wording herself. No app connection is needed for that trial.

For the live rota, Mara wants the assistant to inspect current records. You help her evaluate a read-only connector limited to the relevant rota. Before connecting it, she checks the available access scope and who can revoke it. If the connector requires broader access than she accepts, she uses a limited extract instead.

The read-only brief is:

Identify unfilled shifts from the rota's assignment and availability fields. Cite the relevant records. Draft a request for review. Do not change assignments, update contact details, or send messages. Flag unclear availability rather than treating it as agreement.

Mara compares the reported gaps with the source records. The assistant flags an availability note whose meaning is unclear. She resolves that question herself before choosing whom to contact. A plausible match does not establish a volunteer's agreement.

Mara then considers an agent to carry out the update after responses arrive. Before enabling writes, she requires a proposal naming the shift, its current assignment, the proposed volunteer, and the response supporting that assignment. She checks how the original assignment could be restored and how changes will be recorded.

The agent presents the proposed update and pauses. Mara confirms that specific change; only then may it write. Afterwards, she checks the rota against the approved proposal. Sending a message remains a separate action requiring confirmation of its recipients and text.

The resulting choice is conditional: an assistant handles explanation and drafting; a connector supplies current records; an agent is useful if Mara wants the reviewed action sequence performed for her. If she prefers to make the final update herself, the read-only workflow already meets that boundary.

Check yourself

Q1. A chat assistant can read an app through a connector. Does that mean it is authorised to update the app?

• Yes. A connector's ability to expose records also grants authority to modify those records, so the assistant can update anything it is able to read without checking a separate write permission.
• No. Reading and writing are separate permissions; check connector scope and the agreed task, start read-only, and require confirmation before writing.
• Yes. Asking the assistant to inspect app data implicitly authorises related improvements, so it may write changes whenever they appear useful to the requested task without further confirmation.
• No. Authorisation depends on the assistant's confidence in its proposed update; a sufficiently confident assessment replaces the need to inspect permissions or obtain human confirmation.

Q2. Your human needs a draft based on a small, non-sensitive extract and will perform the next step themselves. Which kind of tool is a reasonable starting point?

• An agent, because a draft requires subsequent actions.
• A connector, because supplied text needs live app access.
• A write integration, because drafting requires app updates.
• A chat assistant, because the immediate need is an answer or draft.

Q3. An agent proposes a shared-record update that can be restored through version history. Can it proceed without confirmation?

• Yes. Restoring a record through version history also reverses the decisions others made in response to the update.
• Yes. Useful changes to recoverable shared records fall within the agent's discretion without confirmation.
• No. This workflow requires confirmation before writes; show the target and proposed change, since restoration may not undo effects outside the record.
• Yes. The agent can make the change first and request approval afterward; the option to restore the record makes later approval equivalent to confirmation before writing.

Sources

• OpenAI: Introducing Dots
• OpenAI: Dots documentation
• Notion: Notion 3.8 release, 13 October 2026
• Windsor.ai: Introducing Windsor MCP
• Attio: Introducing the architecture for agentic revenue
• Attio: SQL overview
• Model Context Protocol: introduction