The day the software agent got a name badge

Today the software agent stopped being a demonstration and started behaving like a colleague. The announcements worth your attention share one thread: an AI that acts on your behalf now needs an identity, a choice of which model does the work, and a clear boundary around what it is allowed to touch.

An agent that gets its own workplace identity

For most of the past two years, "AI in your business tools" meant a chatbot. You asked a question, it answered, and nothing happened unless you acted on the answer yourself. That is changing. Google said it is turning Gemini into an agent that can plan a task and carry it out across the systems a business already uses [1]. The notable detail is not the planning. It is that the agent can delegate work to smaller agents, draw on more than one underlying model, and is given its own workplace identity.

An identity changes the nature of the thing. A chatbot is a feature. An actor with its own identity is closer to a member of staff, and you have to treat it like one. That means asking the same questions you would ask of any new hire. What can it see. What is it allowed to change. Where is the record of what it did. These are not new questions. They are the questions that every growing team eventually has to answer about its people, which is why they are worth settling before you point an agent at live data rather than after. We have written before about why permissions matter as a team grows and about the audit trail nobody thinks about; an agent with an identity makes both of those concrete rather than theoretical.

The practical test is simple. If a person left your company tomorrow, you would disable their account and know, from the logs, what they had access to. An agent deserves the same. An identity you can grant, scope, and revoke is the difference between a tool you control and a process you merely hope is behaving.

Skills you can send to anyone, and the question of who added them

Slack made its Slackbot skills shareable [2]. You create a link, send it to someone, and they can browse and add agent capabilities that other teams have built. The appeal is obvious. Instead of every team rebuilding the same helper, one team builds it well and the rest adopt it.

The trade-off sits in the word "add". The easier it is to add a capability, the easier it is to add one that nobody reviewed. This is the same lesson that integrations taught a decade ago. A connector that any employee can enable in two clicks is convenient until you are trying to work out, months later, which of forty connected tools is reading your customer list. Sharing is a feature. Knowing who added what, and being able to remove it cleanly, is the governance that has to sit underneath the feature. If you adopt shared skills, keep a record of which ones are live and who switched them on.

Choosing which model does the work

The third piece of the day is less dramatic and arguably more useful day to day. Zapier published a guide to which AI models you can wire into an automation, covering several providers [3]. The honest framing in that piece is that the pace is relentless. As the author puts it, staying current is "like trying to keep my house vacuumed in the height of my dog's shedding season (a losing battle)" [3].

That is the right thing to notice. New models arrive constantly, and the one that was the obvious choice in spring may not be the obvious choice now. The lesson for a business is not to chase every release. It is to build your automations so that the model is a setting, not a foundation. A good step cares about the input it receives and the output it returns. Which model produces that output should be something you can change without rebuilding the step around it. The task decides first; the model is chosen to fit the task. We have written about how to tell whether a task should be automated, and the same discipline applies here: define the job clearly, and the choice of model becomes a detail you can revisit rather than a commitment you are stuck with.

Buying the tools a company built for itself

Spotify said it is taking its enterprise software ambitions more seriously, launching a site to make its internal technology available to outside buyers [4]. In the company's own words, it "launched technology.spotify.com, a new site that will make its internal tech available to outsiders" [4].

This is a pattern worth recognising because it keeps recurring. A company builds something for its own needs, finds it works, and decides to sell it. For a buyer, that history cuts both ways. Tools forged inside a demanding business are often shaped by real use rather than a sales plan. They are also shaped by that one business's assumptions, which may not be yours. The question to ask of any such product is the one we raised in the real cost of "we'll build it later": is this solving a problem you actually have, or a problem the seller had. Internal pedigree is a reason to look closely. It is not, by itself, a reason to buy.

Seeing a stack of changes at a glance

For teams that write software, Linear added stacked pull requests to its Diffs view. You can "move through a stack and see review, CI, and merge status at a glance" [5]. Related changes are grouped into a single collapsible row alongside the issue and project they belong to.

The value here is quieter than an agent that acts on your behalf, but it is the same instinct applied to work rather than to AI: put the status where the decision is made. A reviewer who can see, in one place, what has passed its checks and what is still waiting does not have to go hunting across tools to find out whether a change is safe to approve. That is the whole of it. Context assembled in one view is worth more than the same facts scattered across three.

The thread, pulled tight

Read together, the day points one way. Software is being asked to do more on its own, and the burden shifts from writing instructions to deciding what the software is permitted to do and with which engine. That is why identity, permissions, and a clean record matter more now than they did when the AI only ever talked back. We take the same view in how we build 360REV: an action an agent or a teammate takes should sit next to the record of who took it and what they were allowed to touch. If you only change one habit this week, make it the habit of asking, before you grant any tool the power to act, what you would do to take that power back. For the previous day's items, see the briefing for 7 October.