Agents build more, and the rules that keep them in line

Most of what the big software makers put out today circled one question: how much of the work should an automated agent do on its own, and what keeps it inside safe limits. The announcements came from different corners of the industry — version control, customer platforms, project tools, video — but they read like parallel answers to the same problem. For a business choosing tools this year, the useful skill is not picking the loudest launch. It is reading each one for the trade-off it quietly accepts, because that trade-off is what you will live with after the demo ends.

Putting down the pencils

For most of the history of software, building it meant a person typing each line. The idea now being argued in public is different: a person describes what is wanted, an agent produces the code, and the person reviews and corrects it. The work shifts from writing to directing and checking.

David Heinemeier Hansson, who created the Ruby on Rails framework that Basecamp is built on, stated the position plainly. He wrote that "We're not going to write the vast majority of code by hand any longer." [1] That is a strong claim from someone whose career is bound up in the craft of writing code by hand, which is why it is worth a business owner's attention even if you never touch a line yourself.

The reason it matters to you is indirect but real. The tools you buy are made by teams who are deciding, right now, how much of their own product to let an agent write. That decision changes how fast features arrive and how they are reviewed. A faster release pace is good when each change is checked, and a problem when it is not. The lesson for a buyer is the same as it has always been: ask how a vendor verifies what ships, not how quickly it ships. If you are weighing where automation belongs in your own operation, we have written separately about what AI should and should not do in your business.

Rebuilding the plumbing while the shop stays open

When the volume of changes to a system rises sharply, the machinery underneath it starts to strain. That machinery is usually invisible until it breaks. Today GitHub described rebuilding the foundation that stores and tracks code changes, and it framed the reason in exactly those terms.

The company wrote: "We're rebuilding GitHub's Git infrastructure while GitHub keeps running, creating a foundation for agent-scale software development." [2] Two parts of that sentence are worth separating. The first is "while GitHub keeps running" — changing a foundation without taking the building down is the hard part, and the part most likely to go wrong. The second is "agent-scale," which tells you the workload they are preparing for: not a team of people making changes at human speed, but software making changes at machine speed.

You do not need to use GitHub to take the point. The systems your tools depend on are being re-plumbed to carry a much larger number of automatically generated changes. More changes arriving faster is the direction of travel. That raises the ordinary risk that a connection between two systems quietly stops working, which is a problem we have written about in why integrations break quietly.

Autonomy with guardrails

An agent that only suggests is safe and limited. An agent that takes action on its own is useful and risky. The interesting design work is in the middle, and today Salesforce published its account of how to sit there.

The framing pairs two kinds of logic. A probabilistic model is the language model that guesses the most likely next step; it is flexible but not guaranteed to behave the same way twice. Deterministic logic is a fixed rule that always does the same thing. The argument is that you let the flexible part propose and the fixed part enforce the limits. In the company's words, "Salesforce Principal Architect of Ethical AI Practice Kathy Baxter explains how pairing a probabilistic model with deterministic logic gives agents the ability to take action — without giving up the guardrails." [3]

This is the right mental model for any buyer evaluating an agent that will touch real records or spend real money. Ask where the deterministic rules sit. A rule that always refuses to send money without approval does not depend on the model being in a good mood. The guardrail is the part you can test, repeat and audit. 360REV takes the same split: the model drafts, and fixed rules decide what is allowed to happen.

A message to employees, and why a customer reads it

The companies behind your tools reorganise themselves. Most of the time a customer never notices, and most of the time that is fine. But a note from a chief executive about company changes is worth a moment of a customer's attention, because the continuity of a platform depends on the health and direction of the company that runs it.

HubSpot published the full internal message today. The company wrote: "Below is the full message sent to all HubSpot employees today from our CEO, Yamini Rangan." [4] We will not guess at what the changes contain beyond what was said, and neither should you. The useful response to any vendor announcement of this kind is not alarm. It is a quiet check of your own position: do you know how to get your data out, and do you know what you keep if you ever leave. We wrote about that question in what happens to your data when you leave, and it is a good habit to confirm the answer before you need it rather than after.

Capturing a task where it starts

Work is born in conversations. Someone mentions a job in an email or a chat message, and in that moment the task exists only as a sentence in a thread. The friction is the switch: opening a separate tool to record it. Tasks that require a switch are the ones that get lost.

Trello for Google Workspace is aimed squarely at that gap. The announcement says it "makes it easy to capture tasks and ideas from the conversations where they begin." [5] The phrase "where they begin" is the whole point. Recording a task in the place it arises, rather than later from memory, is the difference between a system that reflects reality and one that drifts from it.

This is a small, specific version of a larger principle: your tools should let work live next to the conversation that created it, not in a separate silo you have to remember to update. We have argued the general case in why your tools do not talk to each other and the particular case in why quotes and invoices belong next to the conversation.

The thread, pulled together

Read in one sitting, the day has a shape. The makers of your tools are letting agents do more of the building, re-plumbing the foundations to carry that load, and arguing about where the fixed rules go that keep an agent from overstepping. None of that removes the buyer's job. It sharpens it. The question to carry into any purchase is the one that runs under all of today's news: when this tool acts on its own, what is the rule that stops it, and can you see that rule. For yesterday's edition and the running thread, see our daily briefing for 5 October.