When agents act, the data and the human both matter

AI agents keep changing what we ask of the tools underneath them: the data they read, the time they waste finding context, and the decisions we still want a person to approve. Wednesday's announcements circle one question — when software starts acting on its own, where does its information come from, and where does a human stay in the loop.

That question is not abstract for a business choosing tools. It decides whether an agent can be trusted with a record, whether your data architecture can keep up, and whether the people doing the work spend their day on the work or on the search for context around it. Here are the items from the day that bear on that choice, in order of how much they should weigh on it.

The hours lost before the work begins

The most useful number of the day is a measurement of waste. Dropbox's 2026 trends report finds that "People average 15.8 hours per week with AI, with 36.6% of that time lost gathering context." [1] Read that twice. More than a third of the time people spend working alongside AI goes not to the task but to assembling the material the task needs — finding the right file, the last email, the version that matters, the decision someone made three weeks ago.

This is the quiet tax of scattered information, and it does not go away when you add an AI assistant. It arguably gets worse, because an assistant that cannot see your context asks you to supply it, and supplying it is the 36.6%. The lesson for a business is not "buy more AI". It is that the value of any assistant is capped by how much of your working context it can reach without a human fetching it first. A tool that already holds the customer record, the conversation and the history gives an assistant something to stand on. A tool that holds a fragment makes the human the integration layer. We built 360REV so that one record carries the conversation, the history and the documents together, which is the same reason we keep writing about what a customer record should contain.

One database for two jobs

Underneath that context problem sits an older architectural split. As TechCrunch reports, "Databases have traditionally been designed either for analytical data or for operational data." [2] Operational systems handle the live transactions — an order placed, a record updated. Analytical systems handle the questions you ask afterwards — how many orders, which segment, what trend. For decades these were separate stores, with data copied from one to the other on a schedule, which is why a report is often a day behind the thing it describes.

CedarDB's pitch is that a single engine can serve both, and the reason this is newly interesting is agents. An AI agent that researches, decides and acts needs to read the current state and reason over the history in the same breath; a day-old copy is not good enough when the agent is about to do something. You do not need to adopt a new database to take the point. When you evaluate a tool, it is worth asking whether the numbers it shows you are live or a stale copy, because an agent acting on the stale copy will act on yesterday. The split between what happened and what you can ask about it is the same split that makes your tools not talk to each other.

Keeping a person in the loop

The counterweight to all this autonomy is deliberate human review, and Zapier's primer on human-in-the-loop names the stakes plainly. "AI systems can route messages, update records, make decisions, and trigger entire workflows across multiple apps without you touching anything." [3] That sentence is a promise and a warning at once. The same reach that makes an agent useful makes an unreviewed agent dangerous, because the blast radius of a wrong decision is now every connected app.

Human-in-the-loop is the practice of inserting a checkpoint where a person confirms before the system commits to something that is hard to undo. The skill is choosing where. A checkpoint on every action turns the agent back into a form you fill in by hand; no checkpoints at all means the first time you learn of a mistake is when a customer tells you. The judgement is the same one we keep returning to in what AI should and should not do in your business: automate the retrieval and the drafting, keep a person on the step that sends, charges or deletes.

When the agent does the prospecting

Floqer is a concrete instance of an agent pointed at one job. TechCrunch frames it this way: "The problem Floqer is trying to solve is familiar to anyone who has worked in sales or revenue operations." [4] The familiar problem is research — before a sales conversation, someone has to learn who the prospect is, what they do, and what might move them, and that work is slow and easy to skip under pressure.

Pointing an agent at that research is a sensible use of the technology, because it is retrieval and summarisation rather than a decision that commits the business. It also returns us to the Dropbox number: if a third of AI time is lost gathering context, an agent whose entire purpose is gathering context is attacking the right target. The trade-off to watch is accuracy. Research an agent produces still needs a person to sanity-check before it shapes a pitch, which is the same test as deciding how to tell whether a task should be automated — automate the gathering, verify before you act on it.

Counting without naming names

The day's quietest item is about restraint, and it is a useful model. GitHub rebuilt its repository star-history feature so that, in its words, "Our new repo star history API now provides trends without returning individual identities or requiring unbounded database work." [5] The old approach returned the trend by handing back the full list of individuals behind it; the new one returns the trend alone.

There are two lessons here for a business choosing tools. The first is privacy by design: you can usually answer the question people actually ask — what is the trend — without exposing who is in the data. The second is cost: the old method did work that grew without limit as a repository grew, and the rebuild caps it. Both matter when you pick a vendor, because a tool that cannot show you a trend without dumping personal records, or that slows down as your data grows, has made a design choice you will live with. Asking to see the aggregate without the identities is a fair question to put to any analytics tool.

What to carry into the day

The thread holds: agents raise the value of good data and raise the price of unreviewed decisions at the same time. The practical posture is to feed your tools enough context that an assistant is not waiting on a human to fetch it, to prefer systems where the live state and the history are one thing rather than a copy that lags, and to keep a person on the steps that are hard to reverse. Yesterday's daily briefing made a related point about the plumbing between systems; today's news is what happens when you put an agent on top of that plumbing. The tools that will serve you are the ones that give the agent something true to read and give you a place to say yes before it acts.