Thursday briefing: agents, context, and the jobs tools were bought for

The thread running through today's announcements is not any single feature. It is what sits behind the software: the data a tool can reach, the people it has to bring on board, and the job it was bought to do in the first place.

Four items are worth the attention of anyone choosing business tools right now. One is about AI agents and the results early users say they are getting. One is about feeding a model the context you already hold. One is about the unglamorous work of onboarding. And one is a straight comparison between two products built for two different jobs. None of them is a reason to switch anything this week, but together they sketch the questions a buyer should be asking.

AI agents and the results early users report

Salesforce put out material on what it calls the agentic enterprise, framed around the experience of early adopters rather than a product tour [1]. The line worth reading past the announcement is that named companies say they are getting something out of it: "Salesforce customers are at the forefront of the agentic revolution, and they're already seeing real-world value from it" [1].

It helps to be precise about what an agent is before deciding whether it matters to you. An agent is software that takes an instruction and then carries out a sequence of steps towards it, rather than answering a single question and stopping. It might read a record, decide what to do next, take an action, and check the result. That is a different thing from a chatbot, and it raises a different question. The question is not whether an agent can act. It is where it acts, what it is allowed to see, and what it is allowed to change.

That boundary is the whole decision. An agent that can only read is a research assistant. An agent that can write is a member of staff, and it needs the same scoping you would give a new hire: access to the things it needs and nothing else. Before you let any agent loose on live data, it is worth being clear about the line between the work you want it to do and the work it should never touch. We wrote about drawing that line in what AI should and should not do in your business, and the principle holds regardless of whose agent it is. The early-adopter framing is useful precisely because it moves the conversation from capability to consequence.

Context is the fuel, not the model

Dropbox announced a way to bring the context you keep in Dropbox into Google Gemini [2]. The description is plain: "Connect Dropbox to Gemini to bring the context you already keep in Dropbox into your AI workflows" [2].

This is the more important half of the AI story, and it is easy to miss under the headlines about models. A model knows language. It does not know your business. Its answers about your quotes, your contracts, or last month's project notes are only as good as the material it can actually reach at the moment you ask. A brilliant model with no access to your files will give you a confident, general, and useless answer. A modest model with access to the right document will give you the specific one you needed.

So the pattern being announced here — a bridge between a store of documents and a model — is the pattern that decides whether AI is helpful to you or just impressive in a demo. It is also the pattern that quietly breaks. Every one of these connections is a join between two systems that were built separately, and joins drift. Permissions change on one side and not the other. A folder is renamed. We have written before about why your tools do not talk to each other, and a document-to-AI bridge is subject to exactly the same fragility.

There is a trade-off to hold in view. The more places your AI can read from, the more you have to think about what leaves which system and who is allowed to ask. A connection that lets a model read your files is, by definition, a new door into those files. That is not a reason to avoid it. It is a reason to know, on any given day, what can walk through it.

Onboarding is a workflow, not a welcome email

Zapier published a roundup of employee onboarding software [3], and its opening is a fair description of the problem: "The employee onboarding period is filled with information, forms, and meetings" [3].

It is worth noticing that onboarding a person and adopting a new system are the same shape of problem. Both are a first week in which a lot of information arrives at once, several forms need completing, and nobody yet has the habits that will make the tool feel natural in a month. The reason onboarding software exists is that the first week is where most of the value is either captured or quietly lost. If the forms are chased by hand and the steps live in one person's head, the process works until that person is on holiday.

The useful idea underneath the category is that onboarding is a workflow with a defined start, a defined end, and a set of steps that should happen in order whether or not anyone remembers to trigger them. That is true of bringing on a new colleague, and it is just as true of bringing a team onto a new tool. We set out a practical version of this in what to do in the first week with a new system: decide the handful of things that must be true by Friday, and make those the whole plan. A tool that turns the first week into a checklist that runs itself is doing real work. A tool that just stores the checklist still leaves the chasing to you.

Two tools, two different jobs

Zapier also ran a comparison between ClickFunnels and Shopify [4], and it grounds the piece in a concrete user: "Yoto, an audio player for kids, uses Shopify to power its 1,200-product eCommerce store" [4].

The reason a comparison like this is instructive has little to do with which product wins. It is that the two were built around different primary jobs. One is built to run a catalogue and fulfil orders at scale — a business with more than a thousand products has a very particular set of needs around inventory, variants, and shipping. The other is built around the funnel: fewer products, more attention on the path from a landing page to a purchase. Both can sell something. They are not the same tool wearing different colours.

The practical lesson for a buyer is to match the tool to the job you actually do most, not to the job you might do one day. A business with a large catalogue and steady fulfilment has different centre-of-gravity needs from a business selling one or two offers hard. If you choose the tool built for the other shape of business, you will spend your time working against its defaults. This is the same discipline we argue for in what a CRM is actually for: decide what the system is really for in your business, then judge every option against that, rather than against a feature list that flatters whoever wrote it.

None of today's news demands action. But it is a good day to ask four small questions. What can our AI actually see. What breaks quietly between our tools. Does our first week with anything new run itself or rely on someone remembering. And is each tool we pay for built for the job we mostly do. The answers tend to be more useful than any launch.