All year I have argued that AI agents need more context. They need to know your customers, your history, your products, your conversations and the decisions that came before them. Otherwise they are just very smart strangers.

I still believe that.

But Meta gave me a reason to add something to the argument. Every piece of context we give an agent also gives it reach. And we are getting very good at adding reach without being nearly as good at understanding the sum of it.

That is becoming an agent problem for everybody, not just the people building them.

I saw a version of this in the 2000s when I worked at TIBCO. Enterprises had hundreds of applications connected directly to one another. Every new connection made sense when it was added.

Eventually they had created a web that nobody could easily draw, change or secure.

The solution was to stop treating every connection as its own little decision and create a shared layer through which data could flow. You could see what went where and shut something off without having to untangle everything around it.

Most GTM teams are rebuilding that web with agents. Each new agent gets its own connections to the CRM, the inbox, the calendar and the call recordings, usually set up by the operations lead with their own login. So the agent acts as that person, with that person's reach. Twenty agents connected separately to five systems is a hundred connections, each borrowing someone's access, and no single list of what any of them can read or change.

Nobody sat down one morning and decided to create one giant permission system. It emerged one useful connection at a time. That is exactly why it becomes hard to govern.

We are rebuilding the same point-to-point architecture with agents. Except there is an important difference. These connections do not just move information anymore.

The software on the other end can read it, reason across it and increasingly take action. That changes the stakes.

I don't think the answer is giving agents less context. That makes them safer by making them less useful.

The answer is making their context visible and governable.

And if something goes wrong, you should be able to remove one permission or shut down one agent without hunting through someone's personal accounts or breaking everything around it.

When agents draw from a governed layer, those things become much easier: the systems they read and write to can be visible in one place, actions can pass through approval gates, activity can be logged, and access can be revoked independently.

The architecture can vary. But the principle should not.

More agent context has to come with more visibility and control.

Before giving another agent access to anything, I would do one exercise. Make a list of the agents you already use. Include the obvious ones, but also the AI features that arrived inside software you already pay for.

Then answer five questions for each one:

1. What can it read?

Which systems, files, conversations and records can it access?

2. What can it change, send or delete?

Reading a calendar and moving a meeting are very different permissions.

3. What requires human approval?

Not "is there technically an approval setting?" Who actually has to approve the action before it happens?

4. Can you see a history of what it did?

If something goes wrong next month, can you reconstruct what happened?

5. Can you revoke its access without breaking everything around it?

Could you switch the agent off tomorrow without touching someone's personal account?

These are close to the five columns I would want on one page for every agent in a company. Most teams will find this exercise harder than expected.

But it is a useful information. Because the dangerous permission is often a collection of individually reasonable permissions that nobody has ever looked at together.

A map of agent access is not a security review. It will not tell you whether an agent can be manipulated by something it reads.

It will not tell you how long a vendor retains your data, where that data is processed or whether the context itself is accurate. Those belong to your security and legal teams.

But before you can govern any of them, you need to know what the agent can reach in the first place. That depends on the quality of the context they draw on, which is the argument I will keep making.

Meta's Muse is an unusually visible example of the gap between perceived access and actual access.

Inside most companies, that gap will be much less obvious. It will grow one inbox, one CRM connection, one calendar, one repository and one agent at a time.

P.S. We built RevSure AI as that shared layer for go-to-market: your GTM tools resolve into one context layer, and every action our agents take runs under what we call Safe Autonomy, proposed with its reasoning, approved through gates you set, logged, and reversible with one click.