Delegation and its boundaries across the week's tool news

The announcements that landed today share a single question: how much of a decision are you willing to hand to something that is not a person at a keyboard, and what boundary does that hand-off need to stay safe. A customer's software agent, a branching automation, and a calendar that outlives its owner are the same problem in different clothes — delegation, and the limits that make delegation survivable.

When a customer arrives as an agent, not a person

For most of the history of online business, the thing on the other side of a form was a human. That assumption is quietly ending. Salesforce framed the shift plainly today, describing a near future in which a customer does not visit your site or open a chat themselves but sends software to act for them — to compare prices, book the slot, file the complaint, or complete the purchase [1].

The concept worth understanding is that an agent is not a visitor and not quite a customer either. It is an authenticated stand-in, carrying out instructions on behalf of a named person. That changes three things a business usually takes for granted. First, identity: you now have to know whose agent this is and what it is allowed to do, which is a different question from who is logged in. Second, pace: an agent can read your entire catalogue and your terms in a second, so anything you rely on a human not noticing will be noticed. Third, consent: when an agent acts, the person is still responsible, and your records have to show that the action was authorised.

The trade-off is the one Salesforce names — admit these agents or refuse them. Refusing is simpler for a quarter and slowly cedes convenience to whoever admits them. Admitting them means building the identity and permission plumbing before the traffic arrives, not after. This is less a technology decision than a policy one about what you let a non-human act on. We have written before about what AI should and should not do in your business, and admitting a customer's agent is the mirror image of that question: not what your AI does for you, but what someone else's does to you.

Automation that can decide and look things up

The second thread is about automation growing a brain. Google announced new logic and search steps for Workspace Studio as part of its October release, extending what its automations can do across Gmail, Meet, and Drive [2].

The idea to hold onto is the difference between a straight line and a branch. Early automation was linear: when this happens, do that. Useful, but brittle, because real work has conditions. A logic step lets an automation ask a question — is this invoice over a threshold, is this sender a known client — and take a different path depending on the answer. A search step lets it find a record it was not handed, rather than only acting on the one that triggered it. Together they move automation from a tripwire to something closer to a clerk following a checklist.

The trade-off is that a branch is a decision, and a decision can be wrong in ways a straight line cannot. A linear automation that misfires does one visible thing. A branching one can quietly take the wrong path for weeks before anyone notices the pattern. That is why the maturity of an automation is measured less by what it can do and more by how you test it and how you see what it did. Before you reach for a new logic step, it is worth being honest about whether the task should be automated at all — a question we walked through in how to tell whether a task should be automated. More capability is not the same as more judgement; it is more surface to get right.

What happens to the calendars a person leaves behind

Google's weekly recap carried a smaller item with a long tail: secondary calendars will now follow the lifecycle of their owner for non-personal Workspace accounts [3].

This sounds like housekeeping and is really about ownership. A secondary calendar — a room booking schedule, a project timeline, a shared on-call rota — is created by a person but used by a team. The question every growing organisation eventually hits is: when that person leaves, is the thing they created theirs or the organisation's. If it is treated as theirs, it can vanish with their account and take the team's shared schedule with it. If it is treated as the organisation's, it survives, but you need a deliberate rule that says so. Tying a calendar's lifecycle to its owner is one answer to that question, and the point is that there has to be an answer — the alternative is finding out by accident.

This is the same distinction we draw between a person and the workspace they work in: ending an account should never silently end the things a team depends on, and the lifecycle of shared data should be a decision you made rather than a side effect. We covered the general version of this in what happens to your data when you leave. Whatever tool you choose, ask it the plain question before you depend on it: when someone leaves, what of theirs stays.

Choosing a tool is choosing a company that has to last

SaaStr published a sobering piece on timelines today: an initial public offering can take around twelve years, and even then the money arrives later still. As they put it, founders, employees and even a lot of investors treat the IPO date as the liquidity date when most of the cash actually comes years afterward [4].

Why does this matter to a buyer rather than a seller. Because when you adopt a business tool you are not buying software, you are entering a relationship with a company that has to be around in five years to keep your data safe and your integrations working. The incentives of the people running that company are shaped by exactly these timelines. A long road to liquidity means the people building your tool are committed for the long haul, which is reassuring, and also under pressure to keep growing, which shapes pricing and roadmap. Reading a vendor's funding stage is part of reading the tool. It tells you whether the thing you are standardising on is likely to still be there, and on what terms, when you have come to rely on it.

When the shortlist is the real work

Finally, the category round-ups. Zapier published guides today to AI video generators and to free writing software, listing sixteen of the former. On video they make the honest observation that consuming video is easy and producing good video is not [5].

The lesson is not which tool won. It is that when a category has sixteen credible entries, the selection is the work, not an afterthought before it. A long list is a sign the category is young and the differences between tools are real but hard to see from a feature table. The way through is to stop comparing features and start with your own task: the one video you actually need to make, the one document you actually need to write, run it through three candidates, and keep the one that fitted. A shortlist assembled against a real job beats a ranking assembled against everyone's. If you are tracking these category shifts day by day, yesterday's daily briefing sits alongside this one.

The through-line of the day is worth stating once more. Every one of these items asks you to hand something off — a decision to an agent, a branch to an automation, a shared asset to a lifecycle rule, your continuity to a vendor, your judgement to a shortlist. Delegation is how a small business grows without hiring for everything. The boundary is what keeps it from becoming a liability. Pick tools that make the boundary explicit, and the hand-off is a gain rather than a leak.