Both phrases are used for the same products, which is why neither tells you what you are buying. The useful distinction is not intelligence. It is who does the fetching.
Key takeaways. An assistant works from what you paste into it. An agent works from what it can reach on its own. The dividing line is not model quality — it is whether the tool can gather context and take action without you brokering every step. An agent is only useful in proportion to what it is connected to, and only safe in proportion to what it refuses to do unsupervised. The question to ask a vendor is not "is it agentic" but "what can it do without asking me, and what stops for approval".
The distinction nobody agrees on. Every tool with a text box now calls itself an agent, and most of the ones that do are assistants with a longer context window. That is not a complaint about marketing so much as a practical problem: if the two words mean the same thing, neither of them helps you predict what the product will do on a Tuesday morning. The version of the distinction that survives contact with real use is narrow and slightly boring. An assistant responds to what is in front of it. An agent goes and finds what is in front of it first. That sounds small. In practice it changes almost everything about how the tool fits into a day, because the expensive part of most requests was never the thinking. It was the assembling.
What an assistant actually does. A chat assistant is extraordinarily good at transforming text you hand it. Summarise this, rewrite this more warmly, turn these notes into a plan, explain this error. The quality of the answer is bounded almost entirely by the quality of what you pasted in. This is why the honest complaint about assistants is rarely that the output is bad. It is that getting to the point where you can ask is the work. Consider a request as ordinary as "help me reply to this thread". Open the thread and read it, because you have to know what it says to know what to paste. Copy the relevant messages, minus the signature blocks and the three forwards nobody needs. Remember the thing you promised on a call last week that is not in the thread at all. Check whether you are actually free on the date they proposed. Paste all of it into a text box with an instruction. Copy the result back into the mail client and send it. Steps two through five are the job. The assistant did step six-and-a-half. That is genuinely valuable, and it is also why the productivity gain from chat assistants tends to feel smaller than the demos promised — the demo starts at step five.
What an agent adds. An agent starts at step one. It has authenticated access to the places the context lives, so "help me reply to this thread" means it opens the thread, reads it, checks your calendar for the date they proposed, notices the task you filed about this two weeks ago, and comes back with a draft that accounts for all three. The word for that capability is not intelligence, it is reach. A smaller model with access to your calendar will beat a frontier model that has to be told what your week looks like, for the specific class of request that depends on knowing what your week looks like — which is most of the requests anyone has about their own day. The second half of the definition is action. An agent that can read everything and change nothing is a very good search engine. Being able to write the draft, book the room, add the task and mark the other three done is what closes the loop, and it is also the part that requires an answer to a question assistants never had to ask: what is it allowed to do without checking with you first?
The question that actually separates products. Once a tool can act, "is it an agent" stops being the interesting question. The interesting question is where its boundary sits, and most product pages are quiet about that, because a confirmation step is friction and friction does not demo well. Ask it plainly. What runs on its own? What stops and asks? What happens if I say no? A product that cannot answer those three in a sentence each has not decided, and a boundary nobody has decided is a boundary that moves. Drift stops and asks before anything reaches another person, and before it deletes something. Everything else — reading, and work inside your own account that you can undo — runs without interrupting you. Drift draws the line at recoverability rather than at importance. Reading costs you nothing if it is wrong. Work inside your own account can be undone. An email that has already reached somebody cannot be, so sending, replying and forwarding always stop on a confirmation card that shows every recipient and the full body before it goes. There is a real cost to that choice, and it is worth naming: a product that asks about everything teaches you to approve without reading, which is worse than not asking at all. That is the reason the list of things Drift does not ask about is as deliberate as the list of things it does.
How to tell which one you are looking at. Three questions, none of which require a trial. What does it connect to? If the answer is nothing, it is an assistant, however it is described. Reach is the whole distinction. Can it change anything, or only describe things? A read-only integration is a window, not an agent. What does it refuse to do without you? If there is no answer, the boundary has not been designed, and you will find its edges the hard way. Neither category is better in the abstract. If your work is mostly writing and thinking with material you already have open, an assistant is a cleaner fit and you should not pay for reach you will not use. If the friction in your day is that the context is scattered across four accounts and assembling it is the job, that is the specific problem an agent exists to solve.
Connections are what make it an agent, so in a narrow technical sense that is close. The practical difference is who does the assembling: a chatbot with a plugin still waits for you to decide which context matters and to ask for it, while an agent decides what it needs to read, reads it, and answers from what it found.
It should not, and a well-designed one does not. Asking about every read teaches you to click approve without looking. Drift draws the line at recoverability: reading, and work inside your own account that you can undo, runs without interrupting you, while anything another person would see waits for an explicit approval.
Drift is built around Gmail, Google Calendar, Google Tasks, and Notion, and reaches further through its connections catalog. You choose what to connect and can disconnect anything at any time in Settings.