Weekly AI Tools That Matter to Me: Part 2, Week 31

The Week a Frontier Model Mattered Less Than an Admin Key

Anthropic released Claude Opus 5 on the twenty-fourth, described as a step change for its tier and positioned around long-running agents, with extended thinking always on. A year ago that would have been the whole edition.

This week it was not even the most useful thing to write about, and the reason is visible in how the frontier labs now talk about their own models. Opus 5 is sold on endurance. GPT-5.6, which shipped earlier this month, was sold on price-performance, and OpenAI spent the back half of July publishing follow-up material about how it gets more work out of every token rather than about what it can newly do.

Endurance and unit economics. Not ceiling.

That is what the language of a maturing component looks like. When a model answers a chat turn, its peak capability is what you notice. When it runs an agent for four hours across forty tool calls, what you notice is whether it is still coherent at the end and what the run cost. Both companies are describing their models the way you describe a part in a larger system, which is a good indication that the interesting engineering has moved somewhere else.

It moved to the settings pane, and that is where this week actually happened.

TL;DR

The week’s frontier release was described as a component, not a ceiling. Opus 5 was positioned around long-running agents and endurance, and GPT-5.6, which shipped earlier this month, is sold on price-performance. When a model runs an agent for four hours across forty tool calls, what you notice is whether it is still coherent at the end and what the run cost, which is how you describe a part in a larger system.
The most consequential release of the week was a configuration key. Anthropic’s mcpPersistentAlwaysAllowEnabled lets an administrator disable persistent “Always allow” approvals for MCP tools while keeping session-scoped ones. That converts an organisation’s accumulated permission sediment back into something with a lifespan.
Four vendors shipped four layers of the same missing register. An admin key controlling how long a permission survives, a review gate before an agent becomes discoverable, a console listing what is running, and an Enterprise MCP Registry sold as a governance product. All four assume organisations deployed agents without keeping a register and now need to reconstruct one.
The client side and the platform side independently converged on time-limiting authorisation. Anthropic made persistent approvals switchable off; Optimove made the MCP session expire after a day by default. Neither was coordinating with the other, which is what turns a product decision into an emerging norm, and which makes unattended automation more fragile at exactly the same time.

The most consequential release was a configuration key

In the same release that added the effort selector for Opus 5, Anthropic shipped a managed configuration key called mcpPersistentAlwaysAllowEnabled. It lets an administrator disable the persistent “Always allow” approvals for MCP tools while keeping session-scoped approvals available.

That is an unglamorous sentence describing a real problem.

Think about what “Always allow” means in practice rather than in principle. Somebody is in the middle of a task. A permission prompt appears. They are thinking about the work, not about the prompt, and they choose the option that stops the interruptions from happening again. That grant then persists. Not for the task. Not for the day. Indefinitely.

Multiply by every person in an organisation and every tool they have ever connected, and the actual permission state of your agent estate is not a policy anybody wrote. It is sediment: the accumulated residue of a few hundred people trying to get on with their day. Nobody decided it, nobody can describe it, and nobody is reviewing it.

Being able to say that approvals expire with the session converts that sediment back into something with a lifespan. It is the difference between a permission model and an archaeological record.

Google and Microsoft moved in the same direction in the same week. Google shipped Transparent thinking to general availability in Gemini Enterprise, where the assistant shares its reasoning and planning in the interface before calling tools or data sources, with an expandable section showing the tool activity between the thinking and the answer. Google frames this as a latency improvement, and the time-to-first-token argument is real, but the substance is observability: a user can now see which tools and which data sources were actually reached, and in what order. Microsoft put agents built in Agent Builder behind an administrative review before they can be published to the Agent Store, so there is now an explicit gate between building an agent and making it discoverable to colleagues. Even Google’s Antigravity release, mostly a routine one, added MCP timeouts, which is the protocol being hardened operationally rather than extended.

None of that is exciting. All of it is the enterprise control plane being assembled in public, one boring key at a time.

The same week, on the other beat

I keep a separate weekly log on the marketing technology side, and the two collided this week in a way that is worth putting on the record here.

Braze shipped a remote MCP server, and its list of supported clients reads like the roster of this series: Claude, ChatGPT, Cursor, VS Code, Codex, Google Antigravity, Claude Code. Showpad shipped one five days later. Both led their announcements with the boundary rather than the reach. Braze’s states that no user-profile PII is exposed. Showpad’s states that everything runs under the governance rules already protecting the platform.

So in a single week the platform side shipped MCP servers whose selling point was their scope, and the client side shipped controls over how long a tool approval survives and who is allowed to publish an agent. Both halves of the same conversation, held by different companies who were not coordinating.

That is the tell that a technology is being adopted seriously rather than experimented with. Nobody writes an admin key for a demo.

The register nobody kept

