Who is writing to your systems now

The question worth holding today is not whether software can do more of the work. It is who, or what, is now writing into the systems your business trusts as true, and whether you can still see and control what ends up inside them. Two of today's items show machines creating and editing records at scale; two more show the controls being built to label and lock what those records hold. Read together, they describe a single shift: the authorship of your data is moving, and the governance around it is trying to keep pace.

Half the work items in one tracker are now made by machines

A work tracker is, at bottom, a record of intent. Every ticket, task and issue is a small claim that something should happen, written by a person who decided it mattered. That is why these systems earn trust slowly: when you read a backlog, you are reading human judgement about priority, and you weigh it accordingly.

SaaStr reported that in one widely used issue tracker, the share of work items created by agents rather than people has moved from a small fraction to around half in a single year [1]. The same report notes the company's financing context — a secondary sale that roughly doubled its valuation [2] — which matters mainly because it tells you this is not a fringe experiment but a tool many teams already depend on.

For a business choosing tools, the lesson is not to be impressed or alarmed, but to ask a plainer question. If a machine can open a ticket, who reads it, and how do you tell a human's considered request from an automatically generated one. A backlog where authorship is invisible is harder to prioritise, because you no longer know which items carry judgement behind them. Before you adopt anything that lets agents write into a shared record, insist on two things: a clear marker of who or what created each item, and the ability to review or reverse it. This is the same discipline we have written about in what a CRM is actually for — a record is only useful if you can trust where each line came from.

When the system of record changes hands

The second item takes the idea further. SaaStr's podcast on operating with agents in production described a week defined by one theme — what happens when agents take over the system of record [3]. The system of record is the copy of the truth everything else defers to: the customer list, the renewal dates, the contract terms. When a person maintains it, errors are slow and usually caught in conversation. When agents maintain it, errors are fast and silent, and they can propagate before anyone notices.

That is not an argument against letting software do the work. It is an argument for drawing a line around which decisions a machine may finalise without a person in the loop. Building an automation that drafts a renewal, flags a lapsed account or updates a field is sensible. Letting it commit a change that cannot be traced or undone is not. We have set out where that line sits in decisions automation should never make: the test is whether a wrong answer is cheap to reverse, and whether the change leaves a trail you can read afterwards.

The practical question to put to any vendor is this. When an agent edits a record, does it write who changed it, when, and what the value was before. If the answer is vague, you are being asked to trust a system of record that cannot account for its own history, and that is a worse position than a spreadsheet maintained by one careful person.

Labelling data before you can protect it

If authorship is moving, control of content has to move with it. Google announced that AI-assisted data classification in Google Drive is now in open beta [4]. Classification is the unglamorous first step of data protection: before you can decide who may see a file or where it may travel, something has to know what the file contains. A document labelled as a contract, a payroll export or a customer list can then be governed by a rule. One that is unlabelled is governed by hope.

The reason this matters for tool choice is that most data loss happens not through dramatic breaches but through ordinary drift — a sensitive file dropped in the wrong shared folder, forwarded to the wrong person, synced to the wrong device. Automatic labelling makes it possible to apply a consistent rule across thousands of files that no one has time to tag by hand. The trade-off worth naming is accuracy: a label applied by software is a guess, and a confident wrong guess can be worse than no label, because it invites misplaced trust. If you lean on automated classification, budget for spot-checking it, and keep the ability to correct a label a human disagrees with.

Encryption you hold the key to, now readable in place

The fourth item is narrower but points the same way. Google noted that client-side encrypted PDF and image files can now be previewed directly in Drive, in beta [5]. The useful concept here is client-side encryption itself. As the announcement puts it, this approach gives organisations control over access to their confidential data, with customer-controlled keys and data that is indecipherable to third parties, including the provider [5].

The long-standing cost of that control has been convenience. Files only you can decrypt are, by design, files the service cannot open for you — so you lose the small conveniences, like previewing a document without downloading and decrypting it first. Making encrypted files viewable in place chips away at that friction, which matters because friction is why security controls get switched off. A protection people route around is not a protection.

The point for a business is to understand what you are actually buying when a tool offers encryption. Ask who holds the keys. If the provider holds them, they can read your data and, under the right legal order, must. If you hold them, the responsibility and the control are both yours. Neither is wrong, but they are different promises, and you should know which one you are making to your own customers. This is part of what we meant by keeping customer data current — custody of data is a standing obligation, not a one-time setting.

A smaller change that respects attention

Not everything today is about machines and keys. Google is also introducing a per-event setting in Calendar that lets meeting organisers or their delegates decide whether to receive RSVP emails and automatic responses, such as out-of-office and vacation replies [6]. It is a small feature, and worth noting precisely because it is small: it removes a category of low-value notification that most people have simply learned to ignore.

The habit to carry from it is to treat attention as a budget. Every automatic email a system sends is a withdrawal from someone's focus, and the ones that teach people to stop reading are the most expensive, because they train a reflex to dismiss. When you evaluate a tool, look at what it sends by default and whether you can turn the noise down without turning the signal off. A product that lets you suppress the responses nobody reads, while keeping the ones that matter, is respecting the scarcest resource your team has.

The thread, pulled together

Four of today's items are really one story told from both ends. Machines are increasingly the authors of your records, and the controls to classify, encrypt and quieten those records are arriving to match. The right response is not to resist either half but to insist they meet in the middle. Let software create and edit, but demand that every change names its author and can be undone. Let content be labelled and locked, but remember a label is a guess and a key is a responsibility. The businesses that choose well will not be the ones with the most automation or the strictest controls, but the ones that can still answer a simple question about any record they hold: who wrote this, and can I trust it. In 360REV we treat that question as the design brief — every change to a record carries who made it and when, so the history stays readable whether a person or an automation wrote the line.