Who you let act on your behalf, and who acts on theirs

The announcements that landed today share one thread: software is increasingly asked to act, not just to store. A customer's agent arrives to transact for them, an automation branches and looks things up on its own, a generator produces a finished video from a brief. Underneath that sits a quieter question about governance and permanence — who owns what the automation touches, and whether the vendor behind it will still be standing in a decade. A business choosing tools this week is really choosing what it is willing to delegate, and to whom.

When a customer sends an agent instead of a person

The most consequential item of the day is Salesforce's argument that customers will soon show up at your business represented by their own software. A personal AI agent is a program acting on an individual's behalf — comparing options, filling in details, placing an order — without the person doing each step themselves. Salesforce frames the choice bluntly: "With the advent of personal AI agents, every business is grappling with the same question: Let them in or block them at the front door?" [1]

The reason this matters for tool selection is practical, not philosophical. An agent cannot read your marketing copy the way a human skims a page. It needs structured facts: a price it can parse, stock it can check, a booking slot it can claim, an endpoint it can call. A business whose product information lives only in prose, or whose only route to purchase is a form built for human eyes, is effectively closed to an agent even if it never decides to block one. The decision to "let them in" is less a policy toggle than a measure of how machine-legible your systems already are.

There is a second, less obvious consequence. When an agent transacts, the identity on the other side is layered — a person, and the software they authorised. Your records need to capture both, or you lose the ability to tell who actually asked for what. This is the same discipline that makes any customer record useful, which we have written about in what a customer record should contain. Agents do not change the principle. They raise the cost of getting it wrong, because a sloppy record is now read by something that will act on it immediately.

New logic and search steps for automation

Google added capability to its automation builder today. The company announced that it is "introducing several new feature enhancements to Google Workspace Studio as part of the October 2026 feature release" [2], with the additions described as new logic and search steps spanning Gmail, Meet and Drive.

It is worth separating the two ideas, because they do different work. A logic step is a branch: the automation looks at a condition and takes one path or another, rather than running the same sequence every time. A search step is a lookup: the automation finds a record or a file and uses what it finds in a later step. Together they move an automation from a fixed script toward something that responds to the situation in front of it.

The benefit is obvious — fewer flows that only handle the happy path. The trade-off is that branching automation is harder to reason about after the fact. A straight-line rule does the same thing every time, so you can predict it. A rule with branches does different things depending on data you may not be watching, which makes it both more useful and more capable of surprising you. The guardrail is not to avoid logic steps; it is to be deliberate about which decisions you hand over. We set out where that line should sit in decisions automation should never make. The short version: let automation carry out a decision, but keep the judgement that a mistake would be expensive to reverse.

Video generation moves into the everyday toolbox

Zapier published a roundup of what it calls the sixteen best AI video generators of the year. Its framing captures why these tools get attention: "Consuming video is easy. Producing good video is not." [3]

The cost of video has always been time — scripting, shooting, editing — and generators attack that cost directly by producing footage from a text brief. For a small team, the appeal is that a channel which was previously out of reach becomes something one person can attempt in an afternoon. That is a real shift in what a lean business can publish.

The trade-off is the same one that follows every tool which lowers a production cost. When something becomes cheap to make, more of it gets made, and the scarce resource moves from production to judgement — knowing what is worth saying, and whether a generated clip actually represents your business. A roundup of sixteen options is itself a signal: the category is crowded, and choosing within it is now a selection problem rather than a build problem. The questions that matter are the dull ones. Where does the footage end up, can you export it, and does the output meet a standard you would put your name on. We walk through that kind of evaluation in choose software worth using.

Calendars that end when their owner does

Among the smaller items in Google's weekly recap is a change that touches data governance more than it touches features. Google stated that "secondary calendars will now follow the lifecycle of their owner" [4], rolling the change out to non-personal Workspace accounts.

This sounds like housekeeping, and in a sense it is, but the principle is one every business should hold. A secondary calendar — a room booking, a project schedule, a shared resource — used to be able to outlive the account that created it. When an owner left, the calendar could linger, unowned and unmaintained, a small piece of orphaned data that nobody is responsible for. Tying it to the owner's lifecycle means that when the account ends, the thing it created ends with it in a defined way.

The broader lesson for a buyer is to ask, of any tool, what happens to the things a departing person created. Orphaned records, shared folders with no owner, and automations running under a deactivated account are how systems quietly rot. A clear lifecycle rule is unglamorous, and it is exactly the sort of detail that separates a tool you can run for years from one you spend those years cleaning up after.

The vendor you build on has a long clock

The day's investment note, from SaaStr, is not about a feature at all, but it belongs in a tool-choosing briefing because it is about the companies behind the tools. SaaStr argues that "it's the best outcome for almost everyone on the cap table" when a company reaches an IPO [5] — while also pointing out how long that road is, measured in more than a decade before most of the money arrives.

For a buyer, the relevance is durability. When you adopt a tool, you are placing a bet that its maker will still be funded, staffed and shipping years from now, because migrating off it later is costly. Understanding that software vendors operate on a long horizon — that liquidity for their backers comes slowly, if at all — is part of reading whether a company is built to last or built to be sold quickly. Neither is wrong, but they imply different risks for the customer who depends on the product. The tools you commit to should be the ones you expect to still be running when the current founders have moved on.

The common question

Five different announcements, one recurring decision. Each is about delegation: to a customer's agent, to a branching rule, to a generator, to a lifecycle policy, to a vendor's long-term plan. Delegation is leverage when the thing you hand over is well understood, and a liability when it is not. The tools worth adopting are the ones that make the hand-over legible — clear about what they will do, what they touch, and what happens when the person who set them up is gone.