There is a fourth data point, and it comes from a CRM vendor rather than a model lab, which is what makes it useful.

HubSpot launched Agent Hub in public beta this week. Agent Builder, the companion, is the predictable half: a no-code canvas for assembling agents from CRM context. Agent Hub is a console showing live status for every active agent in the organisation, with one-click activation for dormant ones.

Its selling point is knowing which of your agents are currently running.

HubSpot’s stated problem is a prospecting agent contacting a customer during the same week a service agent is handling that account’s open complaint, neither aware of the other. Nobody writes that example unless a customer has already lived it.

So in one week: an admin key controlling how long a tool permission survives, a review gate before an agent becomes discoverable, a console listing what is running, and an independent vendor selling an Enterprise MCP Registry next to a Gateway and a Proxy as a governance product.

Four vendors, four layers, one shared assumption: that organisations have deployed agents without keeping a register, and now need to reconstruct one.

That is exactly how shadow IT went. Departments adopted SaaS faster than anyone could inventory it, and the correction took years and arrived as a procurement function rather than a product. Agents are moving faster because the adoption unit is smaller. A SaaS tool needs a purchase order. An agent needs somebody to click “always allow.”

If you are responsible for this in an organisation, the question to ask this quarter is not which agent platform to standardise on. It is simpler and more uncomfortable: can anyone produce a list of the agents currently running against your systems, and who authorised each one? If the answer takes more than a day to assemble, the tooling shipped this month exists because you are not alone.

Constraint as a feature, in two release notes

Two smaller items from the marketing side are worth borrowing, because they show what agent governance looks like when it is written at the feature level rather than the policy level.

Bloomreach’s campaign-building agent can now insert discount codes into the emails it generates, including unique per-customer codes drawn from a pool. The accompanying line in the documentation says the agent only uses voucher pools and attributes that already exist in the project, and if none is configured it says so rather than inventing a code. A generative system handling commercial offers, with an explicit statement of what it is not permitted to fabricate, printed next to the feature.

Iterable, separately, added footnotes to its agent’s responses showing where each answer was sourced, so a user can verify it against the documentation. That is the same instinct as Google’s Transparent thinking: not “trust the output”, but “here is where it came from, check it.”

Neither is a governance framework. Both are one sentence in a release note. I would take a dozen of those over another responsible-AI whitepaper.

The CDP started recording the conversation with the model

One item from the other beat deserves to be here in full, because it is where these two subjects stop being separate.

Tealium, a customer data platform, added an Anthropic data source this month. Its own description: use it with the Tealium Anthropic connector to send prompts and AI model responses through Tealium. There is an OpenAI Measurement Pixel and an OpenAI Events connector alongside it.

The CDP has started collecting what the customer said to the model, and what the model said back, as event data.

For this series that closes a loop. We spend most of these editions on how agents reach into systems, what they are permitted to touch, and who approved it. This is the reverse direction: the conversation itself becoming a record that flows into a profile, then into a segment, then into an activation.

And prompts are not page views. They are unstructured, and they routinely contain what a customer would never put in a form: a health worry, a financial situation, the actual reason behind a purchase. Once that is in the profile store it is subject to every downstream process the profile store feeds.

The instrumentation is coming either way, because the signal is too valuable to ignore and pretending the interaction did not happen is not a governance position. But the schema and the retention policy for model conversations are not an afterthought to be handled by whoever owns the CDP. They are the design decision, and they should be made by the same people arguing about MCP scopes, because it is the same argument seen from the other end.

The write-scope spectrum, in one week

Four MCP servers shipped or were documented across the two beats this week, and lined up they give you the real spectrum of what vendors are currently willing to let an agent do.

At one end, 6sense: read-only, explicitly does not execute actions or modify data, per-user authorisation. Then Showpad, serving content out to whatever agent a team already runs. Then Braze, which allows writes but confines them to content objects and states that no user-profile PII is exposed.

At the far end, Optimove. Its MCP exposes actions called create_mini_game and save_mini_game. Describe a game in a sentence, and the AI generates it, deploys it, and returns a live playable URL. An agent producing a customer-facing asset and putting it into the world, not into a review queue.

What travels alongside that is the part worth copying. Optimove’s default MCP session lasts one day, with longer sessions granted per tenant on request rather than being the default. And the documentation states that customer identity is never exposed, only behavioural data.

Look at the shape of that. A one-day default session is the same idea as Anthropic’s mcpPersistentAlwaysAllowEnabled, arrived at independently, from the opposite side of the connection. The client vendor made persistent approvals switchable off. The platform vendor made the session expire by default and required you to ask for more. Neither company was coordinating with the other, and both concluded that agent authorisation should decay unless renewed.

That is the strongest signal in this week’s notes. When the client side and the platform side independently converge on time-limiting authorisation, it stops being a product decision and starts being an emerging norm.

