Agents are moving into the system, not beside it

Every announcement below points at the same fork in the road: does the intelligence a business relies on live inside the system that already holds its data, or does it arrive as a separate layer bolted on top? On 16 September 2026, three vendors made the case for the former, and a publisher explained, in dollar terms, what the latter can cost you.

A reasoning model built for refund policies, not physics problems

Most large language models are trained to reason generally: solve a maths problem, debug a script, plan a trip, argue both sides of a disagreement. Salesforce's engineering team argued this week that general-purpose reasoning is not what a business actually needs from the model sitting inside its customer service or sales tools. Their explanation was direct: "A general model reasons about a refund policy the same way it reasons about a physics problem. So we trained one specifically for enterprise work." [1]

The distinction matters because a refund policy is not a physics problem. It has exceptions, escalation paths, and consequences for a real customer relationship that a generic model has no training signal for. A model that treats the two the same way will sometimes handle an obviously enterprise-specific case in a way a supervisor would never allow. Training a model on the kind of reasoning enterprise work actually demands - policy exceptions, account history, what counts as fair - is a different exercise from training one to score well on a maths benchmark.

For a business choosing between AI tools, this is a useful filter to apply directly. Ask any vendor pitching an "AI agent" what the model underneath was trained on, and whether that training reflects the kind of decision your business makes, or a generic one borrowed from a general-purpose model. The same question sits behind what AI should and should not do in your business.

When an agent works a concert venue, someone still owns the escalation

Salesforce also announced this week that Live Nation is expanding its use of Agentforce beyond an initial pilot. The scope described is specific: "Building on a successful pilot at BottleRock Napa Valley, Agentforce to bring 24/7 fan support to Live Nation concert venues across the U.S." [2]

A concert is a reasonable stress test for a customer-facing agent, because the questions arrive in a burst - parking, re-entry, a lost ticket, a change to set times - and they arrive at moments when a venue's own staff are busy running the show. Round-the-clock coverage for that kind of question is a sensible job for an agent: the questions are repetitive, mostly answerable from data the venue already holds, and low-risk if the agent occasionally has to say a person will follow up.

What is notably absent from the announcement is any claim that the agent replaces the judgement calls a promoter or venue manager makes about refunds, safety, or a genuinely upset fan. The pattern described is: automate the volume, keep a person in the loop for the exception. That is the same test worth applying before automating any repetitive task in your own operation - see how to tell whether a task should be automated.

A year of results is a better signal than a launch announcement

It is easy to be sceptical of an agentic platform on the day it launches, because a launch is a promise rather than a result. A year later is a fairer test. Salesforce marked the first anniversary of Missionforce, its government-focused platform, by pointing to growth rather than a new feature: "One year ago, Salesforce launched Missionforce, its agentic platform for government that brings trusted AI, data, apps, and cloud technology to the government’s most critical missions." [3]

Government buyers are typically slower and more risk-averse than most commercial ones, so a claim of sustained account growth in that sector over twelve months is a stronger signal than an announcement of a new capability would be. It does not tell a small business whether Missionforce would suit it - a procurement process built for federal agencies has little in common with how a ten-person company buys software - but it is a reminder to weigh a vendor's own retention and growth figures, when published, more heavily than a demo.

The bill that arrives after you shipped it yourself

Not every AI story this week was about an agent working inside a large platform. Zapier published a warning aimed at anyone building their own application with AI assistance - "vibe coding," in the current shorthand - about what can go wrong once the app is live and the public can reach it. The piece opens with the scenario at its most ordinary: "Shipping your first app feels great. Your idea is finally out there for the entire world to see. You posted the link, people signed up, everything is smooth—until you get billed $4,000 in OpenAI usage credits for API calls you didn't make." [4]

The lesson generalises beyond the specific bill. An application assembled quickly, without anyone reviewing the parts that touch money, authentication, or external APIs, can work perfectly in a demo and still expose a hole nobody thought to check. That is not a reason to avoid building quickly. It is a reason to be precise about what "shipped" means: a working demo and a system that has been checked for who can call it, and what that calling costs, are two different milestones. A business evaluating any AI-built tool, whether built in-house or bought from a vendor, should ask which of those two milestones it has actually reached - the same question raised in what AI should and should not do in your business.

Buying a writing tool separately from the system that holds your customer data

Zapier also published its review of AI text generators for 2026, framing the category with an observation about who has had to adapt fastest: "It turns out AI is better at writing code than English, so it's computer engineers and not journalists who've had to radically rethink how they work." [5]

A roundup like this is aimed at a real and common decision: which standalone tool should handle drafting - email replies, marketing copy, internal documentation. That is a legitimate purchase on its own terms. The trade-off worth naming is that a standalone generator does not know anything about the customer it is writing to unless someone pastes that context in by hand, every time. A tool that drafts a reply without seeing the account history, the last support ticket, or the outstanding invoice is drafting blind. Two systems that do not share data quietly reintroduce the copy-and-paste step that automation was meant to remove - the same failure mode covered in why your tools do not talk to each other.

The thread across all five stories

Each of today's announcements answers a version of the same question: is the intelligence working from the same record as the rest of the business, or from whatever context a person remembered to copy in by hand. 360REV's approach is to keep reasoning attached to the account record it concerns, rather than asking someone to reassemble that context each time a question comes up.