The day's SaaS news was all about the plumbing around AI agents

Nearly everything the productivity publishers put out today circled the same subject from different sides: what has to be true around an AI agent before you let it touch real work. None of the notable items were about smarter agents. They were about recovery when an agent gets it wrong, evaluation while it runs, the context it can see, and the quality of the data it reads.

That is a useful signal for anyone choosing tools right now. The first wave of agent marketing sold autonomy. The questions that actually decide whether an agent is safe to deploy are duller and more important, and today several vendors answered them in public.

Assume an agent will eventually delete something you need

An AI agent is software that takes actions on your behalf. Some of those actions are destructive: overwriting a record, emptying a field, removing a row. A human doing the same job hesitates before deleting, because a human understands what the data is for. An agent does not hesitate in the same way. That means the safety you rely on cannot live inside the agent. It has to live outside it, in the form of a copy you can restore from.

SaaStr reported today that it runs with three humans and more than twenty AI agents in production, and that in recent weeks two different agents each destroyed something the business cannot operate without [1]. The point of the piece is not that agents are dangerous. It is that the recovery path mattered more than the agent did, and the copy that saved them was not one anyone had planned.

The lesson for a business choosing tools is to treat agent access the way you treat any other write access. Before you connect an agent to a system of record, confirm two things: that there is a backup the agent itself cannot reach, and that you have actually restored from it once. This is the same discipline we have written about in decisions automation should never make — the difference now is that the actor making the mistake is autonomous and fast.

Evaluate agents while they run, not once before launch

Traditional software is tested before release and then behaves predictably. An agent does not. Its behaviour depends on the inputs it sees each day, the cost of each call, and the model behind it, all of which change. A test that passed last month tells you little about what the agent is doing right now.

Salesforce addressed this directly today with an expansion of its Agent Fabric. Its new Agent Evals, the company says, gives leaders the confidence to scale more agents into production by continuously evaluating agent performance and costs, no matter what platform the agent is built on [2]. Two words in that sentence are worth underlining for a buyer. One is continuously: evaluation is ongoing, not a launch gate. The other is the platform-independent framing, which acknowledges that most companies will end up running agents built in several different places.

The trade-off to weigh is where this monitoring layer sits. A tool that watches agents across platforms is useful precisely because it is not tied to one of them, but it also becomes a new dependency that needs its own oversight. When you shop for this kind of control plane, ask what happens to your agents if the evaluation layer is unavailable, and whether cost ceilings are enforced or merely reported.

Insights that never leave the tool they were created in

There is a quieter failure mode than an agent deleting data, and it costs businesses more often. An agent produces a genuinely useful insight, and then nobody else sees it, because it stays inside the one interface where it was generated.

Salesforce published research today on exactly this. As more and more businesses rely on AI, it argues, workers are experiencing a bottleneck: interface isolation [3]. The framing it uses is single-player versus multiplayer AI. A single-player tool helps the individual in front of it and stops there. A multiplayer one assumes the output has to reach other people and other systems to be worth anything.

For a buyer, this reframes a question you are probably already asking. It is not only "is this agent good at its task." It is "what does this tool do with the answer once it has one." An insight that cannot be routed, shared, or written back to a shared record is a private note, however clever it is. We have made a version of this argument before in what AI should and should not do in your business: the value is in what reaches the rest of the team, not in the clever output itself.

Giving an agent your context without losing control of it

For an agent to be useful it needs to see your material — your projects, documents, and prior decisions. The risk is that connecting that material to a general assistant scatters copies of it into places you no longer govern.

Dropbox's announcement today is about threading this needle. The product brings trusted Dropbox project context into Microsoft Copilot to find information, create across Microsoft 365 applications, and keep work connected and governed in Dropbox [4]. The phrase that matters for a buyer is "governed in Dropbox." The context travels to where the work is being done, but the governance stays with the source. That is the pattern to look for whenever you connect a store of documents to an assistant that lives somewhere else: the answer should move, the control should not.

The trade-off is that you are now trusting two systems to agree about permissions. When you evaluate this kind of bridge, check what a user who loses access on one side can still see on the other, and how quickly a revocation propagates.

The data an agent reads decays before it reads it

Every point above assumes the agent is working from good data. Often it is not, and the decay is not a single failure but a series of small ones across a pipeline. SaaStr covered a company, Sumble, whose entire pitch is this problem: why data that starts 80% accurate turns into 33% accurate by the time an agent uses it, and how one customer, Nooks, found 700 accounts it did not know about [5].

You do not need to accept those exact figures to take the point. Accuracy compounds downward. If each handoff in your pipeline is slightly lossy, the agent at the end is acting on something much worse than the source. For a business choosing tools, this argues for two habits: measure data quality at the point the agent reads it rather than at the point it was entered, and treat any agent's output as only as trustworthy as its least reliable input.

Taken together, today's items describe the real work of adopting agents. The agent is the easy part to buy. Recovery, evaluation, shared context, and clean data are the parts that decide whether it helps or hurts. For more in this series, see yesterday's SaaS Daily Briefing.