The corollary is uncomfortable for anyone running automations: a session that expires is a session that breaks your scheduled job at 3am. Optimove’s own release note acknowledges this, offering extended sessions specifically for teams running scheduled reports and recurring agent workflows. Which is exactly the tension the whole industry now has to price. Every control that makes agents safer makes unattended automation more fragile, and somebody has to decide, per workflow, which of the two matters more.

Two permission models, two teams, one agent

Which leads to the question I have not seen anybody answer well, and I include the vendors in that.

The platform side has a permission model. Braze’s server has OAuth with SSO, regional endpoints, and write access scoped to content objects but not profiles. 6sense’s is read-only with per-user authorisation, and its documentation is candid enough to say that once data reaches the assistant, retention is the assistant platform’s business, not theirs.

The client side also has a permission model. Administrator keys governing approval persistence. Review gates before publication. Tool policies with wildcards and per-tool exceptions.

Both are correct. Both are necessary. They are configured in different consoles, owned by different teams, and reviewed on different cycles.

So when an agent reaches a system of record through an MCP server and does something nobody expected, which layer was supposed to stop it? The platform, whose scope permitted the connection? The client, whose policy approved the tool? Or neither, because each assumed the other was the enforcement point?

That gap is not any vendor’s fault. It is the normal consequence of a genuinely useful protocol spreading faster than the operating model around it. But it does mean that whoever owns identity and access in your organisation should be in the room when somebody connects an MCP server to a system that holds customer data. In most places I have looked, they find out afterwards, if at all.

A parallel worth watching

There is a second pattern forming next to MCP, and it is easy to miss because it uses different vocabulary.

Adobe’s Experience Platform release this week included an agentic skill delivered in something called CX Coworker, which handles sandbox object migration: discovering objects, packaging them with dependencies, validating before import, migrating and monitoring. Crucially, it surfaces execution plans and dependency analysis so the work can be reviewed before it runs. A few days earlier, Adobe’s loyalty module introduced its own Coworker skills.

That is a first-party agent layer, named and being extended across a vendor’s own stack, where the permission model and the dependency graph are already understood.

Set against MCP, the distinction is clean. MCP is about reach, meaning which systems an external agent can call. A first-party agent layer is about depth, meaning what an agent can do inside one vendor’s world with full knowledge of that world’s structure. Most organisations will end up running both, for good reasons, and they will be governed in entirely different places.

The plan-then-approve pattern in the Adobe skill is the part I would borrow regardless of vendor. An agent that migrates sandbox configuration on its own is alarming. An agent that shows you the execution plan and the dependency analysis and waits is genuinely useful. That distinction is going to define which agentic features get adopted in regulated environments and which get switched off after the first incident.

What I would take from this week

If you are standing up agentic work inside an organisation, the model choice has stopped being the interesting decision. Opus 5 and GPT-5.6 are both, by their makers’ own framing, components with a duty cycle and a price per unit of work. GPT-5.6 makes the point explicitly by splitting into three durable tiers, Sol, Terra and Luna, where the number marks the generation and the name marks a capability tier that can advance on its own cadence. That is a parts catalogue, not a flagship. You will change your mind about which one you use, more than once, and it will matter less each time.

The decision that will still be with you in two years is whether the permission model of your agent layer can be reconciled with the permission model of the systems it reaches. That is an identity and access question wearing an AI costume, and it belongs to the people who have always owned those questions, working alongside the people buying the tools.

Right now those are two separate models, configured in two separate places, by two separate teams. The vendors shipped their halves this week. The reconciliation is not something anybody is going to sell you.

The model you pick this quarter is a component. The permission model you build around it is the architecture.

Sources

Anthropic

OpenAI

GPT-5.6: frontier intelligence that scales with your ambition, the launch post, general availability 9 July 2026
Advancing the price-performance frontier with GPT-5.6, follow-up, 30 July
How GPT-5.6 fuses frontier intelligence with frontier efficiency, follow-up, 29 July

Google

Microsoft

Microsoft 365 Copilot release notes, governed agent publishing and MCP agents in Office

Adobe

AEP release notes, CX Coworker Sandbox Tooling agentic skill

MCP servers across the marketing beat

Agent governance and constraint-as-a-feature

Model conversations as customer data

Tealium release notes 2026, Anthropic data source and OpenAI connectors

The digest behind each weekly article is produced through a structured AI-assisted scan of official release notes and product update sources. I review the output, verify the relevant signals and write the interpretation.

This article draws from the AI Tools Weekly Digest scans run on July 30, 2026, covering release notes and product updates across the major agentic work platforms. The dated record behind it is in AI Watch, Week 31.

If you find errors or gaps in coverage, I want to know. The process improves when the output is challenged.